Améliorations réelles des performances 2025

Akamai Wave Blue

écrit par

Tim Vereecke et Robin Marx

July 03, 2025

Tim Vereecke

écrit par

Tim Vereecke

Tim Vereecke adore accélérer les sites Web et a passé plus de 15 ans à explorer les aspects techniques et commerciaux des performances Web. Il est Web Performance Architect chez Akamai et dirige également scalemates.com : le plus grand (et le plus rapide !) site Web de modélisation à l'échelle mondiale.

Robin Marx, Web Performance Architect et Developer Champion, pose à l'extérieur

écrit par

Robin Marx

Le Dr Robin Marx est Senior Web Performance Specialist au sein de l'équipe de vente d'Akamai. Il aide les clients à réaliser des audits de performances et fournit des recommandations sur mesure pour améliorer ces dernières. Depuis qu'il a réalisé son doctorat sur des protocoles comme QUIC et HTTP/3, Robin est un leader d'opinion sur le terrain, en rendant accessibles des sujets techniques complexes dans des articles de blog et des présentations de conférence. Robin a également un hobby quelque peu inhabituel : le week-end, il aime frapper des gens avec de longues épées.

Les améliorations de performances que nous avons introduites au cours de l'année passée ont un effet mesurable sur les utilisateurs réels.
Les améliorations de performances que nous avons introduites au cours de l'année passée ont un effet mesurable sur les utilisateurs réels.

Sommaire

Introduction

Aujourd'hui plus que jamais, les clients et les utilisateurs finaux exigent une interactivité instantanée. Les performances restent la clé de votre réussite, car des entreprises telles que Google en ont fait un facteur de classement clé dans les résultats de recherche. Akamai a investi massivement dans les performances des sites. Grâce à nos améliorations et à nos nouvelles fonctionnalités, vous pouvez obtenir des performances d'application optimales pour les clients du monde réel.

Dans cet article de blog, nous allons démontrer l'impact positif que nos améliorations ont apporté aux indicateurs Core Web Vitals (CWV) de nos clients. En tant que signal de classement SEO, en particulier en 2025, CWV est la norme de facto en matière de performances réelles. Nous l'utilisons, car cet indicateur se concentre sur les utilisateurs réels qui utilisent des applications actuelles, indépendamment de la connexion, de l'emplacement, du navigateur ou du terminal qu'ils utilisent.

Nous allons maintenant vous montrer comment ces optimisations peuvent être utilisées pour améliorer les performances de vos applications. Cela inclut à la fois les optimisations que nous avons introduites, ainsi que les fonctionnalités et les contrôles que vous pouvez désormais ajouter à votre configuration Akamai pour accélérer vos sites et applications.

Allons-y.

Résultats réels

Les améliorations de performances que nous avons introduites au cours de l'année passée peuvent avoir un impact mesurable sur les utilisateurs réels. Cela a été confirmé par Google dans le rapport sur l'expérience des utilisateurs de Chrome (CrUX). Fourni par Google, CrUX est un ensemble de données disponible publiquement qui donne des informations sur la façon dont les utilisateurs réels utilisent les sites Web en termes de performances et de temps de chargement.

Les données sont collectées auprès des utilisateurs réels qui ont choisi de permettre à Google de suivre et d'agréger des mesures qui reflètent les interactions fondamentales des utilisateurs plutôt que de simuler ou de réaliser des tests en laboratoire.

Avec les nouvelles fonctionnalités d'Akamai, nous avons constaté de meilleurs résultats en termes d'indicateurs clés de performance (KPI) axés sur l'utilisateur, tels que Largest Contentful Paint, Interaction to Next Paint et le temps d'accès au premier octet, plus technique mais toujours populaire. Examinons quelques exemples de sites Web qui ont connu une évolution positive de leurs indicateurs Web Vitals.

REMARQUE : Les éléments chiffrés suivants sont issus de captures d'écran de l'excellent outil treo.sh, qui permet de visualiser les données historiques des fichiers CrUX pour tous les sites Web de l'ensemble de données.

