Hacia dónde va el rendimiento web

Esta es la lección con más probabilidad de envejecer mal del track, así que está escrita con una regla estricta: lo que se afirma como hecho está comprobado contra la fuente primaria y lleva su fecha, y lo que no se ha podido confirmar aparece marcado como discusión abierta. Hay bastante menos de lo primero de lo que sugiere el ruido del sector, y bastante más de lo segundo. Con esa separación hecha, se puede decir algo útil sobre qué va a cambiar en el trabajo de los próximos años y, más importante, qué no.

Lo que ha cambiado de verdad

Las navegaciones blandas dejaron de ser un punto ciego. La arquitectura de aplicación de una sola página nunca ha estado bien cubierta por las Core Web Vitals: el navegador solo veía una carga de página, y todo lo que ocurría después quedaba atribuido a esa primera carga. Es el límite que de dónde salen los umbrales y qué no capturan señalaba desde el nivel 2. Chrome ha estabilizado una definición de navegación blanda con tres condiciones —la inicia una acción del usuario, produce un cambio de URL visible, y produce un pintado visible— y desde Chrome 151, cuya rama estable empezó a desplegarse a finales de julio de 2026, la funcionalidad está disponible sin banderas.

Lo que aparece en la práctica son dos tipos de entrada nuevos. Una entrada soft-navigation con la URL nueva, un navigationId propio y el interactionId de la interacción que la provocó; y entradas interaction-contentful-paint que permiten medir el pintado del elemento más grande de esa navegación. Además, navigationId se añade a las entradas de las métricas existentes, de modo que se pueden trocear por navegación en lugar de acumularlas durante toda la vida de la pestaña.

// Deteccion de soporte y observacion de navegaciones blandas.
if (PerformanceObserver.supportedEntryTypes.includes('soft-navigation')) {
  new PerformanceObserver((lista) => {
    for (const nav of lista.getEntries()) {
      console.log('navegacion blanda', {
        url: nav.name,
        navigationId: nav.navigationId,
        interactionId: nav.interactionId,
        inicio: Math.round(nav.startTime),
      });
      // Aqui se finalizan y envian las metricas de la URL anterior,
      // y se reinicia la medicion para la nueva.
    }
  }).observe({ type: 'soft-navigation', buffered: true });
}

Dos detalles que ahorran errores de interpretación. Los tiempos siguen siendo relativos a la navegación dura inicial, así que hay que restar el startTime de la navegación blanda para obtener un tiempo comparable con el de una carga normal. Y el tiempo hasta el primer byte se reporta como cero para las navegaciones blandas, igual que para las restauraciones desde la caché de retroceso, porque la pregunta no tiene una respuesta razonable cuando el contenido ya estaba en el cliente.

La librería oficial de medición admite este modo desde su versión 6.0.0, con una opción que hace que las mismas funciones informen también por navegación blanda, y recomienda medir por los dos métodos a la vez durante la transición: por navegación dura, para comparar con el histórico y con los navegadores que no lo soportan, y por navegación blanda, para lo nuevo. Eso duplica el volumen de datos que envías, así que conviene decidirlo antes y no después, y revisar de paso lo que ya tengas montado según instrumentar con la librería web-vitals y enviar los datos.

Las métricas salieron de un solo motor. Con la publicación de Safari 26.2 el 12 de diciembre de 2025, el pintado del elemento más grande y la interacción hasta el siguiente pintado pasaron a estar disponibles en los tres motores principales, como parte del proyecto de interoperabilidad de 2025. Es el cambio más importante del año para cualquiera que tenga tráfico de iOS, porque hasta entonces esa población era un agujero completo en los datos de campo.

Tres matices que hay que conocer antes de comparar números entre navegadores:

• El conjunto de datos público sigue siendo solo de Chrome. Los datos de otros navegadores no lo alimentan, y eso no va a cambiar; tampoco entran los usuarios de Chrome en iOS, que usan el motor de Safari. La ampliación te sirve en tu instrumentación propia, no en la cifra pública, así que la distinción de campo y laboratorio se complica con una tercera categoría: tu campo, que ahora es más ancho que el campo público.
• El instante final no es el mismo. Chrome mide el pintado del elemento más grande hasta el momento de presentación en pantalla; Firefox y Safari, hasta el instante de pintado, que es anterior. Son milisegundos de diferencia, pero son sistemáticos. Desde Chrome 145 también se expone el instante de pintado para poder comparar de igual a igual.
• El desplazamiento acumulado sigue siendo solo de Chromium. Se propuso para el proyecto de interoperabilidad de 2026 y no entró en la lista final, que tiene veinte áreas de foco y cuatro investigaciones. Si tienes mucho tráfico de Safari, hoy no puedes medir tu CLS real en esa población.

