Estamos planeando desarrollar un nuevo sitio web. Nuestro objetivo es cargar rápidamente las páginas web . ¿Cuáles son todas las técnicas que debemos seguir?Cargando rápidamente páginas web
¿Alguien puede darme buenas sugerencias, enlaces de foros o artículos.
Nuestra plataforma es PHP, MySQL, Javascript y AJAX.
Una de las mejores guías para acelerar los tiempos de carga de su sitio web:
http://developer.yahoo.com/performance/rules.html
Actualización: Google ahora tiene una excelente guía, así
http://code.google.com/speed/page-speed/docs/rules_intro.html
Junto con un aún mejor addon for Firefox. En mis pruebas hasta el momento, el complemento de Google Page Page es mucho mejor que YSlow. Proporciona un análisis mucho más detallado y consejos más inteligentes (en lugar de recomendar un CDN para sitios web pequeños como YSlow)
Almacenar en caché el almacenamiento en caché.
Escoja uno, utilizarlo. No tener que buscar todo en la base de datos acelera enormemente las cosas.
Tenga en cuenta que memcached y APC no son mutuamente excluyentes, el uso de APC como un caché de código de operación no descarta el uso de memcached. –
Sí, APC definitivamente debería usarse como opcode, pero en realidad también es compatible con los datos de almacenamiento en caché, mucha gente no se da cuenta. http://php.net/apc_add http://php.net/apc_fetch –
Una herramienta útil es YSlow que es una herramienta de Yahoo que ayuda a identificar los problemas de rendimiento de la página web. Además, Best Practices for Speeding Up Your Web Site de Yahoo es una buena lista.
Sin embargo, consulte la entrada del blog de Jeff Yahoo's problems are not your problems para obtener una perspectiva sobre este tema.
+1 para los problemas de Yahoo no son sus problemas. –
lo mismo que el comentario de Sean. –
+1 para el enlace al blog de Jeff. – altermativ
Escriba el código que sea necesario, pero no demasiado pequeño.
Menos código, menos para compilar, menos para enviar, menos para recibir, menos para procesar, menos para mostrar.
+1 diseño más claro/menos ruido al final – Niteriter
Utilice un generador de perfiles para PHP para asegurarse de que su código se esté ejecutando a una velocidad aceptable. Refactor (donde sea posible) si el rendimiento puede mejorarse.
Algunos puntos aleatorios.
Renderizar progresivamente en lugar de construirlo en la memoria y enviar al final da una impresión distinta de de velocidad.
Hay algunos trucos avanzados de almacenamiento en caché que puede hacer, como un caché directo (esto es lo que hace Akamai a gran escala) y separar el contenido estático y dinámico.
Con PHP en particular, tenga cuidado con la copia de grandes cantidades de datos. PHP 4 fue notorio por esto debido a su "copia por defecto", pero aún es demasiado fácil tener grandes cantidades de datos a mano en PHP 5. En otras palabras: no copiar (¡o crear!) Cadenas, matrices y objetos innecesariamente; trabaje con ellos en su lugar y pase referencias en su lugar.
además de lo que se ha dicho:
El javascript comprimido tiene que estar descomprimido en algún momento. En el tiempo de ejecución javascript de los navegadores, esto está lejos de ser rápido. Use la compresión de nivel http en su lugar. – troelskn
¿Eh? El intérprete no puede leer el javascript comprimido. Simplemente elimina todos los espacios, pestañas, etc., y reemplaza las variables locales para que en lugar de "myVariable" tenga "a". La compresión HTTP, por otro lado, tiene que ser descomprimida por el navegador y es un impuesto (muy pequeño) sobre los recursos. –
Depende. Juro que he visto algo de "compresión de JavaScript" que toma su JS, comprime "real", Base64 lo codifica y almacena el desorden como una variable de JavaScript. Eso o estoy loco. –
Comprima todos sus archivos, incluyendo los archivos css y js que también comprimen sus archivos php. Haga la menor cantidad posible de llamadas a la base de datos y, como se indicó anteriormente, guarde en caché todas las devoluciones.
Acepto. Una llamada a la base de datos que devuelve varios resultados es mejor que varias llamadas a bases de datos distintas. – Kristen
1) mod_gzip/mod_deflate! Esta es una solución tan fácil que me sorprende que no esté activada de forma predeterminada.
2) Juegue trucos con su URL para que pueda decirle a los navegadores que guarden en caché sus archivos JS y CSS para siempre. En otras palabras, construir de la URL para que parezca:
http://www.yourdomain.com/js/mad_scriptz-v123.js
A continuación, utilice mod_rewrite y la tira a cabo el "-v123":
<IfModule mod_rewrite.c>
# http://www.thinkvitamin.com/features/webapps/serving-javascript-fast
RewriteEngine on
RewriteRule ^/(.*)\-v[0-9.]+\.(css|js|gif|png|jpg|xap)$ /$1.$2 [L]
</IfModule>
Ahora Apache va a ir en busca de "/js/mad_scriptz.js "... Cada vez que cambie su contenido estático, simplemente aumente el número de versión para obligar a los navegadores a volver a cargar el contenido. Normalmente tengo una variable de plantilla que contiene un número de versión global al que todo se vincula. No es el más eficiente, pero funciona para mis propósitos. Si puede vincular el número de versión a su sistema de compilación o un hash del archivo, eso sería extra dulce.
Obtener mod_expires tan toda su materia estática expira años a partir de ahora:
<IfModule mod_expires.c>
ExpiresActive On
# all in seconds...
ExpiresByType image/x-icon A2592000
ExpiresByType image/gif A2592000
ExpiresByType image/jpeg A2592000
ExpiresByType image/png A2592000
ExpiresByType application/javascript A2592000
ExpiresByType application/x-javascript A2592000
ExpiresByType application/x-shockwave-flash A2592000
ExpiresByType application/pdf A2592000
ExpiresByType text/css A2592000
ExpiresByType application/rdf+xml A1800
</IfModule>
Actualización: Se ha observado que no todos los navegadores o los motores de búsqueda como contenido gzip. No lo enciendas ciegamente como sugiero arriba. Asegúrate de no alimentar los navegadores antiguos gzip incluso si lo aceptan (algunos se pondrán molestos con javascript comprimido). La documentación para mod_gzip y mod_deflate ambos tienen ejemplos que deberían funcionar bien (supongo que lo hacen, o la gente los enviaría por correo electrónico con los cambios :-).
También debo mencionar que, según mi experiencia, si tiene un proxy inverso entre sus servidores Apache mod_gzip y el mundo, debe tener cuidado. Squid 2.6 engañará a menudo a Apache para que no haga gziping cuando debería y, lo que es peor, almacenará en caché las versiones sin comprimir y las enviará a navegadores que pueden manejar contenido gzip. No sé si 3.0 corrige esto y no sé si algo está mal en mi configuración (lo dudo). Sólo tenga cuidado :-)
Dicho eso. Encenderlo. En serio :-)
mod_gzip/mod_deflate no está activado por defecto por una muy buena razón: no todos los principales navegadores lo admiten sin problemas. Usar con precaución. Si comienza a recibir quejas o (más probable) una caída en el tráfico sin una palabra de los usuarios, apáguelo. De lo contrario, siéntete feliz de que tus usuarios usen navegadores inteligentes. –
Esto es muy cierto. –
Yahoo: "Poner hojas de estilo en la parte superior", "Poner guiones en la parte inferior".
Esto aceleró mi sitio reciente más que cualquier otra optimización.
Aquí hay un consejo que siempre me resulta útil: Si tiene muchas imágenes pequeñas, colóquelas todas en una imagen embaldosada. En sus declaraciones CSS, controlar el área de visualización del elemento HTML mediante la manipulación de las coordenadas X e Y del fondo:
.icon {
background-image:url(static/images/icons.png);
height:36px;
width:36px;
}
.food {
background-position:-52px -8px;
}
.icon_default {
background-position:-184px -96px;
}
Los azulejos se puede hacer en la secuencia de comandos Python, o con la mano si tiene un conjunto manejable.
Gmail hace esto también. Ver: http://mail.google.com/mail/images/2/5/greensky/icons7.png
Un proyecto que ayuda con algunos de los puntos en las directrices Yahoo 's (http://developer.yahoo.com/performance/rules.html) es Minify que emplea minimización, la agrupación de paquetes y HTTP condicional servir en el mismo espacio, se utiliza con buenas prácticas de diseño puede reducir significativamente reducir las cargas de página, especialmente la experiencia del usuario (que difiere de los tiempos de carga de la página en realidad).
¿Qué tan rápido es "rápido"? ¿Qué tipo de carga esperas realmente? ¿Cómo se va a alojar la aplicación? ¿Qué vas a estar haciendo? Hay una diferencia mundial entre escribir algo que es "lo suficientemente rápido" y algo que puede manejar cargas a escala de Facebook. –