121 mediciones Core Web Vitals: dos hipótesis rechazadas
Concatenar CSS empeoró el TBT de 76 a 372 ms. Diferir AJAX de 64 a 265 ms. El verdadero culpable era el stack publicitario. Informe de 9 series de mediciones.
👁 117 lecturas
Optimizamos este sitio durante varios días, haciendo una serie de mediciones de Lighthouse después de cada cambio en lugar de una sola ejecución. El resultado fue humillante: dos de nuestras mejores hipótesis resultaron ser perjudiciales, y solo encontramos al verdadero culpable cuando dejamos de confiar en un único resultado. 121 mediciones en nueve series. Esto es lo que descubrimos.
Tres conclusiones en un párrafo
1. Una sola medición de Lighthouse no significa nada - la misma URL nos dio resultados de 60 a 96 puntos sin ningún cambio en el código. 2. Concatenar archivos CSS en uno solo, el consejo de cada tutorial, empeoró el TBT de 76 a 372 ms. 3. El culpable de la dispersión no era nuestro código, sino el stack publicitario - tras bloquear dominios publicitarios el resultado se estabilizó en 77/77 con una dispersión de FCP del 0,7% en lugar del 22%.
Lista actual de cursos de IA
Recopilación actualizada automáticamente una vez al día: precios, número de clases y valoraciones directamente del catálogo del vendedor. Novedades y bestsellers arriba.
Abrir recopilación →
Regla cero: mide series, no ejecuciones individuales
Suena obvio, pero casi nadie lo hace - y por eso casi todas las «optimizaciones» en internet son casualidad.
Ejecutamos Lighthouse diez veces seguidas en una URL sin cambios. Los resultados variaron de 60 a 96 puntos. Si hubiéramos cambiado algo en el código y obtenido una ejecución de 96 después del cambio y 60 antes, habríamos declarado el éxito. Si hubiera salido al revés, habríamos revertido una buena corrección.
Consejo profesional: mínimo cinco ejecuciones por variante, compara medianas y siempre indica el rango completo. Si los rangos antes y después se superponen, no tienes un resultado - tienes ruido.
Hipótesis 1, rechazada: concatenar CSS en un solo archivo
El consejo clásico: menos peticiones HTTP, así que combina las hojas de estilo. Construimos un paquete con varios archivos CSS del tema, verificamos la corrección de las rutas relativas y el orden de las importaciones, lo desplegamos. Medición:
| Indicador en página de entrada | Antes | Después de concatenar |
|---|---|---|
| TBT (bloqueo del hilo principal) | 76 ms | 372 ms |
| Tiempo styleLayout | 700 ms | 1018 ms |
Por qué no funcionó: cinco hojas de estilo separadas son cinco tareas cortas de análisis que el navegador puede intercalar con otras. Una hoja de estilo de 69 KB es una tarea larga que no se puede interrumpir - y las tareas largas son exactamente lo que mide el TBT. Redujimos el número de peticiones y empeoramos la sensación de fluidez.
Consejo profesional: con HTTP/2 el número de peticiones dejó de ser un problema. Concatenar archivos es un consejo de los tiempos de HTTP/1.1 y hoy puede perjudicar.
Hipótesis 2, rechazada: diferir peticiones en segundo plano
La página de la tienda enviaba varias peticiones AJAX al inicio. Las diferimos mediante requestIdleCallback con un límite de tiempo de 3000 ms - la solución de manual. Medición:
- TBT de la tienda: 64 ms → 265 ms
- El inicio de las peticiones se desplazó del intervalo 183-1329 ms a 383-2411 ms
Por qué no funcionó: el límite de tiempo de 3000 ms hizo que el navegador ejecutara todas las peticiones diferidas en una sola serie - y exactamente en la ventana en la que se cuenta el TBT. En lugar de distribuir el trabajo, lo concentramos en un solo cuello de botella.
Consejo profesional: requestIdleCallback con un límite de tiempo corto no es «hazlo más tarde». Es «hazlo más tarde, pero seguro». Sin límite o con uno muy largo se comporta de manera diferente.
Qué funcionó y por qué
Una línea que eliminó 70 ms de recálculo forzado del layout
El script leía la posición de un elemento e inmediatamente la cambiaba. Esto causa un recálculo forzado del layout - el navegador debe interrumpir todo y calcular la geometría de la página. Lighthouse indicaba 70-75 ms en una sola línea.
La corrección es una línea:
if (window.requestAnimationFrame) requestAnimationFrame(lugar); else lugar();
La lectura se traslada al momento en que el navegador de todos modos recalcula el layout. El coste cae a cero, y el código hace exactamente lo mismo.
Eliminar de la ruta crítica lo que la página no usa
La hoja de estilos de plantillas pesaba 75 094 bytes y se cargaba en cada subpágina, a pesar de que la mayoría de las páginas no usan ninguna de esas plantillas. La versión básica son 9 708 bytes - es decir, el 87% del peso era innecesario. Lo mismo con jQuery, cargado a pesar de no tener ningún consumidor.
Consejo profesional: antes de empezar a minificar, verifica si el archivo es siquiera necesario en esa página. La eliminación supera a la compresión cualquier día.
El verdadero culpable: el stack publicitario
Después de rechazar ambas hipótesis hicimos otra pregunta: de dónde viene la dispersión de 60-96 puntos. Bloqueamos los dominios publicitarios y de consentimiento y repetimos la serie:
| Con anuncios | Sin anuncios | |
|---|---|---|
| Puntuación de rendimiento | 60-96, bipolar | estable 77/77 |
| Dispersión FCP | 22% | 0,7% |
| TBT | variable | 0 |
| Peso del stack | 445-467 KB | |
La conclusión fue brutal: durante varios días optimizamos código que era responsable de una fracción del problema. La dispersión provenía de scripts externos sobre los que no tenemos control y que no podemos eliminar porque financian el sitio.
Consejo profesional, el más importante de todo el texto: antes de optimizar cualquier cosa, mide cuánto del resultado proviene de ti y cuánto de scripts externos. Haz una serie con dominios de terceros bloqueados. Si la diferencia es grande, tu techo real está mucho más bajo de lo que piensas - y es mejor saberlo antes de tres días de trabajo que después.
Dos trampas de herramientas que encontramos de paso
Pingdom puede mentir sobre la compresión
El informe afirmaba que el servidor no comprimía las respuestas. Verificamos directamente: el servidor envía br y zstd, y cuando se solicita explícitamente gzip, devuelve la página principal en 71 306 bytes en lugar de 289 394 sin comprimir. La herramienta simplemente no declaraba soporte para algoritmos más nuevos. Los encabezados de expiración también estaban en su lugar.
Limpiar toda la caché puede estropear la apariencia
El plugin limpiaba en cada publicación toda la caché junto con los archivos CSS minificados. En la ventana entre el borrado y la reconstrucción la página enlazaba a una hoja de estilo que no existía - y durante un momento se mostraba como HTML puro. Con una docena de entradas diarias esto ocurría regularmente.
Consejo profesional: después de publicar una entrada limpia puntualmente - solo la entrada, la página principal, sus categorías y el feed RSS. Un nuevo artículo no cambia el contenido del archivo CSS, así que no hay razón para borrarlo.
Lista de verificación si quieres repetir esto en tu sitio
- Haz diez mediciones en una página sin cambios. Anota la mediana y el rango. Ese es tu ruido.
- Repite la serie con dominios externos bloqueados. La diferencia es el techo de tus posibilidades.
- Solo entonces cambia una cosa a la vez y mide en serie, no con una sola ejecución.
- Si los rangos antes y después se superponen - revierte el cambio. La falta de prueba no es prueba.
- Empieza eliminando, no minificando. Un archivo que no existe siempre es el más rápido.
- Busca recálculos forzados del layout. Pueden valer 70 ms por una línea de corrección.
De dónde vienen estos números
Todos los valores provienen de 121 mediciones de Lighthouse en nueve series, realizadas en este sitio los días 18-19 de septiembre de 2026 en cuatro tipos de páginas: principal, entrada, reseña y tienda. Ambas hipótesis rechazadas fueron desplegadas en producción, medidas y revertidas. Esto no es una recopilación de consejos ajenos - es un informe de lo que funcionó y lo que no funcionó en nuestro caso.
More on this from FULGOR
revista·El modelo se niega a leer documentos: prueba en tres proveedoresPrueba de contexto mostró content_filter para cada documento superior a ~2000 tokens en AWS, API del fabricante y Google. Incluso con texto sobre plantas.