Desde que la web comercial existe hay algo que el cliente siempre pidió, pide y pedirá... “que el sitio cargue rápido”. Si son clientes que no tenían web, este requerimiento era por mero capricho, pero hay estudios que demuestran un serio impacto de un page load (carga de la página) largo, al punto tal de que 100ms son decisivos para lograr una venta. Ante estos estudios, es obvio que no es un mero capricho.
¿Como hago que un sitio cargue rápido?
Esta respuesta es muy compleja, requiere cada parte del proceso de entregar la web este optimizada lo más posible, y un poco más. Estas tres partes son;
- Front-end: diseño, maquetación, y javascript
- Back-end: programación pura y dura
- Servidor: un técnico especializado en servidores (lo digo en plural por las granjas de servidores)
Antes de ver un poco cada parte, analicemos cómo funciona una petición normal.
- Usuario escribe la url en la barra de direcciones y presiona enter, o hace click en un link.
- Se envía esa petición a nuestro servidor
- El servidor entrega un HTML, ese HTML tiene más peticiones (css, js, imágenes, etc.)
- Llega la petición al cliente y el browser la procesa
- Se hacen las peticiones de archivos adicionales, una petición por archivo
- El servidor entrega cada archivo adicional
Llega la petición al server
Cuando llega la petición al servidor, es normal que utilicemos un lenguaje de servidor para que nuestro sitio sea dinámico, aquí ya tenemos el primer problema. El servidor siempre entrega HTML, nunca entrega PHP, ASP, o código fuente, entonces entregar un archivo HTML estático (con extensión .html) es más rápido que un archivo HTML dinámico (generado por un lenguaje de servidor) ¿Por qué? Por una simple razón, el servidor tiene que interpretar el lenguaje de servidor para crear el archivo HTML que será entregado. Es más rápido entregar algo que tienes hecho, que algo que tienes que crear.
Para solucionar esto hay varias alternativas, wordpress tiene varios plugins para ello, algunos frameworks también, o puedes usar una solución de servidor (como varnish), básicamente lo que hacen estas herramientas es generar el archivo HTML, guardarlo en algún lugar y entregarlo cuando el cliente lo pida. Cada herramienta es configurable para regenerar el archivo HTML cada cierto tiempo o cuando se modifique.
Se envía petición al cliente
El archivo sale del servidor, antes de hacer esto se puede usar Gzip (formato de compresión) en el archivo HTML. El servidor puede ponerse de acuerdo con el browser y si ambos soportan Gzip el archivo HTML es enviado comprimido a través de internet. Esto lo que hace es comprimir el paquete a enviar. Tengamos en cuenta, que un archivo HTML es texto plano, con caracteres legibles por humanos, por lo que el porcentaje de compresión es muy alto. Con esto, el paquete que originalmente pesaba 100kb, puede pesar 40kb. A menos peso del paquete, más rápido llega al cliente.
El browser recibe el archivo
Cuando el archivo llega, el browser comienza a renderearlo, es decir dibujarlo. Aquí es muy importante 3 cosas:
- Poner las llamadas a archivos CSS en el <head>
- Poner las llamadas a archivos JS una línea antes del </body>
- Minimizar la cantidad de llamadas a archivos
Pero, ¿por qué?, siempre puse los <script> en el <head>, uso muchos css, y algunos en el medio del html, tengo una llamada por cada imagen y carga bien el sitio ¿Por qué esta mal?,
Teniendo los archivos css cargados, nos aseguramos que el sitio se vea bien mientras se va cargando.
Cuando el browser ve un tag <script> deja de renderear el sitio, pide el archivo js, lo procesa y luego sigue con la carga del sitio.
Cada llamada a un archivo es una demora en pedir el archivo, buscarlo en el server, enviarlo. Burdamente hablando, es más trabajo “administrativo” que trabajo “real”.
Se piden los demás archivos
Una vez que el html renderea, se comienzan a pedir archivos css, js, imágenes, etc. Es muy bueno tener un CDN (Content Delivery Network, es una red donde replicas tus archivos estáticos para que sean leídos) para poder hacer descargas en paralelo. El browser está limitado a 2 archivos por dominio, sin un CDN puedo pedir 2 archivos simultáneamente, si tengo 4 CDN puedo pedir 4 x 2 + 2 que es igual a 10 archivos simultáneamente. Un CDN se puede crear de 2 maneras, con tu técnico de servidores, o puedes usar los servicios externos como Amazon o Google, ambas opciones son buenas.
Conclusión
Todo lo que sale del server puede ser optimizado, el html, css, js, imágenes, etc hay técnicas para ello. La clave está en hacer todo, optimizar no es hacer una cosa bien, es hacer todo bien, esforzarse en cada parte del proceso y perfeccionarlo al extremo y un poco más.
En mi experiencia personal, el page load de un sitio se puede reducir un 40% solamente con buenas prácticas y optimizando cada parte, sin gastar dinero en mejorar el server y sin cambiar de frameworks o CMS.
¿Sabes SQL? ¿No-SQL? Aprende MySQL, PostgreSQL, MongoDB, Redis y más con el Curso Profesional de Bases de Datos que empieza el martes, en vivo.
Por gielfull el 16 de Diciembre de 2011
Una gran manera de empezar una serie de escritos al respecto
¿Puedes agregar alguna imagen Dientuki? En los comentarios. Yo la integro y entonces te paso.
Por gzaloprgm el 16 de Diciembre de 2011
Unir todas las imágenes del "template" en un spritesheet, para minimizar las peticiones.
Las cosas estáticas (imágenes, scripts, ...) meterlas en otro dominio así el navegador no manda las cookies al pedirlas.
Si el contenido es largo y tiene varias imágenes grandes, conviene usar lazyloading (ir cargando imágenes cuando sean necesarias)
Si es una página con alto bounce rate o que no se va a volver a visitar, conviene integrar imágenes pequeñas usando URIs tipo data:
No abusar de los efectos de CSS3, si se puede hacer con backgrounds es mucho mejor. Cuanto más radio de desenfoque es peor.
Si cambian las dimensiones de un div que tiene sombra y border radius, puede andar todo medio lento y parecer "pesado"
Espero que les sirvan
@tifa^ ponle en los creditos!!!
Por Dororo el 18 de Diciembre de 2011
me imagino que pretendes continuar con mas info?.
Saludos.
Me imagino que lo mencionará a su tiempo, pero no puedo dejar de comentarlo que una de las primeras cosas que debemos hacer al momento de optimizar es medir.
No tiene sentido invertir muchos recursos de tiempo en optimizar áreas y finalmente descubrir que se gana unos 100ms de mejora, ignorando que otro tipo de ajustes puede impactar mucho más en los resultados.
Por ignacio85r el 19 de Diciembre de 2011
Por galindezcba el 20 de Diciembre de 2011
Como siempre tus tutoriales son muy claros!!
Gracias amigo!
Por Dawry el 20 de Diciembre de 2011
Por cethapgames el 26 de Diciembre de 2011