Blog

Factores técnicos en un análisis de velocidad de carga

(artículo publicado originalmente el 28-03-16 en jiuston.io, blog que pereció)

Hola de nuevo, acá estoy siguiendo con el tema que comencé en:

La importancia de la velocidad de carga para GOOGLE

(si no conocés del tema, pegale una leida. Vas a entender mejor este artículo).


Optimizar velocidad de cargaEs una idea ya conocida y popular dentro del ambiente webmaster ( y aplicando la lógica también llegamos a lo mismo) que u
n sitio más rápido tiene beneficios, tales como mejores SERPs, menores porcentajes de rebotes y una experiencia de usuario más agradable.

 

Ahora, vos me dirás: Gastón: ¿De esto me querés hablar? – Obvio que no! Te quiero contar sobre los aspectos técnicos a tener en cuenta para un análisis de carga de páginas web.

Primero, te quiero presentar un artículo que el propio Google sacó a la luz hace ya dos años y medio (por Agosto del 2013). Personalmente lo titularía:

Google quiere que tu sitio cargue en menos de un segundo.

Éste es el link: https://googlewebmastercentral.blogspot.com.ar/2013/08/making-smartphone-sites-load-fast.html

¿De qué nos sirve analizar un test de velocidad de página?

En el artículo que cité antes, les muestro 3 herramientas gratuitas que realizan análisis de velocidad de carga de página, cualquiera que le ingreses. Los puntos más importantes que nos dirán estos análisis:

  • Encontrar y resaltar los scripts, fuentes y plugins que están molestando y creando retardos en la carga (HTML, CSS, Javascript).
  • Ver que los scripts estén minificados.
  • Encontrar imágenes pesadas que limitan y provocan un cuello de botella.
  • Determinar si hay bloqueadores activos sobre los render de JavaScript o de CSS.
  • Medir el tiempo para el primer bit (TTFB – Time To First Bit).
  • Ver y analizar el peso de las páginas y el número de pedidos al servidor.
  • Probar el rendimiento de tu web en diferentes exploradores.
  • Analizar el rendimiento del servidor, ya sea con pedidos desde diferentes posiciones geográficas como la estabilidad del servicio de CDN (Content Delivery Network).

 

Conceptos sobre la velocidad de un sitio web.

Es claro que antes de lanzarse a ver los análisis de velocidad de las páginas web, debemos entender qué son los puntos que antes marqué y por qué son importantes.

http response request

Tiempo para el primer Bit (Time to First Byte – TTFB)

Este tiempo mide la capacidad de respuesta del servidor donde está alojada la web. En términos simples: Es el tiempo que le demora al explorador para comenzar a recibir información desde el servidor, luego de haber realizado un pedido.

Una idea importante que debemos tener, es que las webs son una pila de archivos que deben ser ejecutados del lado del servidor, y éste nos entregará (en la mayoría de los casos) el código puro para que el browser lo interprete. Y estos archivos, son requeridos mediante los “request” contra el servidor.
Una forma fácil de mejorar el TTFB, que es reducir esta medida, es contratar un mejor hosting y que los data centers estén lo más cerca de donde las visitas suelen cargar la web. Un ejemplo sería, si nuestro público es de Uruguay, que el datacenter esté en el sur de Brasil, en el mismo Uruguay o bien en Argentina. Otra opción, es utilizar servicios de CDN, que dentro de su principal utilidad está la de reducir el TTFB. (prometo hacer un  artículo hablando de los CDN).


Los bloqueadores de render de Javascript y de CSS

Las renderizaciones de Javascript y de CSS que no sean importantes para mostrar al comienzo de la web, el conocido “Above the fold”, deberían dejarse para cargar a lo último. O al menos luego de que se cargue la parte que primero se muestra.

Javascript

Google hace especial mención y recomendaciones para remover o diferir el javascript que está molestando al contenido que se muestra en el “above the fold”.
Este es el artículo de google:

https://developers.google.com/speed/docs/insights/BlockingJS

CSS

CSS Velocidad de página

El CSS es el codigo de estilos en cascada, ponerlo de otra manera es lo que hace que el sitio se vea estético a grandes rasgos. Con el CSS se pueden editar las fuentes, lo colores o las orientaciones de los bloques que estén dentro de la programación de la web, entre muchas otras cosas, que escapan a mis conocimientos.
Lo que es recomendado que debemos hacer sobre un sitio, al analizar su velocidad:

  1. Llamar de manera correcta a los archivos de CSS.
  2. Tener pocos archivos de CSS.
  3. Usar la menor cantidad posible de sentencias “overall”.

