Aprendizajes de una sesión de prueba de página web sobre trucos de CSS

Me reuní con Tim Kadlec de WebPageTest el otro día para realizar algunas pruebas de rendimiento en CSS-Tricks. Básicamente, utilice la herramienta, hurgue e identifique los puntos débiles de rendimiento en los que trabajar. Puede ver el video aquí mismo en el sitio o en su canal de Twitch , al que vale la pena suscribirse para ver más investigaciones de rendimiento como estas.

El trabajo de performance web es doble:

Paso 1) Mida las cosas y explore los problemas
Paso 2) Solucionelo

Tim y yo, a través de la increíble herramienta que es WebPageTest, hicimos gran parte del Paso 1. Tomé notas mientras husmeábamos. Encontramos una serie de áreas problemáticas, ¡algunas bastante grandes! Por supuesto, después de todo eso, no podía sacármelas de la cabeza, así que tuve que entrar en acción y hacer las cosas del Paso 2 tan pronto como pude, y estoy feliz de informar que he hecho la mayor parte de ellas. y noté una mejora. ¡Vamos a profundizar en!

Problema identificado #1) LCP deficiente

Largest Contentful Paint (LCP) es uno de los Core Web Vitals (CWV), que todo el mundo está observando atentamente en este momento y Google nos dice que es un factor de SEO. Mi LCP registraba 3,993 segundos, lo cual no es nada bueno.

Aprendí de Tim que es ideal si la Primera Pintura con Contenido (FCP) contiene el LCP. Pudimos ver que eso no estaba sucediendo a través de WebPageTest.

Cosas para arreglar:

• Asegúrese de que el área LCP, que en última instancia era una imagen grande, esté optimizada correctamente, tenga una interfaz responsiva srcsety esté alojada en CDN. Todas esas cosas estaban fallando en esa imagen en particular y despiro trabajar en otro lugar.
• La imagen del LCP tenía loading="lazy", y acabamos de enterarnos de que no es un buen lugar para eso.

Técnica de fijación y aprendizajes:

• Se implementaron todas las cosas adecuadas para el manejo de imágenes, pero por alguna razón, nada funciona para .gifarchivos, que es lo que era esa imagen el día de la prueba. De todos modos , probablemente no deberíamos usar .gifarchivos para esa área.
• Desactive la carga diferida de la imagen LCP. Esta es una imagen destacada de WordPress, así que básicamente tuve que hacer ?php the_post_thumbnail('', array('loading' = 'eager')); ?. Si fuera una imagen en línea, haría img data-no-lazy="1" ... /lo que le dice a WordPress lo que necesita saber.

Problema identificado #2) Primer byte para iniciar la brecha de renderizado

Tim vio esto de inmediato como un problema bastante obvio.

En la cascada de arriba (aquí hay un artículo súper detallado sobre la lectura de cascadas de Matt Hobbs), puedes ver que el HTML llega en aproximadamente 0,5 segundos, pero el inicio de la renderización (lo que la gente ve, gran línea verde ), no comienza hasta aproximadamente 0,5 segundos. 2,9 segundos. Eso es demasiado largo.

El gráfico también identifica el problema con una línea amarilla. Estaba vinculando a un archivo CSS de terceros, que luego redirige a mis propios archivos CSS que contienen fuentes personalizadas. Esa redirección cuesta tiempo y, a medida que profundizamos, no solo el tiempo de carga de la primera página, sino cada carga de una página, incluso las cargas de páginas en caché.

Cosas para arreglar:

• Elimina la redirección de archivos CSS.
• Fuentes autohospedadas.

Técnica de fijación y aprendizajes:

• De todos modos, he estado buscando algunas fuentes nuevas. No hace mucho noté que realmente me encanta la innovación en materia de licencias de Mass-Driver (con un precio por número de empleados), pero también me encanta MD Primer , así que lo compré. Para el tipo de cuerpo, me quedé con un serif cómodo con Blanco , que afortunadamente vino con versiones RIBBI ¹ muy bien optimizadas . La próxima vez, juro que buscaré una fuente variable, pero bueno, a veces debes seguir tu corazón. Los compré y ahora autohospedé los archivos de fuentes.
• Úselo @font-facedirectamente en mi propio CSS, sin redirecciones. También estoy usando font-display: swap;, pero tengo que trabajar un poco más en esa técnica de carga . No puedo esperar size-adjust.

Después de volver a realizar la prueba con el cambio implementado, puede ver en una página de artículo grande que el procesamiento inicial es 2 segundos más rápido en una conexión 4G:

Problema identificado n.º 3) CLS en la guía de cuadrícula es incorrecto

Tim tenía un buen truco bajo la manga para medir el cambio de diseño acumulativo (CLS) en las páginas. Puede indicarle a WebPageTest que se desplace hacia abajo en la página. Esto es importante para algo como CLS, porque el cambio de diseño puede ocurrir debido al desplazamiento.

Consulte este artículo sobre CLS y WebPageTest.

El truco consiste en utilizar una configuración avanzada para inyectar JavaScript personalizado en la página durante la prueba:

En este punto, no estábamos probando la página de inicio, sino una página muy importante: nuestra Guía completa de Grid . Con esto en su lugar, se puede ver que el CWV está en mucho peor situación:

No sé qué pensar exactamente sobre el LCP. Esto se debe a lo que resulta ser la imagen más grande bastante al final de la página.

El CLS es más preocupante para mí, porque cualquier diseño cambiante siempre es desagradable para los usuarios. ¿Ves todas estas líneas punteadas de color naranja? Eso es CLS sucediendo:

Things to fix:

• CLS is bad because of lazy loaded images coming in and shifting the layout.

Fixing technique and learnings:

• I don’t know! All those images are inline img ... elements. I get that lazy loading could cause CLS, but these images have proper width and height attributes, which is supposed to reserve the exact space necessary for the image (even when fluid, thanks to aspect ratio) even before it loads. So… what gives? Is it because they are SVG?

If anyone does know, feel free to hit me up. Such is the nature of performance work, I find. It’s a mixture of easy wins from silly mistakes, little battles you can fight and win, bigger battles that sometimes involves outside influences that are harder to win, and mysterious unknowns that it takes time to heal. Fortunately we have tools like WebPageTest to tell us the real stories happening on our site and give us the insight we need to fight these performance battles.

---

1. RIBBI, I just learned, means Regular, Italic, Bold, and Bold Italic. The classic combo that most body copy on the web needs. ⮑