← Casos Velocidad 16–22 oct 2026 · PageBrick 1.8.0 y tema 2.2.0
Del informe de PageSpeed a la solución
pagebrick.org funciona con PageBrick, así que su informe de PageSpeed es el informe del propio producto. En menos de una semana la nota en el móvil pasó de 95 a 98 y la mayor queja desapareció, medida de la misma forma en la misma página. Dos números secundarios empeoraron, y también están en este caso.
- 98Rendimiento en el móvil, antes 95 (PageSpeed Insights, 16 → 22 oct 2026)
- 2,2 sMayor elemento de la página (LCP) en el móvil, antes 2,9 s
- 410 → 0KiB que el navegador descargaba de nuevo en cada visita (la queja del caché, en el móvil)
- 176 → 59KiB de ahorro aún sugerido en imágenes, en el móvil
El problema
El 16 de octubre de 2026 el sitio sacó 100 en el ordenador y 95 en el móvil. El informe señalaba tres cosas: los archivos estáticos llegaban sin tiempo de caché (410 KiB descargados de nuevo en cada visita, en el móvil), la foto del destacado se enviaba con 1400 × 1045 píxeles y se mostraba con 372 × 278 (165 KiB), y ninguna imagen tenía srcset. Una parte era del tema y otra del núcleo, así que arreglar solo uno de los lados no bastaba.
La decisión
Dos etapas, primero el tema. Etapa 1, tema 2.2.0: cada imagen recibió copias más pequeñas con srcset; la primera imagen de la página se pide primero; la animación de entrada que la ocultaba cerca de un segundo ahora se mueve en lugar de desvanecerse; las dos fuentes se piden junto con la página; y la fuente con serifa se redujo de 132 KB a 86 KB.
Etapa 2, PageBrick 1.8.0: un botón en Configuración escribe las líneas de caché del navegador al final del .htaccess (un año para los archivos cuya dirección cambia cuando cambia el archivo, una semana para el resto), y cada foto nueva guarda una copia de 960 píxeles.
La promesa a los sitios que ya existen decidió los detalles. El HTML que un tema ya imprime no puede cambiar, así que el srcset es algo que el tema pide (img(sizes: …)), nunca algo que el núcleo añade. Y como una actualización nunca toca el .htaccess, los sitios instalados antes reciben el caché con un botón, que comprueba el sitio después y quita las líneas solo si el hosting responde con un error.
La prueba
Antes de publicar, una instalación nueva se midió con Lighthouse: con las líneas de caché apagadas, el informe señalaba 9 archivos (240 KiB); con ellas encendidas, esa auditoría pasó. En un móvil de 375 píxeles con doble densidad, el navegador eligió la copia de 960 píxeles: 8,6 KB en lugar de 19,7 KB en la foto de prueba. La actualización de la 1.7.1 a la 1.8.0 se ejecutó en un navegador real, 31 de 31 comprobaciones, incluido pulsar el botón del caché en un sitio instalado antes y apagarlo de nuevo para que el .htaccess volviera byte a byte. Después el sitio en línea se midió otra vez con la misma herramienta.
El resultado
El 22 de octubre la nota en el móvil era 98 (antes 95) y el mayor elemento de la página tardaba 2,2 s (antes 2,9 s). La queja del caché desapareció, y la de las imágenes bajó de 176 KiB a 59 KiB en el móvil. En el ordenador la nota siguió en 100.
No todo mejoró. En el móvil, el primer elemento visible (FCP) pasó de 0,9 s a 1,1 s y el Speed Index de 2,1 s a 3,3 s; en el ordenador, el mayor elemento pasó de 0,4 s a 0,5 s y el Speed Index de 0,7 s a 1,1 s. PageSpeed varía de una medición a otra, así que la lectura justa es: lo que más importa aquí (mayor elemento, caché, peso de las imágenes) fue en la dirección correcta, algunas métricas secundarias fueron en la contraria, y los próximos puntos de la lista son 5 KiB de CSS y una animación que no está compuesta.
Qué quedó
Un informe de velocidad solo sirve como prueba si la misma prueba se hace antes y después, en la misma página, y los números que empeoraron también se publican.