Lo que está en prueba y puede no llegar

Aquí la regla es literal: son pruebas de campo, sus responsables dicen explícitamente que pueden cambiar o no seguir adelante, y construir sobre ellas es una apuesta.

Especulación que se detiene antes de ejecutar scripts. Desde enero de 2026 hay una prueba de origen, a partir de Chrome 144, para una opción intermedia entre las dos que ya existían. La preobtención trae solo el documento; el prerenderizado completo trae los subrecursos y ejecuta JavaScript, con lo que eso implica: analíticas que se disparan sin que el usuario haya navegado, estado que se queda viejo, complejidad de implementación. La opción nueva descarga el documento, empieza a renderizar y trae los subrecursos, pero pausa el analizador al encontrar un <script> bloqueante y espera a que el usuario navegue de verdad. Los scripts con async o defer se descargan pero no se ejecutan hasta la activación.

La propiedad interesante es que en el caso bueno —una página sin scripts bloqueantes en la cabecera— se prerenderiza entera sin ejecutar nada, y en el caso malo el escáner de precarga ya ha traído los subrecursos. Pero el anuncio dice con todas las letras que el objetivo de la prueba es decidir si es algo que deba añadirse a la plataforma. Trátalo como una hipótesis con datos, no como una técnica.

Compresión con diccionario compartido. Permite comprimir una respuesta contra una versión anterior o contra un diccionario declarado, en lugar de contra sí misma, y es especialmente eficaz con paquetes de JavaScript que cambian poco entre despliegues. Está disponible en navegadores basados en Chromium desde su versión 130. Fuera de Chromium no me consta que haya llegado a una versión estable; lo que he podido confirmar es que el trabajo está en curso, no que esté disponible. Como es una mejora progresiva que los navegadores que no la entienden ignoran, el riesgo de adoptarla es bajo, pero el beneficio hoy solo lo ve una parte de tu tráfico. El contexto está en diccionarios compartidos y compresión delta.

Lo que el proyecto de interoperabilidad de 2026 sí ha aceptado y toca directamente al rendimiento: las transiciones de vista entre documentos, el atributo que bloquea el renderizado hasta que un recurso está listo, la pista que bloquea el renderizado hasta que un elemento concreto existe en el documento, la API de navegación, las animaciones dirigidas por scroll y el anclaje del scroll. Es una lista de convergencia, no de novedades: significa que estas cosas van a comportarse igual en los tres motores, que es la condición para poder usarlas sin ramificar. El formato de imagen JPEG XL sigue siendo solo una investigación, así que el mapa de los cuatro formatos no cambia todavía.

Las estrategias de render

Aquí es donde más ruido hay y menos hechos comprobables, así que conviene separar con cuidado.

Lo que ha cambiado de sitio es la plataforma, no los frameworks. Los mecanismos que el track cubre en el nivel de hidratación —hidratación parcial, progresiva, resumibilidad y arquitectura de islas— dejaron de ser propuestas hace años y hoy están implementados en herramientas de uso general. Lo nuevo de 2026 no es que existan, sino que el navegador está incorporando piezas que antes había que emular en JavaScript: transiciones entre documentos sin convertir el sitio en una aplicación de una sola página, control declarativo de cuándo se produce el primer pintado, y una API de navegación común.

Ese control declarativo del primer pintado merece un comentario, porque invierte el consejo por defecto del track. Todo lo anterior empuja a pintar cuanto antes; el atributo que bloquea el renderizado hasta que un elemento existe hace justo lo contrario, a propósito. La razón es que una transición entre documentos con un primer pintado a medias produce un parpadeo peor que la espera, y que retrasar cincuenta milisegundos el pintado para que el elemento del LCP sea el definitivo puede dar un LCP mejor que pintar antes un elemento que va a ser sustituido. Es un caso en el que la aritmética manda sobre la regla, y hay que medirlo, no suponerlo: el marco para hacerlo son las cuatro subpartes del LCP.

Lo que no puedo afirmar es cuál de las estrategias se impone. El árbol de decisión de las cuatro estrategias sigue dando las mismas respuestas que hace dos años porque depende del contenido y no de la tecnología, y no he encontrado ninguna evidencia de que eso haya cambiado. Lo que sí se puede decir con datos es que el streaming de HTML y la separación entre caparazón cacheable y hueco personal siguen siendo la combinación que mejor se comporta cuando hay a la vez contenido indexable y contenido de sesión, y que la especulación —en cualquiera de sus tres formas— es la palanca de navegación siguiente con mejor relación entre esfuerzo y resultado, con el mismo cuidado que exige precargar el fragmento antes de necesitarlo: traer de más también cuesta.

