Mejoras reales del rendimiento 2025

Los clientes y los usuarios finales exigen interactividad instantánea ahora más que nunca. El rendimiento sigue siendo clave para su éxito, ya que empresas como Google establecen el rendimiento como un factor de clasificación clave en los resultados de búsqueda. Akamai ha realizado una gran inversión en el rendimiento de los sitios. Gracias a nuestras mejoras y nuevas funciones, puede lograr un rendimiento óptimo de las aplicaciones para clientes reales.

En esta entrada de blog, demostraremos el impacto positivo que nuestras mejoras han tenido en las métricas de Core Web Vitals (CWV) de nuestros clientes. Como señal de posicionamiento SEO, especialmente en 2025, las CWV son el estándar de facto para observar el rendimiento en el mundo real. Utilizamos CWV porque se centran en los usuarios reales que utilizan aplicaciones modernas, independientemente de la conexión, ubicación, navegador o dispositivo que utilicen.

A continuación, le mostraremos cómo se pueden utilizar estas optimizaciones para mejorar el rendimiento de sus aplicaciones; esto incluye tanto las optimizaciones que hemos introducido como las funciones y controles que ahora puede agregar a su configuración de Akamai para acelerar sus sitios y aplicaciones.

Empecemos.

Las mejoras de rendimiento que introdujimos el año pasado pueden tener un impacto medible en los usuarios reales. Google confirmó este punto en el informe sobre la experiencia del usuario en Chrome (CrUX). El CrUX es un conjunto de datos disponible públicamente y proporcionado por Google que ofrece información sobre cómo los usuarios del mundo real experimentan los sitios web en cuanto a rendimiento y tiempos de carga.

Los datos se recopilan de usuarios reales que han optado por la inclusión, lo que permite a Google realizar un seguimiento y agregar métricas que reflejan interacciones fundamentales de los usuarios en lugar de pruebas simuladas o basadas en laboratorio.

Con las nuevas funciones de Akamai, hemos observado mejores resultados en los indicadores clave de rendimiento (KPI) centrados en el usuario, como el Largest Contentful Paint (LCP) y la Interaction to Next Paint (INP), así como el más técnico, pero popular tiempo hasta el primer byte (TTFB). Echemos un vistazo a algunos ejemplos de sitios web que han visto una evolución positiva de esos Web Vitals.

NOTA: Las siguientes figuras son capturas de pantalla de la excelente herramienta treo.sh, que permite visualizar datos históricos de CrUX de todos los sitios web del conjunto de datos.

La parte verde del gráfico de la parte superior muestra el porcentaje de solicitudes para las que la LCP ha sido inferior a 2,5 segundos. También muestra que un 20 % más de usuarios tienen una experiencia de usuario “buena” (verde) (la LCP fue inferior a 2,5 segundos) desde febrero en comparación con los tres meses anteriores.

El sitio a menudo estaba registrado como territorio que “necesita mejorar” (naranja), y potencialmente estaba siendo penalizado en los resultados de búsqueda de Google, pero ahora está firmemente en el verde, lo que es un fuerte indicio de una mayor satisfacción del usuario.

Un banco centrado en la seguridad logró impresionantes mejoras de Interaction to Next Paint (INP) (Figura 2). No solo realizaron sus propias mejoras en la implementación, sino que también se beneficiaron de varias optimizaciones de JavaScript de Akamai Bot Manager que se han lanzado en los últimos meses. El banco observó que su INP mejoraba continuamente de aproximadamente el 55 % a más del 87 % de los usuarios que tenían una experiencia "buena" (INP < 200 milisegundos).

Aunque no es una CWV en sí misma, el tiempo hasta el primer byte (TTFB) sigue siendo una métrica importante que se debe rastrear, ya que a menudo se correlaciona bien con la LCP.

Un sitio web de comercio electrónico ya de por sí rápido se ha vuelto aún más rápido en los últimos ocho meses a medida que se ha mejorado la plataforma (más información en la sección “¿Qué hemos mejorado?” sección). La Figura 3 muestra un aumento continuo, en consonancia con las versiones de la plataforma de Akamai, en el porcentaje de usuarios con una buena experiencia de TTFB en ese sitio web.