Aquí les dejo un tutorial de los “chicos Google”, muy copado está:

https://developers.google.com/web/fundamentals/performance/critical-rendering-path/render-blocking-css

Una buena idea a tener en cuenta al pensar la optimización del CSS, es que tenemos que descargarlo lo más rápido posible al cliente así poder optimizar al máximo el tiempo del primer renderizado.

Optimizar los recursos

Minimizar (cómo se dice en la jerga), es solo un sinónimo de optimizar los recursos necesarios para que el sitio cargue por completo. Así, vale mucho la idea de que quitemos, mejor dicho que no estén cuestiones innecesarias dentro del HTML, JavaScript y/o CSS.

Algunos de ellos son:

  • Caracteres de espacios en blanco,
  • Caracteres de nuevas líneas,
  • Comentarios o
  • delimitadores de bloques.

Éste último influye directamente en la cantidad de código puesto dentro, impactando sobre el tiempo que demora el sitio web en cargar.
Hay algunas herramientas para optimizar el uso de recursos. Para los sitios personalizados pueden utilizar la herramienta de Dan’s CSS y Javascript Minify. O si estás en WordPress, te recomendamos el Autoptimize.

Peticiones HTTP (Requests)

Técnicamente hablando, cuando un explorador carga datos desde el servidor, lo hace utilizando HTTP (Hypertext Transfer Protocol). Esta carga de información se realiza mediante una serie de pedidos/respuestas, en la jerga se utiliza request/response, entre el cliente y el host.
Generalmente, cuanto más pedidos se realicen al servidor, más tiempo demorará la web en cargar. Hay varias formas de reducir la cantidad de requests, algunos son:

  • Combinar los archivos de CSS y JavaScript,
  • Utilizar “CSS Sprites” (Esta es un atajo, donde se combinan varias imágenes dentro de una, pura y exclusivamente para mejorar el rendimiento de la web)
    Más info en: CSS Sprites
  • Reducir la utilización de plugins y/o cuestiones necesarias de una tercera parte y que ésta realice un número grande de pedidos externos.

Optimizar las imágenes

  • Cuando se usa un width y height en el código html que muestra la imágen, usando un tamaño menor al real del archivo de la imagen. Se puede reducir el tamaño real del archivo sin perder calidad visual.
  • Comprimir sin que se note visualmente usando algoritmos de tratamiento de imágenes. Ejemplo, con GIMP muchas veces no noto diferencia visible cuando exporto en jpeg con nivel de calidad 50% en lugar del 70%.
  • Cambiar la extensión (formato de compresión).
  • Recortar espacios en blanco (bordes)


Optimizado vs no optimizado

Habilitar la compresión gzip en el servidor

Los datos enviados entre el cliente y el servidor se comprimen para ocupar menos espacio y por lo tanto mejorar la velocidad de transferencia. Se aclara en las cabeceras HTTP y es necesario que se pongan de acuerdo el servidor y el cliente en el tipo de compresión utilizado. Hoy en día los más comunes son gzip y deflate.

https://en.wikipedia.org/wiki/HTTP_compression

https://developers.google.com/speed/docs/insights/EnableCompression

Especificar cache de navegador

Dentro de las cabeceras HTTP se puede especificar un “tiempo máximo de vida” del recurso enviado por el servidor, de tal forma que si el cliente necesita solicitar el mismo recurso dentro de un período de tiempo menor, se descargará desde el cache del navegador en su disco rígido en lugar de pedirlo nuevamente al servidor. Esto aumenta la velocidad de carga a la vez que optimiza el ancho de banda utilizado (del servidor y del cliente).

Esto es muy útil en recursos estáticos como los PDF pero se debe tener cuidado con los contenidos dinámicos:

https://developers.google.com/speed/docs/insights/LeverageBrowserCaching

Hasta acá llegamos. Se puso bastante técnico el artículo, no? Pensemos que esto es solo un punto de vista por arriba del tema. De seguro, si algún programador o developer específico de estos temas me va a criticar de que no estoy siendo 100% estricto con lo que digo. Otra vez, esto es una visión para que lo entendamos con poco nivel de abstracción. Queremos entender, no ser expertos en el tema.

 

Ya saben, comenten sobre qué les pareció este artículo. Todo el contenido que publico está sujeto a edición y corrección. No tengas miedo, mucho menos vergüenza; Si me equivoco, decímelo!

Les mando un abrazo fuerte.
Gastón Riera

Comments are closed.