Lo que el hardware no arregla

El argumento de que esto se resuelve solo con aparatos mejores es viejo y se puede contrastar con números.

Por el lado del aparato, la referencia que se usa para calibrar un percentil 75 realista en 2026 es un teléfono Android de gama media lanzado a mediados de 2023. No es un error de actualización: la vida media de un móvil supera los dos años, la gama baja no se renueva al ritmo de la alta, y el aparato que importa para tu percentil 75 no es el que se vende este trimestre. La distancia entre el chip más rápido y el más lento que sigue en uso en teléfonos modernos es de un orden de magnitud largo, y esa distancia se está ensanchando, no cerrando.

Por el lado de la carga, los datos del censo de la web de 2025 —tomados sobre el rastreo de julio— son elocuentes:

Diez años, un aumento del 202,8 % en la mediana móvil. Y el percentil 90 de JavaScript por página está en 1,9 MB, con una mediana individual de fichero de 4,7 KB, que es la ilustración perfecta del mecanismo: nadie añade un megabyte, todo el mundo añade cuatro kilobytes.

De ahí sale la aritmética que responde a la pregunta. Para que la mejora del hardware arreglase el problema, la velocidad efectiva del aparato mediano tendría que crecer más deprisa que la carga, sostenidamente, en la parte baja del mercado, que es donde el hardware mejora más despacio. Y hay dos costes que el hardware no toca en absoluto: la latencia de la red, que está limitada por la distancia y la velocidad de la luz y no mejora con el procesador —el argumento completo está en por qué el ancho de banda no es lo que importa—, y la temperatura, porque un procesador más rápido en un teléfono sin ventilación se limita antes, como está desarrollado en el thermal throttling.

Lo que sigue sin resolverse

La lista honesta de problemas abiertos, que es probablemente la sección más útil de esta lección porque señala dónde va a haber trabajo.

No hay ninguna métrica principal de fluidez. El scroll a tirones, las animaciones que saltan y el zoom que se atasca no los captura ninguna Core Web Vital, porque la métrica de interacción solo observa clic, toque y pulsación de tecla. Existe desde Chrome 123 la API de fotogramas de animación largos, sucesora de la de tareas largas, que expone la duración de cada fotograma lento con atribución por script y desglose por etapa, y es hoy la mejor herramienta disponible para este territorio; el marco para interpretarla es el presupuesto de un fotograma. Pero es una API de diagnóstico, no una métrica principal, y el debate sobre si debería haber una y con qué forma sigue abierto.

El desplazamiento acumulado solo se mide en un motor. Ya está dicho arriba; es el hueco más concreto que queda en los datos de campo.

No hay forma justa de atribuir el coste de terceros. Se puede medir cuánto hilo principal consume cada script, y ese trabajo está en medir script a script y el coste real de un tercero, pero no hay ninguna señal estándar que traslade ese coste a quien lo introduce. Sigue siendo un problema organizativo resuelto con mecanismos caseros, como la cultura de rendimiento en un equipo desarrolla.

La métrica convertida en objetivo sigue sin defensa técnica. Mientras las métricas alimenten una señal de posicionamiento, van a existir formas de mover el número sin mover la experiencia. Eso no se arregla con una definición mejor: cada definición nueva trae sus propios atajos. Lo único que funciona es lo de los errores que ya no deberías cometer: medir la cosa además del indicador.

Y una cifra que conviene mirar sin dramatismo. Los recuentos públicos sobre el conjunto de datos de experiencia de usuario sitúan la proporción de orígenes que pasan las tres métricas algo por encima de la mitad, con el móvil claramente por debajo del escritorio y con el pintado del elemento más grande como el que más falla. No he podido verificar una cifra exacta contra la fuente primaria y la que circula varía según qué orígenes entren en el recuento, así que tómala como orden de magnitud: cerca de la mitad de la web sigue sin pasar, quince años después de que todo esto empezara.

Qué de este track caduca y qué no

La distinción práctica con la que conviene salir de aquí:

Con esto se cierra el track. Empezó preguntando qué significa rápido y siguiendo la cadena de causas del clic al píxel; termina con un método, un árbol, un catálogo de errores, un conjunto de mecanismos para que nada de esto se pierda, y una idea de hasta dónde llega lo que hoy se sabe. Lo que queda por delante no es aprender más técnicas: es aplicar el método a un problema real, medirlo en campo, equivocarte de hipótesis un par de veces y descubrir que eso también es progreso.