Otro cliente del sector turístico había sufrido históricamente unos números de TTFB inferiores y no utilizaba las optimizaciones de rendimiento disponibles de Akamai. Después de implementar algunas de las prácticas recomendadas del equipo de rendimiento de Akamai, el cliente observó que su TTFB mejoraba de 3 segundos a tan solo 0,6 segundos en poco más de un mes (Figura 4).

No solo los sitios web lentos son los que han aumentado su velocidad, sino que incluso los más rápidos lo han hecho con Akamai. El sitio de comercio electrónico que se muestra en la Figura 5, con millones de visitas al mes, ha cruzado recientemente la barrera mágica de 500 milisegundos de LCP en el P75, tiene unos impresionantes 50 milisegundos de INP y una puntuación perfecta de 0,00 en el Cumulative Layout Shift (CLS).

Al utilizar la plataforma de Akamai, puede construir sitios maduros y altamente escalables que se benefician de una mayor disponibilidad con un rendimiento de clase mundial: sin compromisos, sin concesiones; solo excelencia.

En este punto de la entrada del blog, es posible que haya esperado una comparación del rendimiento en relación con otras redes de distribución de contenido (CDN). Sin embargo, especialmente en 2025, sentimos que es difícil hacer este tipo de comparación con buena conciencia.

Una de las principales razones es que las métricas de CWV de usuarios reales no solo dependen de la velocidad de la CDN, sino también de la programación del front-end y back-end de un sitio, y de sus configuraciones de CDN específicas, todo lo cual puede ser muy diferente entre sitios. Y, por supuesto, puede crear sitios web rápidos y lentos en cualquier plataforma. 

La alternativa sería utilizar métricas de nivel inferior, como TTFB. Aparentemente, se trata de una métrica que debería ser fácilmente comparable entre las CDN: Solo tiene que descargar un único objeto en cada CDN, medir la configuración de la conexión y los tiempos de solicitud… ¡y voilà!

Sin embargo, si bien es fácil recopilar estos resultados, también es cada vez más inútil en el mundo actual del HTTP/3 (y HTTP/2) y sus conexiones multiobjeto. La (re)utilización eficiente de estas conexiones a través de funciones avanzadas (como la priorización de transmisiones y el uso compartido del ancho de banda) es mucho más importante para la experiencia del usuario final (y métricas como la LCP) que la configuración inicial de esa conexión.

Además, muchas otras técnicas cambian la forma en que se mide el TTFB en la práctica, entre las que se incluyen: 103 Early Hints, datos iniciales (0-RTT), registros DNS HTTPS, API de reglas de especulación, etc. (como veremos en la sección “¿Qué hemos mejorado?”).

Como resultado, la medición de TTFB para dos objetos individuales en dos CDN (una con y otra sin una de estas funciones habilitadas) ya puede dar lugar a resultados radicalmente diferentes que no dicen nada sobre lo que realmente es capaz de hacer la CDN (como se muestra en las Figuras 1-5).

Para demostrar lo que decimos, aquí tiene un ejemplo de un cliente que confío demasiado en una comparativa que predecía que vería una reducción drástica de su TTFB si dejaba Akamai (Figura 6). Se cambiaron a una solución diferente a principios de agosto de 2024 y, desafortunadamente, sus datos públicos de CrUX empeoraron instantáneamente.

Nos centramos en los datos de CWV de los clientes de Akamai para mostrar cuál es nuestro impacto en los usuarios reales en lugar de depender de técnicas de comparación heredadas. No se deje llevar por grandes promesas; en su lugar, busque los CWV de algunos de los sitios más grandes del mundo. Es muy probable que se ejecuten en Akamai y tengan un rendimiento estelar.

Ahora que ha visto los impresionantes resultados que puede esperar de las mejoras que hemos realizado en los últimos 12 meses, es el momento de analizar con más detalle lo que implican esas mejoras. Hemos realizado mejoras en las siguientes áreas:

• Plataforma
• Akamai Image & Video Manager
• Soluciones de seguridad
• Capacidad de observación y supervisión de usuarios reales

En el núcleo de Akamai se encuentra nuestra plataforma altamente distribuida, que sigue acercando más cargas de trabajo a los usuarios finales. Esta amplia plataforma nos permite implementar mejoras a una escala sin precedentes.

Entre las últimas mejoras destinadas a distribuir su contenido lo más rápido posible (a usuarios reales) se incluyen:

