Todos aquí están dando un montón de buenas sugerencias, pero se están perdiendo el paso más importante.
Instrumentación.
Antes de comenzar a arreglar las cosas, averigua qué está roto. Si su servidor de aplicaciones tarda 5 segundos en generar una página, usar sus CDN con recursos estáticos no ayudará mucho. Si está descargando 10 MB de imágenes en cada vista de página, agregar Memcache a su arquitectura de fondo no solucionará el problema.
- Cómo poner una imagen de ancho completo con animaciones en la página de inicio con Rails
- ¿Qué es un editor basado en web de nodejs que puedo alojar yo mismo?
- ¿Cuánto cobran los diseñadores web por sitio web?
- ¿Cuáles son sus sitios web de conferencias favoritos?
- ¿Cuáles son las principales diferencias entre un ingeniero de interfaz de usuario, un desarrollador web y un ingeniero?
¿Sabía que puede abrir Chrome y ver el tráfico y el volumen de la red al cargar una página? Aquí hay algunos datos sobre una recarga de Google:
Una herramienta que recomiendo para muchas cosas, pero también para la supervisión del rendimiento es New Relic. Realiza un seguimiento del rendimiento del servidor y del cliente, y lo desglosa por el mayor cuello de botella. Por ejemplo, este es el gráfico de pave.com para el tiempo de carga del navegador:
En este caso, puede ver que la gran mayoría de nuestro tiempo lo dedicamos al procesamiento DOM y al procesamiento de páginas. Al intentar mejorar el rendimiento, este es el primer lugar para buscar: vea cuál es el problema antes de perder el tiempo en soluciones potencialmente complicadas para problemas que no tiene.
Antes de entrar en problemas de rendimiento específicos de la página, vea dónde se tendrá el mayor impacto. Puede ver en qué está pasando más tiempo el usuario (esto es básicamente [# de páginas vistas * tiempo de carga promedio] para cada página). Para Pave, tener el mayor impacto implicaría optimizar la página de inicio. No importa qué tan rápido se cargue una página si nadie la usa.
Para alguien que comienza un nuevo sitio web.
Probablemente no necesite preocuparse por todas las posibles optimizaciones mencionadas aquí. Hay algunos que harán la vida más fácil desde el principio, o que son tan fáciles que sería una tontería evitarlos. Específicamente:
- Instrumente su sitio. Esto es lo mas importante. A largo plazo, es la única forma de saber cómo te va.
- Comprenda la división entre la hora del servidor, la hora de la red y la hora del navegador. Críticamente, debe comprender que la optimización de uno casi no tendrá impacto en el otro. Si su servidor es lento, no importa qué tan rápido haga el navegador, y viceversa. Hay menos cosas que puede hacer sobre el tiempo de la red (hasta que sea megaescala) que no sea usar un CDN.
- Poner CSS en la parte superior de la página y secuencias de comandos en la parte inferior. Esto requiere literalmente cero esfuerzo extra de su parte. Ayuda porque el navegador comenzará a representar la página (el usuario percibirá que se está cargando) incluso antes de que se ejecuten todos los scripts.
- Evite alinear CSS / JS. Los navegadores almacenarán en caché estos recursos externos, lo que reducirá el tiempo de carga en las vistas de página posteriores. Tenga en cuenta que esto no ayudará (y podría perjudicar) si la tasa de rebote de su sitio es del 100%. Pero entonces probablemente tengas problemas más grandes.
- La mayoría de los elementos “no” en las Mejores prácticas para acelerar su sitio web . Si nunca comienza, no necesitará eliminarlo más tarde. Esto va para expresiones CSS, minimizando iframes, usando sobre @import, evitando escalar imágenes en HTML, redireccionamientos, etc.
- Optimiza imágenes / usa sprites CSS. Utilice el mejor formato de imagen para el trabajo (PNG para iconos, JPG para fotos) y elija una configuración de calidad para JPG que logre el equilibrio correcto entre calidad y tamaño. El uso de sprites CSS significa que en lugar de realizar múltiples solicitudes para descargar íconos, puede descargar una imagen y usar background-position: en CSS para mostrar la sección correcta.
Algunas cosas fáciles que probablemente deberías hacer desde el principio:
- CDNs . Cloudfront es bastante trivial de configurar y funciona bien para Pave. Solo lo dejé fuera de la lista inicial porque probablemente no sea algo que literalmente necesites al hacer prototipos o mostrar amigos iniciales. También es bastante fácil agregar más tarde.
- Empaquetado / minificación JS / CSS. En Pave, usamos LESS y RequireJS para esto. Significa que ambos estamos enviando menos bytes a través del cable, y que la mayoría de las visitas a la página solo hacen 2-4 solicitudes de recursos estáticos, aunque, como desarrollador, considero que son muchos archivos más pequeños.
- Componentes GZIP. Suponiendo que tiene control sobre su servidor web, esto es probablemente solo un indicador de configuración. Si no tiene control sobre su servidor web, es probable que esto ya esté configurado para usted.
- Optimice la obtención de datos del lado del servidor. Esto es bastante abstracto porque las estrategias son completamente diferentes dependiendo de su almacén de datos. Pero algo que he visto una y otra vez son las personas con patrones de acceso a datos realmente muy ineficientes. New Relic puede ayudarte a rastrear cuánto tiempo pasas buscando datos. Hablando en términos generales, las tres estrategias que podría emplear son: enfrentar con un caché, acceso por lotes de datos y reducir la sobrecarga.
- Monitorear el servicio externo perf. Una API que utilizamos anteriormente en Pave tomaba ~ 1000ms por consulta, lo que resultó en una experiencia de usuario realmente mala. Además, intente siempre que sea posible llamar a API externas de forma asíncrona o al menos después de que la respuesta se vacíe al navegador. Por ejemplo, hacemos esto para todos los informes métricos, por lo que realmente no importa si la API de Mixpanel es lenta o cuántos datos enviamos.
De todos modos, eventualmente deberías asumir todo lo que Steve Souders recomienda y seguir trabajando para asegurarte de minimizar el tiempo del servidor también. Las cosas sofisticadas como el enjuague temprano, la carga progresiva y similares pueden no ser el mejor uso del tiempo cuando se realizan prototipos; pero puede proporcionar un inmenso rendimiento a largo plazo.