100 puntos en PageSpeed: qué cambiamos para conseguirlo

El valor de partida era 58 sobre 100 en móvil. No es un valor malo para una web con efecto 3D en la cabecera, pero sí uno que Google penaliza de forma perceptible en la búsqueda móvil. Al final quedaron 100 puntos en escritorio y 98 en móvil, con 100 también en accesibilidad.

Lo que sigue no es una lista de comprobación general, sino el recorrido real, incluidos los puntos en los que nos equivocamos.

La situación de partida

Las cinco intervenciones que de verdad contaron

1. Sustituir la biblioteca, no optimizarla

La cabecera muestra una nube de partículas en 3D. Para ello funcionaba una biblioteca gráfica conocida: 458 KB tras la minificación. La medición señalaba que 51 KB de ellos no se ejecutaban nunca.

La mirada decisiva fue la pregunta de cuánto necesitábamos realmente. Eran once piezas: renderizador, escena, cámara, geometría, material y algunas clases auxiliares. Todo eso se puede programar directamente contra la interfaz gráfica del navegador.

Resultado: 458 KB se convirtieron en 6 KB. La representación es idéntica: mantuvimos los mismos sombreadores.

2. La compresión estaba solo a medias

En la configuración del servidor la compresión estaba en «activada», pero la línea que indica qué tipos de archivo deben comprimirse estaba comentada. Esa es la configuración por defecto de muchas distribuciones. Resultado: solo se comprimía HTML.

La biblioteca gráfica iba, por tanto, sin comprimir por la línea. Tras activarla: 1243 KB se convirtieron en 251 KB. Además, ahora dejamos al lado las versiones comprimidas precalculadas, para que el servidor no vuelva a calcular en cada petición.

Esfuerzo: dos líneas de configuración. Efecto: casi un megabyte por primera visita.

3. Eliminar del todo la biblioteca de animación

Para las apariciones al desplazarse funcionaba otra biblioteca, 114 KB. La medición la señalaba además como causante de recálculos forzados de maquetación: consultaba la geometría durante el desplazamiento y obligaba al navegador a recalcular la maquetación en plena marcha.

Sustituida por un IntersectionObserver que se limita a poner una clase. El movimiento en sí lo hace el CSS. 114 KB menos, sin recálculos, unas 40 líneas de código propio.

4. El favicon pesaba 205 KB

Una nimiedad con un efecto asombroso, porque se carga muy pronto. Sustituido por un archivo SVG de 6 KB, generado a partir del logotipo existente.

5. Consultar la geometría en el fotograma de animación

Un script leía en cada evento de desplazamiento la altura total del documento. Esa propiedad el navegador no la puede responder de memoria: para ello tiene que recalcular la maquetación de toda la página, en pleno desplazamiento.

La regla que se deriva y que vale en todas partes: leer en el evento, escribir en el fotograma siguiente. Nunca al revés. Desde entonces, la altura de la página se mide una vez y se recuerda en lugar de consultarse sesenta veces por segundo.

El error que costó 24 puntos

Lo que aportó poco

Para ser completos, las medidas que aparecen en cualquier guía y que en nuestro caso apenas fueron medibles:

Formatos de imagen. Nuestra página de inicio apenas tiene imágenes: el logotipo es un archivo SVG. Donde hay imágenes, la conversión compensa, claro; como palanca principal solo sirve en páginas con mucha imagen.

Reducir más las tipografías. Alojamos dos familias tipográficas nosotros mismos y precargamos las necesarias en la zona visible. Una optimización adicional sería posible, pero no mueve el valor.

Ubicación del servidor. Muy recomendada, en nuestro caso irrelevante: el tiempo hasta el primer byte ya estaba en 20 milisegundos. Quien ya anda bien ahí no gana nada con una red de distribución.

El procedimiento para repetirlo

1. Medir antes de cambiar nada. Móvil y escritorio por separado, anotando los valores.
2. Buscar el archivo transferido más grande. Casi siempre es JavaScript. La pregunta no es cómo reducirlo, sino si hace falta.
3. Revisar la compresión. No si está activada, sino para qué tipos de archivo.
4. Contar las peticiones bloqueantes. Cada hoja de estilos en la cabecera retiene el primer renderizado.
5. Comprobar los saltos de maquetación sin limitar la conexión. La única prueba que nos faltó.
6. Volver a medir tras cada cambio. Si no, al final no se sabe qué ha surtido efecto.

Ayúdame a traducir el informe de PageSpeed de mi página en un
orden de actuación. Sé estricto; no elogies nada.

Mis mediciones:
- Móvil: [puntuación], escritorio: [puntuación]
- LCP, TBT, CLS por dispositivo: [valores]
- Archivos transferidos mayores con su tamaño: [lista]
- Peticiones que bloquean el renderizado: [lista]
- Avisos del informe: [insertar texto]

Sobre la página:
- Cómo está construida: [CMS / estática / constructor]
- ¿Hace falta JavaScript para el contenido visible? [sí/no]
- ¿Cómo se entrega el CSS? [externo / por adelantado /
  parcialmente por adelantado]

Tareas:
1. Asigna cada aviso a una causa y di a qué métrica afecta:
   LCP, TBT o CLS.
2. Ordena las medidas por efecto por unidad de esfuerzo. Di en
   cada una cuántos puntos mueve de forma realista y por qué.
3. Nombra las medidas del informe que con mi tipo de
   construcción no aportan prácticamente nada, y justifícalo en
   lugar de omitirlas sin más.
4. Con cada archivo grande de JavaScript, pregunta primero si
   hace falta antes de proponer reducirlo.
5. Advierte si el CSS solo se entrega en parte por adelantado, y
   explica por qué eso puede ser peor para el CLS que no hacerlo.
6. Nombra qué debería volver a medir tras cada cambio.

No inventes mediciones.

Conclusión

La puntuación en sí no es el objetivo: es una medición, no un resultado de negocio. Lo que cuenta es la experiencia que hay detrás: una página legible a los 1,4 segundos la lee más gente que una que tarda seis segundos. En visitantes móviles con datos, la diferencia es mayor que cualquier optimización de texto.

El camino hasta ahí pasó en nuestro caso por una única pregunta recurrente: ¿necesitamos esto? Cinco de seis intervenciones consistieron en quitar algo, no en añadirlo.

Preguntas frecuentes