• 103 Early Hints
• Datos iniciales (0-RTT)
• TLS 1.3 al origen
• API de reglas de especulación
• Optimizaciones de DNS
• Límite de antiamplificación

Para los recursos no almacenables en caché y los fallos de caché, los servidores en el Edge de ​Akamai​ tienen que ponerse en contacto con el servidor de origen. Esto deja inactiva la conexión entre el navegador del cliente y nuestros servidores periféricos hasta que llega la respuesta.

Con Early Hints, los navegadores pueden utilizar ese tiempo de espera para cargar los recursos que especifique, como hojas de estilo CSS, fuentes web, logos o JavaScript crítico, así como preconectar a dominios o subdominios de terceros. Akamai le da control total sobre estas sugerencias para ayudarte a acelerar significativamente la experiencia de renderizado (LCP).

Los datos iniciales son una nueva y potente función tanto para HTTP/2 a través del protocolo de control de transmisión (TCP) como para HTTP/3 a través de QUIC. Permite a los navegadores ahorrar un tiempo de ida y vuelta (RTT) de red completo en la mayoría de las conexiones al Edge de Akamai.

También funciona muy bien junto con otras opciones, como las Early Hints, para traer los datos a los navegadores de los usuarios lo antes posible. Akamai permite una configuración detallada del equilibrio inherente entre seguridad y rendimiento de esta potente función.

Aunque utilizamos conexiones persistentes a su máximo potencial, a veces Akamai necesita establecer una nueva conexión TCP desde nuestro Edge hasta su origen. Hemos añadido compatibilidad con TLS 1.3, lo que evita el RTT adicional necesario con TLS 1.2. Para aprovechar estas ventajas de latencia, asegúrese de configurar los orígenes correctamente.

Puede aprovechar la nueva API de reglas de especulación para acelerar las aplicaciones de varias páginas mediante la recuperación previa o la representación previa de futuras navegaciones. Esta API promete una carga casi instantánea al representar previamente las páginas a las que los usuarios podrían querer acceder a continuación.

Akamai dispone de varias opciones para ofrecer reglas de especulación a los usuarios finales, de modo que pueda influir de forma significativa en KPI importantes como LCP y CLS.

Nuestro equipo de DNS ha implementado las primeras fases de nuestra arquitectura de DNS Anycast de última generación. El programa, apodado Megacloud, está en curso con 8 de nuestros 22 clústeres independientes ya convertidos.

Megacloud anuncia cada una de nuestras redes Anycast desde más ubicaciones. La transición es compleja y deliberada para garantizar que no se comprometa la resiliencia a los ataques. El resultado es una búsqueda de DNS más rápida en todos los percentiles y regiones.

Normalmente, la negociación de QUIC solo tarda 1 RTT en completarse en la red. Sin embargo, dado que Akamai cumple estrictamente ciertos requisitos de seguridad del sector (que reflejan las recomendaciones de RFC 9000), muchas conexiones QUIC (y, por tanto, HTTP/3) en la práctica requerían dos RTT.

Para resolver este problema, hemos aumentado el límite antiamplificación de QUIC de tres (según RFC) a siete y ahora aprovechamos plenamente el rendimiento de HTTP/3 con un único RTT para establecer la conexión.

Las imágenes nítidas son una parte esencial de la web moderna. Para una buena LCP, las imágenes deberían cargarse rápidamente, y dos nuevas funciones del Image & Video Manager le ayudarán a conseguirlo.

• Submuestreo de crominancia SharpYUV: AVIF y HEIF, dos modernos formatos de imagen que ofrecemos, ahora utilizan la versión SharpYUV del submuestreo de crominancia, que ofrece una mejor representación del color y una mayor eficiencia de compresión.

• Cache+: Este nuevo complemento le permite utilizar Akamai Cloud Wrapper para almacenar en caché derivados de Image & Video Manager. Proporciona un espacio de caché dedicado dentro de Cloud Wrapper, lo que le proporciona un mayor control sobre las políticas de exclusión y retención de caché. Esto es excelente para el rendimiento, ya que reduce el reprocesamiento innecesario y garantiza que las imágenes permanezcan en caché durante más tiempo, lo que reduce los fallos de cola larga.

La mayoría de nuestros clientes no quieren comprometer la seguridad. Pero eso no significa que no les importe el rendimiento.

