Conceptos avanzados para medir la velocidad de la página en 2020
Publicado: 2020-04-09Para comprender qué afecta la velocidad de la página en 2020, primero debemos comprender cómo un navegador representa una página web. Si no está familiarizado con la velocidad de la página y los conceptos de tecnología web como DOM, CSSOM, árbol de representación, costo de reflujo y tipos de DOM, probablemente desee comenzar leyendo el artículo vinculado anteriormente.
A medida que los sitios web y los navegadores web se vuelven más complejos, la velocidad de la página se vuelve algo más que el tamaño de una página o la rapidez con la que puede responder un servidor. En este artículo, veremos algunas de las métricas nuevas y emergentes para la velocidad de la página en 2020 y más allá: número y tamaño de las solicitudes de recursos, ruta de representación crítica, LCP, CLS y tiempo total de bloqueo.
Este artículo es el segundo de una serie de cuatro artículos sobre la velocidad de la página. Puede encontrar el primer artículo aquí: ¿Cómo crea un navegador una página web?
Administrar el orden, el tamaño y la cantidad de solicitudes de recursos
Cada paso del proceso de renderizado lleva tiempo. La forma de encontrar dónde su sitio web es lento y cómo acelerarlo implica observar cómo el navegador maneja los recursos durante el proceso de visualización de la página.
Esto significa que el orden, el número y el tamaño de las solicitudes juegan un papel importante en la medición de la velocidad de la página en la actualidad.
La contribución más importante del pedido de recursos y la optimización de las sugerencias de carga de recursos es reducir el TTI (Tiempo para interactuar) a través de la pintura con mayor contenido. Con la optimización del orden de los recursos, puede cargar archivos del mismo número y del mismo tamaño en menos tiempo y entregarlos a los usuarios y motores de búsqueda.
¿Qué es la ruta crítica de renderizado?
La ruta de representación crítica incluye todos los recursos que crearán la parte superior de la página web.
Su página web puede ser más lenta que la página web de sus competidores debido al tamaño de carga total de su página. Pero aquí está el truco: incluso si otros departamentos comerciales no le permiten corregir el tamaño de carga de la página, aún puede servir su contenido más rápido que sus competidores al optimizar la ruta de representación crítica.
Cómo optimizar la ruta de renderizado crítica
Este es un simulador de correlación de velocidad de página y tasa de conversión creado por Sergey Chernyshev. Puede encontrar la respuesta a la pregunta de qué sucedería si mi página web se cargara 0,5 segundos más rápido para los usuarios y se la mostraría a su equipo de desarrolladores para especificar que cada milisegundo puede mejorar la conversión.
Para optimizar la ruta de representación crítica, debe determinar qué recursos necesita para crear su parte superior del pliegue. Después de eso, hay algunas preguntas menores que hacer:
- ¿Qué recursos evitan que el navegador descargue fuentes críticas?
- ¿Se puede reducir el tamaño y el número de fuentes críticas?
- ¿Se pueden incorporar fuentes críticas?
- ¿Se pueden unificar las fuentes de la ruta de representación crítica para limitar el proceso de búsqueda de DNS?
Veremos un ejemplo. También proporcionaremos algunas recomendaciones para acelerar CSS, JS y HTML.
Aquí hay un ejemplo de parte crítica de una página web de Amazon. Con DevTools, puede ver el elemento <div> más importante en la parte crítica de la página junto con los códigos CSS necesarios. De esta manera, puede crear un bloque de código CSS en línea antes de que los recursos de bloqueo de renderizado molesten al navegador. También puede ver las pilas de código no utilizadas en la parte inferior. Amazon siempre usa los mismos patrones de recursos CSS/JS para diferentes categorías, incluso si no están optimizados.
Además de la velocidad, también hay otro problema aquí. Con diferentes tamaños de pantallas de teléfonos móviles, la parte crítica de la página web varía de un modelo a otro. Algunas pantallas no muestran el precio, algunas de ellas no muestran la información bursátil. Este es un error de diseño importante, pero también dificulta la optimización de la ruta de representación crítica. También divide el valor de PageRank si hay un enlace en esta área y disminuye la probabilidad de conversión.
Puede usar Puppeteer (motor de rastreo de Googlebot) para examinar este tipo de problema y tomar capturas de pantalla automáticas para cada modelo de teléfono inteligente/tableta y verificar el diseño de la parte crítica de la página web. Jean-Francois Lagarde tiene una buena biblioteca de titiriteros para esta tarea que tal vez quieras consultar.
Aquí hay una captura de pantalla rápida para la configuración del dispositivo en la captura de pantalla automática de Puppeteer para cada herramienta de ventana gráfica del dispositivo.
¿Cuál es la pintura con contenido más grande?
La pintura con contenido más grande (LCP) es el área más grande de una página web en términos de bytes y tamaño. En cada página web, hay muchos elementos "div" y todos ellos contienen diferentes componentes de página. Y estos componentes tienen diferentes valores de carga de página.
Según Google, la pintura con contenido más grande se ve afectada principalmente por el elemento más importante de la página. Para darle una idea de la importancia de LCP, Google ha decidido agregar esta nueva métrica a los informes de Lighthouse en el futuro.
Esto también significa que escucharemos cada vez más acerca de LCP, ya que se usará junto con Real User Metrics (RUM) y será una métrica clave, particularmente en lo que respecta a la ruta de representación crítica.
Aquí hay un ejemplo de pintura con contenido más grande de Lendio. Como puede ver, DevTools muestra el LCP en una página junto con datos sobre su tipo, tamaño y tiempo de carga. El contenido de su pintura con contenido más grande siempre debe incluir el propósito y el valor de la página, junto con la funcionalidad más importante o CTA y, lo que es más importante, ¡también debe cargarse primero!
En este ejemplo, es sólo texto. Combinarlo con una herramienta funcional sería mejor que solo un LCP de texto/imagen.
LCP solo considera ciertos tipos de recursos. La razón principal de esto es mantener la medición LCP simple al principio. A continuación se muestra una "instancia de secuencia de comandos" que está marcada para crear la lista de entradas de LCP. Estudiar estos fragmentos de código le enseñará a qué y cómo los desarrolladores de Google prestan atención al cargar una página.
[Expuesto=Ventana]
interfaz LargestContentfulPaint: PerformanceEntry {
atributo de solo lectura DOMHighResTimeStamp renderTime;
atributo de solo lectura DOMHighResTimeStamp loadTime;
atributo de solo lectura tamaño largo sin firmar;
atributo de solo lectura DOMString id;
atributo de solo lectura DOMString url;
¿Elemento de atributo de solo lectura? elemento;
[Predeterminado] objeto aJSON();
};
Lo que ve en esta lista son las escalas necesarias para la comparación de elementos candidatos que ingresan a la lista de entrada de LCP. A continuación, le mostraré una metodología para elegir los candidatos LCP ("texto de cuerpo grande" e "imagen grande").
Comprender los principios y el proceso para definir su LCP
Los principios para determinar el LCP son extremadamente importantes:
- Mientras se carga una página, el LCP puede cambiar en segundos. A veces, incluso si un componente de página permanece el tiempo suficiente como LCP en la pantalla, incluso un elemento de página más grande cargado detrás no cambia el estado anterior.
- A veces, un elemento de la mitad superior de la página (en la parte crítica de la página web) se selecciona como LCP en lugar de un elemento más grande debajo de la página (parte no crítica de la página web).
- Un elemento mayor<div> no se puede seleccionar como LCP si sus componentes están divididos en la pantalla. En su lugar, se seleccionará un elemento de bloque <div> como LCP. A continuación verá un ejemplo que ilustra esto.
En este ejemplo, vemos que el componente más grande es el <div> que incluye cuatro imágenes diferentes. Sin embargo, ninguna de estas imágenes individuales es más grande que el logotipo de Oncrawl y el texto que se incluye en el mismo elemento <div>. Dado que ambos se encuentran en la parte crítica de la página web, el segundo elemento será el LCP.
Al calcular el tiempo de LCP y determinar el punto de vista de los desarrolladores de Google, también debe centrarse en el diseño "compuesto". Si un elemento <div> no tiene una vista/sensación de diseño unificado y compuesto, probablemente no se elegirá como LCP.
Incluso si se selecciona, Google Chrome puede pensar que este no es un LCP saludable con nuevos códigos que agregará a la API de LCP en el futuro. Por razones relacionadas con UX y para una mejor comprensión de la velocidad de la página, Google continuará mejorando su propia percepción utilizando estos métodos.
¿Qué son los cambios de diseño y los cambios de diseño acumulativos?
El cambio de diseño es la idea de que, mientras el navegador descarga una página, los elementos de la página cambian sus posiciones de una manera que puede ser molesta para el usuario.
Mientras se descarga una página, cada parte de la página será visible una por una en un orden determinado. Esto es normal. Pero si estas partes cambian su posición de inicio debido a las partes subsiguientes, esto es un cambio de diseño.
El cambio de diseño acumulativo (CLS) es la suma de todos los eventos de cambio de diseño.
Chrome User Experience también tiene una sección sobre la puntuación CLS. Pero no se trata solo de UX. El cambio de diseño puede ser perjudicial para los pacientes con epilepsia fotosensible. Como “empresa de salud”, Google también debe dar valor a la salud de los usuarios; intentan disminuir el "estrés web" siempre que pueden.
“Creo que Google ya es una empresa de salud. Ha estado en el ADN de la empresa desde el principio”
David Feinberg – Jefe de Salud de Google
Aquí hay un ejemplo de cambio de diseño simple y decisivo de uno de los mismos sitios que hemos visto anteriormente en esta serie. Es un sitio web de noticias principal de Turquía y esta es su página principal...
Puede leer más sobre el cambio de diseño, parpadeos, parpadeos y variaciones de color que son peligrosos para la salud de los desarrolladores de Moz.
Cómo encontrar el cambio de diseño acumulativo en su sitio web
Para ver las partes cambiantes del diseño de sus páginas web, puede usar Google Chrome DevTools o puede usar la API de inestabilidad de diseño para escalar el proceso para todas sus páginas web.
El cambio de diseño acumulativo, o la suma de todos los eventos de cambio de diseño, es un criterio importante tanto para la velocidad de la página como para la UX en 2020 y más allá. Si la parte superior de la página web se desplaza durante la carga, también debe optimizarla al optimizar la velocidad.
A continuación, encontrará la fórmula de cambio de diseño, también un ejemplo de código API de inestabilidad de diseño para darle una perspectiva sobre la contribución de CLS y un método para calcular su puntaje de cambio de diseño.
La fórmula de cambio de diseño es la siguiente:
puntaje de cambio de diseño = fracción de impacto * fracción de distancia
La puntuación de cambio de diseño se calcula con dos nuevos términos útiles, Fracción de impacto y Fracción de distancia:
- La fracción de impacto es el porcentaje de pantalla afectada por el cambio. Sabe que su CLS será alto si el elemento de la página, que cubre el 50 % de la ventana gráfica en los dispositivos móviles, crea un cambio de diseño, porque moverlo afectará, como mínimo, a más del 50 % de la pantalla.
- La fracción de distancia se mide por cuánto se aleja el elemento móvil de su punto original en la dirección en la que se desplaza durante el cambio. Si la distancia entre la primera y la última posición es excesiva, la fracción Distancia también lo será.
Esto le facilitará estimar su puntaje CLS y asesorar a sus equipos de TI y UX.
Arriba, puede ver un fragmento de código API CLS y, debajo, un GIF que muestra cómo calcular el cambio de diseño acumulativo.
En el mismo sitio de noticias turco que hemos estado viendo, nuestro CLS es 0,47. Teniendo en cuenta que se calcula entre 0 y 1, esta es una puntuación bastante mala.
Puede calcular su CLS con el sistema métrico personalizado avanzado de Webpagetest.org. Debe usar los códigos de la API de CLS hasta "Envía la parte de información". Después de eso, debe cambiar su URL de root/results/ a root/custom_metrics.php?test={Mismo número de resultado}.
¿Qué es el tiempo total de bloqueo?
Puede descargar la parte superior de su página web rápidamente sin ningún cambio de diseño, pero si no responde a la entrada del usuario, Google Algorithms afirma que tiene otro problema de velocidad de página y UX. El tiempo total de bloqueo es el tiempo perdido en esta etapa.
Al igual que el cambio de diseño acumulativo y la pintura con contenido más grande, el tiempo de bloqueo total es una nueva métrica de velocidad de página y UX para 2020 y más allá.
Lo que cuenta para el Tiempo total de bloqueo (TBT) es cualquier evento de carga entre First Paint (FP) y Time to Interactive (TTI) que bloquea el hilo principal del navegador (o dispositivo) durante más de 50 milisegundos y evita que los usuarios realizar cualquier proceso.
Cómo calcular y optimizar TBT
Puede calcular su tiempo total de bloqueo (TBT) con la API de tareas largas.
Para optimizar su puntaje TBT, también debe centrarse en el orden y las preferencias para cargar recursos, junto con la cantidad y el tamaño de las solicitudes.
Esto es del mismo sitio de antes. Como puede notar, el hilo principal está completamente ocupado durante más de 5 segundos sin parar. Su LCP todavía se está cargando después de casi 2,5 segundos... Lo importante a tener en cuenta aquí es que su solicitud de tarea más larga es superior a 350 MS. Esto significa que se considera que está bloqueando el subproceso principal durante más de 300 MS.
Además, todos los tiempos bloqueados se cuentan como parte del Tiempo total de bloqueo. Esto no solo incluye elementos en la parte superior de la página, sino que se aplica a todos los componentes de la página web. Crea un historial de navegación dañino para su sitio web.
Si su TBT es más de 300 milisegundos, esto probablemente dañará considerablemente la retención de usuarios y la tasa de conversión.
Puede ver un ejemplo de cálculo para TBT para el hilo principal anterior. En este ejemplo, hay cuatro solicitudes. Google Chrome puede crear 6 solicitudes desde el mismo servidor a la vez. Solo los primeros 50 MS de ellos funcionarán sin problemas; después de eso, comenzará a realizar múltiples tareas al mismo tiempo, tanto como lo permita la potencia de la CPU/red. Recuerde, un ser humano puede ver un cuadro cada 16 MS. Google se preocupa por cada milisegundo para los usuarios.
En este ejemplo, el tiempo total de bloqueo es de 1 segundo y 100 MS.
Los próximos pasos en la optimización de la velocidad de la página
Hasta ahora, en esta serie, hemos examinado cómo los navegadores crean páginas web, lo que nos ha permitido ver en este artículo cómo las nuevas métricas relacionadas con la carga de las páginas en los navegadores pueden afectar la velocidad de la página. Hemos analizado algunas de las principales métricas nuevas y cómo medirlas y optimizarlas.
En el próximo artículo de esta serie sobre la velocidad de la página en los sitios web de hoy, cubriremos un tema que se ha convertido en un tema importante en SEO y desarrollo web: optimizar los activos de JavaScript para mejorar la velocidad de la página y la representación de la página.