Saltar al contenido
en línea
esv0.46.1 · 1d135e2

Un sitio web rápido que sigue siéndolo

Hacer que un sitio web sea rápido una vez es fácil. Mantenerlo rápido mientras se añaden funciones es lo difícil: cada componente, fuente o biblioteca hace la página algo más pesada. Por eso convertimos la velocidad en una prueba que debe superar cada cambio, no en una auditoría puntual.

Ilustración: cuatro indicadores de puntuación en 100 sobre un gráfico en el que las primeras mediciones superan la línea del presupuesto y el resto se mantiene por debajo.

Hacer que un sitio web sea rápido una vez es fácil. Lo difícil es mantenerlo rápido mientras se siguen añadiendo funciones: cada nuevo componente, fuente o biblioteca hace la página un poco más pesada, y nadie lo nota hasta que el sitio se siente lento. Por eso dejamos de tratar la velocidad como una auditoría puntual y la convertimos en una prueba que cada cambio tiene que superar.

El punto de partida

Cuando medimos este sitio en serio por primera vez, la maquetación saltaba al cargar (un Cumulative Layout Shift de alrededor de 0,2) y el contenido principal tardaba de 4 a 6 segundos en aparecer con una conexión móvil limitada. La hoja de estilos principal pesaba 41 KB comprimida, sobre todo porque a los visitantes también se les enviaban componentes y código de validación pensados para el área de administración.

Qué cambiamos

  • Los visitantes reciben solo código para visitantes. La biblioteca de interfaz de la administración y la de validación de formularios ya no llegan al sitio público. Una prueba recorre los imports del sitio y falla si alguna de ellas vuelve a colarse.
  • CSS solo para lo que hay en la página. La hoja de estilos principal pasó de 296 KB a 98 KB, y a 16 KB comprimida.
  • Fuentes que no desplazan la maquetación. Las fuentes clave se precargan y la página ya no precarga código que quizá nunca necesite.

La prueba que lo mantiene así

En cada pull request, la CI compila el sitio, lo sirve como lo hace producción —HTTP/2, TLS, compresión— y ejecuta Lighthouse tres veces en cuatro páginas clave, quedándose con la mediana. El presupuesto: todas las puntuaciones de al menos 95, el contenido más grande visible en menos de 2 segundos, un desplazamiento de la maquetación inferior a 0,1 y un bloqueo del hilo principal inferior a 200 ms. Si un cambio rompe el presupuesto, la CI se pone en rojo y el cambio no se fusiona. En paralelo se ejecuta una comprobación de accesibilidad que actualmente no encuentra infracciones de WCAG AA en las páginas que cubre.

El resultado

En la CI, las páginas obtienen 100 en las cuatro categorías de Lighthouse, con el contenido principal visible en menos de un segundo. En el sitio en producción, la página de inicio obtiene 100 con el contenido principal en unos 1,2 segundos, y una página de producto obtiene 98.

También somos sinceros con lo que aún no es perfecto: las páginas en japonés y en otros idiomas CJK son más lentas, porque sus fuentes son mucho más grandes. Eso tiene su propia tarea.

Por qué le importa

Una página lenta pierde visitantes antes de que lean una sola palabra, y los buscadores también lo notan. Si crea con nosotros una landing page o una tienda, este presupuesto va incluido: forma parte de nuestra manera de trabajar, no es un extra.

Hablemos de su sitio