En los últimos 12 meses, hemos optimizado la lógica del Edge y del cliente de nuestras soluciones de seguridad (como Akamai Bot Manager y Akamai Content Protector). Para las bibliotecas de cliente, se han realizado las siguientes optimizaciones típicas de JavaScript:

• División de tareas largas en piezas más pequeñas
• Eliminación del código no utilizado
• Cambio a bibliotecas más rápidas
• Sustitución del código antiguo por homólogos más rápidos

Estas optimizaciones dieron como resultado una reducción de los bytes que se envían por cable, lo que reduce la congestión de la ruta crítica y el tiempo de análisis y compilación de JavaScript. Además, el impacto de nuestras soluciones de seguridad en las métricas de tiempo total de bloqueo (TBT) e Interaction to Next Paint (INP) se redujo significativamente (por ejemplo, consulte la Figura 2).

Ahora que conocemos las métricas de rendimiento y cómo las afectan varias optimizaciones, la siguiente pregunta que podemos plantear es: "¿Cómo las medimos?" Lograr una visibilidad integral puede ser todo un reto, especialmente cuando se utilizan varios proveedores de nube, diferentes servicios y una CDN.

Afortunadamente, hay soluciones disponibles para abordar estos problemas operativos específicos, incluidas las de la solución de supervisión de usuarios reales (RUM) Akamai mPulse y la capacidad de observación de CDN.

• Paneles de atribución de CWV: saber que su sitio es lento es una cosa; averiguar por qué es lento es más complejo. Se han puesto a disposición varios widgets nuevos de mPulse para resolver este problema. Ayudan a atribuir los problemas de CLS, identificar las peores y más frecuentes causas de la INP y categorizar los elementos LCP.

• Nuevas métricas y temporizadores: Se han añadido muchos temporizadores y dimensiones interesantes a mPulse. Eliminan las típicas brechas de visibilidad, reducen el ruido de RUM y facilitan el acceso a los datos más relevantes. Esto incluye Frustrationindex, Page CDN Cache Status, cuatro nuevos temporizadores de front-end e información de BFCache.

• Tiempo perdido de navegación no atribuido (UNO): Este nuevo temporizador acumula todos los intervalos de tiempo "desconocidos" y "adicionales" de una navegación que no se tienen en cuenta en otros temporizadores. Esto puede incluir retrasos en el navegador, tiempos de acceso al disco, tiempo oculto debido a restricciones entre orígenes, etc. Esta métrica ayuda a llenar los huecos y a detectar problemas que, de otro modo, podrían haber pasado desapercibidos.

• Akamai DataStream 2 se ha modificado y ahora incluye datos relevantes adicionales para quieres estén interesados en el rendimiento:

  • Compatibilidad de campo con datos iniciales de TLS y 103 Early Hints
  • Compatibilidad con Akamai EdgeWorkers
  • Compatibilidad con destinos de TrafficPeak

• Breadcrumbs: la nueva función Breadcrumbs le ofrece visibilidad en tiempo real de las condiciones de error y de impacto en el rendimiento para la distribución de contenido.

• Common Media Client Data (CMCD): la recopilación de datos de rendimiento y métricas de uso de dispositivos que transmiten contenido como vídeos, música o juegos es crucial para medir el rendimiento de la transmisión. Identifique y mitigue:

  • Eventos de almacenamiento en búfer
  • Tiempos de arranque lentos
  • Problemas de calidad de reproducción
  • Tasas de error
  • Rendimiento

En los últimos 12 meses, hemos introducido varias mejoras que aceleran las aplicaciones modernas, no solo sobre el papel, sino también para los usuarios reales. Los impactos de estos cambios se reflejan claramente en los datos de CrUX una y otra vez, y llevan a resultados de CWV sustancialmente mejorados, optimizando tanto la experiencia del usuario final como las codiciadas clasificaciones del motor de búsqueda de Google.

Aunque estamos satisfechos con las numerosas mejoras, nuestros equipos siempre ven la oportunidad de reducir milisegundos adicionales, por supuesto, teniendo en cuenta la seguridad, la escalabilidad y la disponibilidad.

Se ha programado la implementación de más optimizaciones en las próximas semanas, meses y años. Permanezca atento mientras esperamos un futuro aún más rápido.