Herramientas vitales para la Web central

Sigo pensando que los Core Web Vitals ideados por Google son inteligentes. Cuando comencé a preocuparme por el rendimiento, todo era: ¡reducir las solicitudes! caché cosas! ¡Haz las cosas más pequeñas! Y si bien todos ellos están muy relacionados con el rendimiento web, están relacionados de forma abstracta . El rendimiento web real para los usuarios son cosas como ¿ cuánto tiempo tuve que esperar para ver el contenido de la página? ¿Cuánto tiempo pasará hasta que pueda interactuar con la página, como escribir un formulario o hacer clic en un enlace? ¿Las cosas saltaron desagradablemente mientras intentaba hacer algo? Por eso los Core Web Vitals son inteligentes: miden esas cosas.

La pestaña Lighthouse en Chrome DevTools los tiene ahora:

Es bueno vigilarlos, porque recuerde , aparte de que esos números tienen un beneficio directo para sus usuarios una vez que llegan a su sitio, pueden afectar a los usuarios que acceden a su sitio. Web Core Vitals está teniendo en cuenta el SEO y los nuevos requisitos del carrusel que anteriormente estaban reservados solo para las páginas AMP.

Es útil hacer un seguimiento de estas cifras en auditorías puntuales, pero aún más útil es observarlas a lo largo del tiempo para protegerse contra errores. Las herramientas de rendimiento como Calibre los cubren . New Relic lo tiene . SpeedCurve los rastrea .

El cambio de diseño acumulativo (CLS) es complicado. Ese es aquel en el que, por ejemplo, el sitio tiene un anuncio en la parte superior de un artículo. La solicitud de ese anuncio es asincrónica, por lo que es muy probable que el anuncio llegue tarde y reduzca el contenido del artículo. Eso no solo es molesto, sino que también es un verdadero problema para las métricas de rendimiento y, en última instancia, para el SEO.

El “Cambio de diseño acumulativo en la práctica” de Nic Jansma ofrece una inmersión profunda.

CLS no es simplemente “¿la página lo hace o no?” Hay una puntuación, como lo señala la ilustración anterior. Yo diría que 0 es un buen objetivo ya que no existe una versión de CLS que sea buena para nadie. Hay muchos matices en esto, como rastrearlo “sintéticamente” (por ejemplo, en un navegador sin cabeza, especialmente para herramientas de rendimiento) y con usuarios reales en su sitio real (que se llama RUM o Real User Metrics). Ambos son útiles.

Si tienes CLS con el que necesitas luchar, eso puede ser complicado. SpeedCurve tiene algunas herramientas nuevas que ayudan:

Para cada cambio de diseño, le mostramos el fotograma de la tira de película justo antes y después del cambio. Luego dibujamos un cuadro rojo alrededor de los elementos que se movieron, resaltando exactamente qué elementos causaron el cambio. La puntuación del cambio de diseño para cada turno también le ayuda a comprender el impacto de ese turno y cómo se suma a la puntuación acumulativa.

Eso haría que fuera bastante fácil desarraigar y arreglar, espero. Especialmente los complicados. No lo sabía, pero el CLS puede ser causado por cosas mucho más sutiles que Mark Zeman señala en la publicación. Por ejemplo:

• Un carrusel de imágenes que solo se mueve horizontalmente puede activar CLS . Parece una lástima, ya que es lo que se supone que deben hacer, pero aparentemente puedes engañarlo moviendo carruseles solo con CSS transform.
• Si tiene un área muy grande, es muy arriesgado mudarse. Si se mueve solo una pizca, afectará mucho a CLS .
• El destello de texto sin estilo ( FOUT ) es una causa de CLS . ¡Aunque eso es bueno para el rendimiento por otras razones! ¡22 capturas! Es una buena excusa para buscar fuentes alternativas perfectas .

Cosas difíciles pero importantes. Realmente necesito realizar pruebas de rendimiento en mi CI / CD , lo que realmente me ayudará con esto . Cada vez se siente más como si el rendimiento web fuera un subgénero profesional completo del desarrollo web. Los desarrolladores web front-end realmente necesitan entender estas cosas y ayudar hasta cierto punto, pero ya tenemos mucho que hacer .