Largest Contentful Paint

En janvier 2025, un client du secteur de l'hôtellerie a mis en œuvre 103 Early Hints et a immédiatement remarqué une nette amélioration de son Largest Contentful Paint (LCP, figure 1).

A customer from the hospitality industry implemented 103 Early Hints in January 2025 and immediately noticed a drastic improvement in their Largest Contentful Paint (LCP; Figure 1). Fig. 1: The LCP improved drastically over a few weeks in January, ending up with more than 82% of end users having a “good” experience

La partie verte du graphique en haut indique le pourcentage de demandes pour lesquelles le LCP était inférieur à 2,5 secondes. Il montre également que 20 % d'utilisateurs en plus ont une « bonne » expérience (en vert) (le LCP était inférieur à 2,5 secondes) depuis février par rapport aux trois mois précédents.

Le site a souvent été identifié comme « À améliorer » (en orange), et pouvait être pénalisé dans les résultats de recherche Google. Désormais, cette partie est nettement en vert ce qui est un signal fort d'amélioration de la satisfaction des utilisateurs.

Interaction to Next Paint

Comme le montre la Figure 2; une banque spécialisée dans la sécurité a réalisé des améliorations notables en termes d'interaction avec Next Paint (INP). Non seulement elle a apporté ses propres améliorations de mise en œuvre, mais elle a également bénéficié de plusieurs optimisations JavaScript Akamai Bot Manager qui ont été publiées au cours des derniers mois. La banque a constaté une amélioration continue de son INP, passant d'environ 55 % à plus de 87 % des utilisateurs ayant une « bonne » expérience (INP < 200 millisecondes).

A security-focused bank realized some impressive Interaction to Next Paint (INP) improvements (Figure 2). Fig. 2: INP saw a gradual but steady improvement, with small incremental updates combining to a large total gain over the course of a year

Temps d'accès au premier octet 

Bien qu'il ne s'agisse pas d'une mesure CWV à lui tout seul, le temps d'accès au premier octet (TTFB) reste un indicateur important à suivre, car il est souvent bien corrélé avec le LCP.

Un site Web d'e-commerce déjà rapide a été encore plus optimisé au cours des huit derniers mois, grâce à des améliorations apportées à la plateforme (plus de détails dans la section « Qu'avons-nous amélioré ? »). La figure 3 montre une augmentation continue, conformément aux versions de la plateforme Akamai, du pourcentage d'utilisateurs ayant une bonne expérience du temps d'accès au premier octet sur ce site Web.

Figure 3 shows a continuous increase, in line with the Akamai platform releases, in the percentage of users with a good TTFB experience on that website. Fig. 3: The TTFB decreased steadily over the course of the year, ensuring response times below 800 milliseconds for 97% of the users by the end

Un autre client, dans le secteur du tourisme, souffrait depuis longtemps de chiffres de temps d'accès au premier octet inférieurs aux normes et n'utilisait pas les optimisations de performance disponibles d'Akamai. Après avoir mis en œuvre les meilleures pratiques recommandées par l'équipe de performances d'Akamai, ce client a constaté que son temps d'accès au premier octet s'améliorait, passant de 3 secondes à seulement 0,6 secondes en un peu plus d'un mois (Figure 4).

After implementing some recommended best practices from Akamai’s performance team, that customer saw their TTFB improve from 3 seconds to just 0.6 seconds in a little more than a month (Figure 4). Fig. 4: The TTFB saw a dramatic change — from 3 seconds at the start of February 2025 to just 0.6 seconds by the end of March 2025

Impact sur un site Web rapide

