Me reuní con Tim Kadlec de más en WebPageTest el otro día para hacer algunas pruebas de rendimiento en CSS-Tricks. Básicamente, use 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 más investigaciones de rendimiento como estas.
El trabajo de rendimiento web es doble:
Paso 1) Mida las cosas y explore los problemas
Paso 2) Arreglarlo
Tim y yo, a través de la increíble herramienta que es WebPageTest, hicimos mucho del Paso 1. Tomé notas mientras hurgamos. Encontramos varias áreas problemáticas, ¡algunas bastante grandes! Por supuesto, después de todo eso, no podía sacarlos de mi 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 y ha visto una mejora. ¡Vamos a profundizar en!
Problema identificado n. ° 1) LCP deficiente
La pintura de contenido más grande (LCP) es uno de los elementos fundamentales de la web (CWV), que todos están observando con atención en este momento y Google nos dice que es un factor de SEO. Mi LCP estaba registrando 3.993s, lo cual no es genial.
WebPageTest le dice claramente si hay problemas con su CWV.
Aprendí de Tim que es ideal si First Contentful Paint (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 de LCP, que en última instancia era una imagen grande, esté optimizada correctamente, tenga una respuesta
srcsety está alojado en CDN. Todas esas cosas estaban fallando en esa imagen en particular, a pesar de trabajar en otra parte. - La imagen de LCP tenía
loading="lazy"en él, que acabamos de aprender no es un buen lugar para eso.
Técnica de fijación y aprendizajes:
- Todo el material adecuado para el manejo de imágenes estaba en su lugar, pero por alguna razón, ninguno de ellos funciona para
.gifarchivos, que es lo que era esa imagen el día de la prueba. Probablemente no deberíamos usar.gifarchivos para esa área de todos modos. - Desactive la carga diferida de la imagen LCP. Esta es una imagen destacada de WordPress, así que esencialmente tuve que hacer
<?php the_post_thumbnail('', array('loading' => 'eager')); ?>. Si fuera una imagen en línea, haría<img data-no-lazy="1" ... />que le dice a WordPress lo que necesita saber.
Problema identificado n. ° 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), puede ver que el HTML llega en aproximadamente 0.5 segundos, pero el inicio de la renderización (lo que la gente ve, grande verde línea), no comienza hasta aproximadamente 2,9 segundos. Eso es demasiado largo.
El cuadro también identifica el problema con una línea amarilla. Estaba enlazando a un archivo CSS de terceros, que luego redirige a mis propios archivos CSS que contienen fuentes personalizadas. Esa redirección cuesta tiempo y, como analizamos, no solo el tiempo de carga de la primera página, sino cada carga de la página, incluso las cargas de la página almacenada 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 mirando algunas fuentes nuevas. No hace mucho noté que realmente me encanta la innovación de licencias de Mass-Driver (precio por número de empleados), pero también amo MD Primer, así que lo compré. Para el tipo de cuerpo, me quedé con un cómodo serif con Blanco, que afortunadamente vino con versiones RIBBI1 muy bien optimizadas. La próxima vez te juro que encontraré una fuente variable, pero oye, a veces tienes que seguir tu corazón. Compré estos, y ahora soy yo mismo alojando los archivos de fuentes.
- Usar
@font-facedirectamente en mi propio CSS, sin redireccionamientos. También usandofont-display: swap;, pero tengo que trabajar un poco más en esa técnica de carga. No puedo esperarsize-adjust.
Después de volver a probar con el cambio en su lugar, 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:
Eso es un gran cambio. Especialmente porque también afecta a las cargas de páginas almacenadas en caché.
Vea cómo la cascada retrocede hacia la izquierda sin la redirección CSS.
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, estábamos probando no la página de inicio, sino a propósito una página muy importante: nuestra Guía completa de Grid. Con esto en su lugar, puede ver que los CWV están en mucho peor estado:
No sé qué pensar exactamente sobre el LCP. Eso está siendo provocado por lo que resulta ser la imagen más grande bastante abajo en la página.
No estoy muy preocupado por el LCP con el desplazamiento en su lugar. Esa es solo una imagen como cualquier otra en la página, cargada con pereza.
El CLS es más preocupante para mí, porque cualquier diseño cambiante siempre es desagradable para los usuarios. ¿Ves todas estas líneas naranjas punteadas? Eso es CLS sucediendo:
Las líneas naranjas de CLS se correlacionan con la carga de imágenes (a medida que la página se desplaza hacia abajo y aparecen las imágenes cargadas de forma diferida).
Cosas para arreglar:
- CLS es malo debido a que las imágenes cargadas de forma diferida entran y cambian el diseño.
Técnica de fijación y aprendizajes:
- ¡No sé! Todas esas imágenes están en línea
<img loading="lazy" ...>elementos. Entiendo que la carga diferida podría causar CLS, pero estas imágenes tienenwidthyheightatributos, que se supone que reserva el espacio exacto necesario para la imagen (incluso cuando es fluida, gracias a la relación de aspecto) incluso antes de que se cargue. Entonces … ¿qué pasa? ¿Es porque son SVG?
Si alguien lo sabe, no dude en pegarme. Esa es la naturaleza del trabajo escénico, me parece. Es una mezcla de victorias fáciles de errores tontos, pequeñas batallas que puedes pelear y ganar, batallas más grandes que a veces involucran influencias externas que son más difíciles de ganar y misteriosas incógnitas que lleva tiempo curar. Afortunadamente, tenemos herramientas como WebPageTest para contarnos las historias reales que suceden en nuestro sitio y darnos la información que necesitamos para librar estas batallas de rendimiento.
- RIBBI, acabo de aprender, significa regular, cursiva, negrita y negrita cursiva. El combo clásico que necesita la mayoría de los textos corporales en la web. ⮑