Avec Akamai; non seulement les sites Web lents sont devenus plus rapides, mais même les plus rapides ont encore accéléré. Le site d'e-commerce illustré à la figure 5, qui enregistrait des millions de visites par mois, a récemment franchi la barrière magique de 500 millisecondes de LCP au P75, a atteint un incroyable score de 50 millisecondes pour l'INP et un score parfait de 0,00 pour le Cumulative Layout Shift (CLS).

 The ecommerce site shown in Figure 5, with millions of visits per month, recently crossed the magical barrier of 500 milliseconds LCP at the P75, has a stunning 50 milliseconds for INP, and a perfect score of 0.00 for Cumulative Layout Shift (CLS). Fig. 5: With Akamai, this ecommerce site has a lightning-fast 500-millisecond LCP, a super-snappy 50-millisecond INP, and a completely absent CLS for more than 96% of end users

En utilisant la plateforme d'Akamai, vous pouvez créer des sites matures et hautement évolutifs qui bénéficient d'une disponibilité accrue et de performances exceptionnelles : aucune approximation, aucun compromis, juste l'excellence.

Qu'en est-il des autres CDN ?

À ce stade de la publication, vous vous attendiez peut-être à une comparaison de nos performances par rapport aux autres réseaux de diffusion de contenu (CDN). Cependant, en particulier en 2025, nous pensons qu'il est difficile de faire ce type de comparaison en toute conscience.

L'une des principales raisons est que les mesures CWV des utilisateurs réels dépendent non seulement de la vitesse du CDN, mais aussi de la programmation du front-end et du back-end d'un site, et de leurs configurations CDN spécifiques, qui peuvent toutes être très différentes d'un site à l'autre. Et, bien sûr, vous pouvez créer des sites Web rapides ou lents sur n'importe quelle plateforme. 

Il est également possible d'utiliser des mesures de niveau inférieur, telles que le temps d'accès au premier octet. Ostensiblement, il s'agit d'un indicateur qui devrait être facilement comparable parmi les CDN : Il vous suffit de télécharger un seul objet sur chaque CDN,  de mesurer la configuration de la connexion et de demander une catégorie de temps et voilà !

Cependant, bien qu'il soit facile de recueillir ces résultats, ils ne sont plus aussi pertinents dans le monde actuel du HTTP/3 (et du HTTP/2) et de leurs connexions multi-objets. L'utilisation efficace de ces connexions grâce à des fonctionnalités avancées (comme la priorisation des flux et le partage de la bande passante) est bien plus importante pour l'expérience utilisateur (et des métriques comme LCP) que la configuration initiale de cette connexion.

En outre, de nombreuses autres techniques modifient la façon dont le temps d'accès au premier octet est mesuré dans la pratique, notamment : 103 Early Hints, Early Data (0-RTT), enregistrements DNS HTTPS, API des règles de spéculation, etc. (comme nous le verrons à la section « Qu'avons-nous amélioré ? »).

Par conséquent, mesurer le TTFB pour deux objets uniques sur deux CDN (l'un avec et l'autre sans ou avec l'une de ces fonctionnalités activée) peut déjà conduire à des résultats radicalement différents qui ne disent rien de ce dont le CDN est réellement capable (comme indiqué aux figures 1 à 5).

Exemple adapté aux besoins réels

Pour prouver notre point de vue, voici l'exemple d'un client qui a fait trop confiance à un référentiel indiquant une réduction drastique de son TTFB s'il n'utilisait plus les services d'Akamai (figure 6). Il a adopté une autre solution début août 2024 et, malheureusement, ses données CrUX publiques se sont détériorées instantanément.

To prove our point, here's an example of a customer that put too much faith in a benchmark that predicted they would see a drastic reduction in their TTFB if they moved away from Akamai (Figure 6). Fig. 6: The TTFB worsened considerably, from a good sub–800 milliseconds on Akamai to a mediocre 1.2 seconds, with a competitor

Nous nous concentrons sur les données CWV des clients Akamai pour montrer l'effet que nous avons eu sur les utilisateurs réels au lieu de nous fier aux techniques de benchmarking traditionnelles. Ne soyez pas ébloui par de grandes promesses. Recherchez plutôt les CWV de certains des plus grands sites du monde. Il est fort probable qu'ils utilisent Akamai et qu'ils affichent des performances exceptionnelles.

Qu'avons-nous amélioré ?

Maintenant que vous avez vu les résultats impressionnants que vous pouvez attendre des améliorations que nous avons apportées au cours des 12 derniers mois, il est temps de discuter plus en détail de ces améliorations. Elles ont concerné les domaines suivants :

  • Plateforme
  • Akamai Image & Video Manager
  • Solutions de sécurité
  • Surveillance des utilisateurs réels et observabilité

Plateforme

Au cœur d'Akamai se trouve notre plateforme hautement distribuée qui continue de rapprocher davantage de charges de travail des utilisateurs finaux. Cette plateforme étendue nous permet de mettre en œuvre des améliorations à une échelle sans précédent.

Les dernières améliorations visant à diffuser votre contenu le plus rapidement possible (à des utilisateurs réels) incluent :

  • 103 premiers conseils
  • Données précoces (0-RTT)
  • TLS 1.3 vers le serveur d'origine
  • API de règles de spéculation
  • Optimisations DNS
  • Limite d'anti-amplification

103 premiers conseils

Pour les ressources non mises en cache et les échecs de cache, les serveurs d'Akamai en bordure de l'Internet doivent contacter le serveur origine. La connexion entre le navigateur du client et nos serveurs en bordure de l'Internet reste inactive jusqu'à ce que la réponse arrive.

Avec Early Hints, les navigateurs peuvent utiliser ce temps d'attente pour précharger les ressources indiquées, telles que les feuilles de style CSS, les polices Web, les logos ou le JavaScript critique, ou pour se préconnecter à des domaines ou sous-domaines tiers. Akamai vous offre un contrôle intégral de ces indices pour vous aider à accélérer considérablement l'expérience de rendu (LCP).

Données précoces (0-RTT)

Early Data est une nouvelle fonctionnalité puissante pour HTTP/2 sur TCP (transmission Control Protocol) et HTTP/3 sur QUIC. Elle permet aux navigateurs d'économiser un délai aller-retour (RTT, Round-Trip Time) réseau complet sur la plupart des connexions à la bordure de l'Internet Akamai.

Elle fonctionne également très bien avec d'autres options, telles que les Early Hints, pour transmettre les données aux navigateurs de vos utilisateurs le plus rapidement possible. Akamai permet une configuration précise du compromis sécurité-performances inhérent à cette puissante fonctionnalité.

TLS 1.3 vers le serveur d'origine

Bien que nous utilisions des connexions persistantes à leur potentiel maximal, Akamai doit parfois établir une nouvelle connexion TCP entre notre bordure de l'Internet et votre serveur d'origine. Nous avons ajouté la prise en charge de TLS 1.3, évitant ainsi les RTT supplémentaires nécessaires avec TLS 1.2. Pour tirer parti de ces avantages de latence, assurez-vous de configurer correctement vos origines.

API de règles de spéculation

Vous pouvez tirer parti de la nouvelle API des règles de spéculation pour accélérer les applications multi-pages en préchargeant ou en effectuant un prérendu des futures navigations. Cette API promet un chargement quasi instantané lors de la présoumission de pages auxquelles vos utilisateurs pourraient vouloir accéder ultérieurement.

Akamai propose différentes options pour fournir des règles de spéculation à vos utilisateurs finaux afin que vous puissiez avoir un impact significatif sur les indicateurs clés de performance importants tels que LCP et CLS.

Optimisations DNS

Notre équipe DNS a déployé les premières phases de notre architecture DNS anycast nouvelle génération. Le programme, surnommé Megacloud, est en cours avec 8 de nos 22 clusters indépendants qui ont déjà été convertis.

Megacloud annonce chacun de nos réseaux anycast depuis davantage de sites. La transition est complexe et délibérée pour garantir l'absence de compromis sur la résilience des attaques. Résultat : des recherches DNS anycast plus rapides sur tous les percentiles et toutes les régions.

Limite d'anti-amplification

Normalement, établir une liaison QUIC ne prend qu'un RTT sur le réseau. Cependant, comme Akamai adhère strictement à certaines exigences de sécurité de l'industrie (reflétant ainsi les recommandations de RFC 9000), de nombreuses connexions QUIC (et donc HTTP/3) nécessitaient en pratique deux RTT au lieu d'un.

Pour résoudre ce problème, nous avons augmenté la limite anti-amplification QUIC de trois (conformément à la RFC) à sept et nous profitons maintenant pleinement des performances de HTTP/3 avec seulement un seul RTT pour établir la connexion.

Image & Video Manager

Aujourd'hui, sur le Web, il est essentiel d'avoir des images nettes. Pour un bon LCP, les images doivent se charger rapidement et deux nouvelles fonctionnalités d'image & Video Manager vous aideront à atteindre cet objectif.

  • Sous-échantillonnage SharpYUV Chroma : AVIF et HEIF, deux formats d'image actuels que nous proposons, utilisent désormais la version SharpYUV de Chroma SubSampling, offrant une meilleure représentation des couleurs et une meilleure efficacité de compression.

  • Cache+ : Ce nouveau module vous permet d'utiliser Akamai Cloud Wrapper pour la mise en cache des dérivés d'Image & Video Manager. Il fournit un espace de cache dédié dans Cloud Wrapper, ce qui vous permet de mieux contrôler les règles d'éviction et la rétention du cache. Cette fonction est idéale pour les performances, car elle réduit le retraitement inutile et garantit que les images restent dans le cache plus longtemps, réduisant ainsi les pertes à long terme.

Solutions de sécurité

La plupart de nos clients ne veulent pas faire de compromis sur la sécurité. Mais cela ne signifie pas pour autant qu'ils ne se soucient pas des performances.

Au cours des 12 derniers mois, nous avons optimisé la logique de nos solutions de sécurité (telles qu'Akamai Bot Manager et Akamai Content Protector aussi bien du côté de la bordure de l'Internet que du côté client). Pour les bibliothèques côté client, les optimisations JavaScript types suivantes ont été effectuées :

  • Diviser les tâches longues en petits morceaux
  • Suppression du code inutilisé
  • Basculement vers des bibliothèques plus rapides
  • Remplacement de l'ancien code par des homologues plus rapides

Ces optimisations ont permis de diminuer le nombre d'octets à envoyer par câble, de réduire la congestion critique des chemins et de limiter le temps d'analyse et de compilation JavaScript. En outre, l'impact de nos solutions de sécurité sur les mesures de Total Blocking Time (TBT) et d'Interaction to Next Paint (INP) a été considérablement réduit (voir la figure 2, par exemple).

Surveillance des utilisateurs réels et observabilité

Maintenant que nous comprenons les indicateurs de performances et la façon dont les diverses optimisations les affectent, nous pouvons poser la question suivante : « Comment pouvons-nous les mesurer ? » Obtenir une visibilité de bout en bout peut s'avérer difficile, en particulier lorsque vous utilisez plusieurs fournisseurs de cloud, différents services et un réseau de diffusion de contenu (CDN).

Heureusement, il existe des solutions pour résoudre ces problèmes opérationnels spécifiques, notamment celles de la solution de surveillance des utilisateurs en temps réel (RUM, Real User Monitoring) mPulse d'Akamai et de l'observabilité des CDN.

Solution mPulse RUM

  • Tableaux de bord d'attribution CWV : Savoir que votre site est lent est une chose, en trouver la raison est plus complexe. Plusieurs nouveaux widgets mPulse ont été mis à disposition pour résoudre ce problème. Ils vous aident à identifier les problèmes de CLS, à identifier les causes INP les plus défavorables et les plus fréquentes, et à classer vos éléments LCP par catégorie.

  • Nouveaux indicateurs et chronomètres : De nombreux chronomètres et dimensions intéressants ont été ajoutés à mPulse. Ils éliminent les lacunes de visibilité classiques, réduisent le bruit du RUM et vous permettent d'accéder plus facilement aux données les plus pertinentes. Cela inclut le score de frustration, l'état de la mise en cache CDN de la page, quatre nouveaux chronomètres front-end et des informations sur BFCache.

  • Unattributed Navigation Overhead (UNO) : Cette nouvelle métrique accumule toutes les durées « inconnues » et « supplémentaires » d'une navigation qui ne sont pas prises en compte par les autres. Il peut s'agir de retards dans le navigateur, de temps d'accès au disque, de temps masqué en raison de restrictions inter-origines, etc. Cette métrique permet de combler les écarts et de détecter les problèmes qui auraient pu passer inaperçus.

Observabilité des CDN

  • Akamai Datastream 2 a été modifié et inclut désormais des points de données pertinents supplémentaires pour les personnes intéressées par les performances :

  • Fil d'Ariane : La nouvelle fonctionnalité Fil d'Ariane vous offre une visibilité en temps réel des conditions d'erreur et d'impact sur les performances pour la diffusion de votre contenu.

  • Common Media client Data (CMCD) : La collecte de données de performances et de mesures d'utilisation à partir d'appareils qui diffusent du contenu comme des vidéos, de la musique ou des jeux est essentielle pour mesurer les performances de streaming. Identifier et atténuer :

    • Mise en mémoire tampon des événements
    • Temps de démarrage lents
    • Problèmes de qualité de lecture
    • Taux d'erreurs
    • Débit

Synthèse

Au cours des 12 derniers mois, nous avons introduit plusieurs améliorations qui accélèrent les applications actuelles, non seulement sur papier, mais aussi pour les utilisateurs réels. L'impact de ces changements se manifeste clairement dans les données CrUX à maintes reprises, ce qui se traduit par des résultats CWV considérablement améliorés, faisant progresser à la fois l'expérience de l'utilisateur final et le très convoité classement des moteurs de recherche Google.

Bien que nous soyons satisfaits des nombreuses améliorations apportées, nos équipes ont toujours la possibilité de gagner des millisecondes supplémentaires, en tenant compte de la sécurité, de l'évolutivité et de la disponibilité.

D'autres optimisations sont prévues pour le déploiement dans les semaines, les mois et les années à venir. Restez à l'écoute et nous nous réjouissons à l'idée d'un avenir encore plus rapide.

En savoir plus

Pour en savoir plus, regardez ce webinaire pour une présentation technique approfondie qui explique comment vous pouvez bénéficier des dernières optimisations de performances dans le navigateur, en bordure de l'Internet et dans le cloud.



Akamai Wave Blue

écrit par

Tim Vereecke et Robin Marx

July 03, 2025

Tim Vereecke

écrit par

Tim Vereecke

Tim Vereecke adore accélérer les sites Web et a passé plus de 15 ans à explorer les aspects techniques et commerciaux des performances Web. Il est Web Performance Architect chez Akamai et dirige également scalemates.com : le plus grand (et le plus rapide !) site Web de modélisation à l'échelle mondiale.

Robin Marx, Web Performance Architect et Developer Champion, pose à l'extérieur

écrit par

Robin Marx

Le Dr Robin Marx est Senior Web Performance Specialist au sein de l'équipe de vente d'Akamai. Il aide les clients à réaliser des audits de performances et fournit des recommandations sur mesure pour améliorer ces dernières. Depuis qu'il a réalisé son doctorat sur des protocoles comme QUIC et HTTP/3, Robin est un leader d'opinion sur le terrain, en rendant accessibles des sujets techniques complexes dans des articles de blog et des présentations de conférence. Robin a également un hobby quelque peu inhabituel : le week-end, il aime frapper des gens avec de longues épées.