La mise à jour Safari 26.2 introduit la prise en charge du suivi du Largest Contentful Paint (**LCP**) ainsi que de l’Event Timing API, qui permet de mesurer la Interaction to Next Paint (**INP**). Grâce à ces apports, les administrateurs de sites peuvent désormais collecter des données LCP et INP directement depuis les navigateurs Safari via la Performance API, et les remonter dans leurs outils d’analyse et de supervision réelle des utilisateurs.

Nouveau support de LCP et INP dans Safari

Le Largest Contentful Paint est l’un des indicateurs essentiels des Core Web Vitals et joue un rôle dans le référencement. De son côté, la Interaction to Next Paint — également considérée comme une métrique des Core Web Vitals — évalue la réactivité d’une page lors des interactions utilisateur. L’intégration native de ces mesures dans Safari comble une lacune de longue date en matière d’observabilité pour les visiteurs utilisant des appareils Apple.

La métrique INP est particulièrement significative : elle rend compte du temps total écoulé entre l’action de l’utilisateur (clic, tap, pression sur une touche) et la mise à jour visuelle à l’écran, en se focalisant sur l’interaction la plus lente observée pendant une session. En pratique, elle révèle si une page donne l’impression d’être « gelée » ou peu réactive. Un score INP rapide correspond généralement à une expérience utilisateur fluide pour les personnes qui interagissent avec le site.

Il est important de noter que cette évolution ne modifie pas les jeux de données publics utilisés par des outils basés sur Chromium : par exemple, PageSpeed Insights et les données CrUX resteront inchangés car ils reposent sur le moteur Chromium. En revanche, les visiteurs utilisant Safari pourront désormais être inclus dans les données de terrain (field data) si le propriétaire du site a mis en place la collecte des métriques via ses solutions d’analyse ou de Real User Monitoring (RUM).

Quels outils peuvent désormais remonter ces métriques depuis Safari ?

La disponibilité de ces API fait qu’un grand nombre de solutions d’analyse et de monitoring peuvent être configurées pour recevoir des LCP et des INP mesurés côté client. Parmi les solutions de collecte et d’analyse on trouve :

• Google Analytics (GA4, via l’intégration Web Vitals ou par événements personnalisés)
• Adobe Analytics
• Matomo
• Amplitude (avec instrumentation de performance)
• Mixpanel (via pipelines d’événements personnalisés)
• Solutions internes ou personnalisées de supervision

Et pour les plateformes de Real User Monitoring (RUM) :

• Akamai mPulse
• Cloudflare Web Analytics
• Datadog RUM
• Dynatrace
• Elastic Observability (RUM)
• New Relic Browser
• Raygun
• Sentry Performance
• SpeedCurve
• Splunk RUM

Pour plus de détails techniques fournis par Apple, la documentation officielle de WebKit explique les nouveautés introduites dans cette version.

Comment Safari expose ces mesures au niveau technique

La Performance API du navigateur centralise différentes entrées permettant d’analyser le comportement d’affichage et d’interaction d’une page. Avec Safari 26.2, deux types d’entrées deviennent accessibles de manière fiable :

• Les entrées de type Largest Contentful Paint, qui identifient le plus grand élément visible rendu dans la fenêtre d’affichage et la durée nécessaire pour son affichage.
• Les entrées issues de l’Event Timing API, qui fournissent une chronologie complète entre l’événement utilisateur, l’exécution des gestionnaires (event handlers), les mises à jour du DOM et la peinture finale. Ces entrées permettent de calculer l’Interaction to Next Paint (INP).

Les développeurs peuvent utiliser un PerformanceObserver pour capter ces entrées côté client et les envoyer vers un backend d’analyse. Par exemple, la bibliothèque Web Vitals (ou une implémentation maison) peut écouter les entrées et convertir les valeurs en événements mesurables pour vos rapports.

// Exemple simplifié d'observation (pseudo-code)
const obs = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // entry peut être un LargestContentfulPaint ou PerformanceEventTiming
    // envoyer les données vers l'endpoint d'analyse
  }
});
obs.observe({ type: 'largest-contentful-paint', buffered: true });
obs.observe({ type: 'event', buffered: true });

Limites et différences vis-à-vis des outils publics

Les services publics de mesure de performances reposent souvent sur des environnements contrôlés (laboratory data) ou sur l’écosystème Chromium pour la collecte de métriques de champ. Ainsi :

• PageSpeed Insights et la Chrome User Experience Report (CrUX) continueront d’afficher des données majoritairement issues de sessions Chrome, car elles s’appuient sur l’écosystème Chromium.
• La prise en charge dans Safari ne modifie pas rétroactivement ces jeux de données, mais offre aux propriétaires de site la possibilité d’inclure les utilisateurs Apple dans leurs propres jeux de métriques terrain.

Pourquoi ces métriques comptent pour le référencement et l’expérience utilisateur

Les Core Web Vitals sont intégrés aux signaux de qualité utilisés par les moteurs de recherche pour estimer la convivialité d’un site. Le LCP renseigne sur le moment où le contenu principal apparaît pour l’utilisateur, tandis que le INP évalue la rapidité ressentie lors d’interactions. Ensemble, ces métriques permettent d’appréhender deux dimensions clés :

• La perception de rapidité lors du chargement initial (visibilité du contenu principal).
• La réactivité pendant l’utilisation (interactions et feedback visuel).

Un bon score LCP indique que la page affiche rapidement son contenu central, ce qui réduit le taux d’abandon au chargement. Un bon score INP signifie que les actions de l’utilisateur provoquent des réponses visuelles rapides, ce qui favorise l’engagement et la conversion. En conséquence, pouvoir mesurer ces valeurs pour les utilisateurs Safari est un atout pour obtenir une vision plus complète du ressenti réel des visiteurs et pour prioriser des améliorations à impact élevé.

Se préparer à interpréter les données LCP et INP

Quelques points à garder en tête lors de l’interprétation :

• Les seuils qui définissent une « bonne » valeur varient selon la métrique et les recommandations (par exemple, Google propose des repères pour LCP et INP). Ces seuils servent d’indicateurs mais doivent être évalués dans le contexte de vos utilisateurs réels.
• La variance entre navigateurs et appareils est normale. Un même site peut afficher des LCP et INP différents sur desktop, mobile Android et iOS en raison des différences matérielles et des moteurs de rendu.
• La collecte côté client reflète l’expérience réelle — elle est donc sujette à la diversité des conditions réseau, aux versions d’OS, et à la charge CPU du device de l’utilisateur.

Configurer la collecte : conseils pratiques pour les équipes web

Pour profiter de cette nouveauté, il est recommandé de revoir la chaîne de collecte de mesures et de s’assurer que les outils d’analyse sont capables d’ingérer les nouvelles entrées. Voici un guide pratique par type d’outil :

Google Analytics (GA4)

Dans GA4, vous pouvez intégrer les métriques Web Vitals en les envoyant comme événements personnalisés. Plusieurs approches sont possibles :

• Intégrer la bibliothèque web-vitals et envoyer les valeurs LCP et INP via des événements personnalisés vers GA4.
• Utiliser Google Tag Manager pour capter les événements côté client et les transmettre à GA4.
• Ajouter des dimensions personnalisées pour segmenter les métriques par navigateur, version d’OS ou type d’appareil (afin de séparer le trafic Safari).

Exemple (schématisé) : capter l’événement, puis le poster vers votre endpoint ou via GTM vers GA4. Veillez à respecter les règles de consentement si vous traitez des données utilisateur.

Plateformes classiques et solutions open-source

Des solutions comme Adobe Analytics, Matomo, Amplitude ou Mixpanel peuvent recevoir des événements contenant les données LCP et INP. Les étapes générales :

• Instrumenter le client (navigateur) pour capter les entrées via la Performance API.
• Transformer ces entrées en payloads conformes aux schémas d’événements de la plateforme cible.
• Envoyer et vérifier la qualité des données (taux d’échantillonnage, latence, erreurs).

Solutions RUM (Real User Monitoring)

Les plateformes RUM listées ci-dessus ont généralement des agents JavaScript ou des SDK capables de récolter les entrées Performance. Elles permettent :

• Une agrégation en temps réel des métriques LCP et INP.
• La segmentation par navigateur, appareil, géographie et pages.
• La mise en place d’alertes et de tableaux de bord dédiés au suivi des Core Web Vitals.

Si vous utilisez une solution RUM commerciale, vérifiez la version du SDK et la documentation pour activer la collecte des entrées issues de l’Event Timing API et du Largest Contentful Paint.

Mise en œuvre maison (Custom / In-House Monitoring)

Pour les équipes qui gèrent leur propre pipeline d’événements, la procédure consiste à :

• Installer un PerformanceObserver pour les types d’entrées nécessaires.
• Filtrer et nettoyer les données (éviter la duplication, gérer les sessions et l’échantillonnage).
• Expédier les événements vers un endpoint sécurisé, puis les stocker et les agréger dans votre Data Warehouse ou votre outil BI.

La flexibilité d’une solution maison permet d’adapter la granularité des données et d’appliquer des règles de conformité spécifiques à votre organisation.

Actions recommandées pour améliorer vos scores LCP et INP

L’optimisation de ces deux métriques requiert des axes d’intervention complémentaires — certains visent le temps de rendu des éléments majeurs, d’autres réduisent la latence perçue lors des interactions. Voici des bonnes pratiques éprouvées :

Pour améliorer le LCP

• Optimiser et compresser les images (WebP/AVIF lorsque pertinent) et définir des tailles adaptées via srcset et sizes.
• Précharger les ressources critiques (fonts, images hero) avec <link rel="preload"> pour réduire le temps jusqu’au rendu.
• Minimiser le temps de réponse serveur (TTFB) : mise en cache, CDN, optimisation de l’application backend.
• Réduire la préparation du rendu (critical CSS inlining, suppression des CSS bloquants).
• Décomposer les pages en composants légers et charger de manière asynchrone les éléments non critiques.

Pour améliorer le INP

• Éviter les tâches longues dans le thread principal : décomposer les tâches lourdes en micro-tâches, utiliser requestIdleCallback lorsque pertinent.
• Utiliser des « passive » event listeners pour le scroll et le touch afin de ne pas bloquer le thread principal.
• Déporter des calculs lourds vers des Web Workers si possible.
• Minimiser le JavaScript exécuté au démarrage et différer le code non essentiel (code-splitting, lazy loading).
• Limiter le travail effectué dans les gestionnaires d’événements et privilégier des interactions rapides suivies d’un rendu asynchrone si nécessaire.

Mesurer l’impact des changements

Après avoir déployé des optimisations, il est essentiel de comparer les indicateurs avant/après en segmentant par navigateur et par appareil. Grâce à la collecte des données LCP et INP depuis les utilisateurs Safari, vous pourrez :

• Vérifier si les optimisations améliorent réellement l’expérience des utilisateurs iOS/macOS.
• Prioriser les actions en fonction de l’impact réel observé sur le terrain.
• Éviter des décisions basées uniquement sur des environnements de laboratoire qui ne reflètent pas toujours les conditions réelles.

Aspects pratiques, confidentialité et compatibilité

Consentement et règles de confidentialité

La collecte de métriques de performance côté client peut impliquer l’envoi de données liées à la session utilisateur. Selon votre législation locale et vos politiques internes, assurez-vous de :

• Respecter le consentement des utilisateurs (ex. : bannières de cookies) si vos événements sont associés à un identifiant ou permettent un suivi cross-site.
• Anonymiser les données quand c’est possible et limiter la durée de conservation des traces individuelles.

Même si les Core Web Vitals sont des mesures techniques, la capture des événements et leur association à des sessions ou utilisateurs doit être traitée conformément aux obligations RGPD/LPD/CCPA le cas échéant.

Compatibilité et couverture utilisateur

La portée effective de cette nouveauté dépend de la part de trafic Safari sur votre site. Pour beaucoup de domaines, les appareils Apple représentent une part significative des visites, en particulier sur mobile dans certains marchés. Intégrer ces métriques permet donc d’obtenir une image plus fidèle de l’expérience réelle :

• Vérifiez la version minimale d’OS / de Safari dans votre population d’utilisateurs ; la disponibilité des API peut dépendre de la mise à jour du navigateur.
• Mesurez la distribution des versions pour estimer l’amélioration de couverture apportée par Safari 26.2.

Exemples concrets d’utilisation des données

Voici des cas d’usage concrets où l’ajout des données Safari peut changer la compréhension du produit :

• Si vos utilisateurs iOS montrent systématiquement des LCP plus élevés que les utilisateurs Android, il peut être nécessaire d’optimiser la livraison d’images pour WebKit ou d’ajuster le preloading.
• Un INP élevé sur Safari uniquement peut pointer vers un code JavaScript incompatibles ou des handlers qui bloquent le thread sur WebKit ; l’analyse des entrées d’Event Timing permet d’identifier les handlers problématiques.
• Segmenter par version de navigateur pour repérer des régressions introduites par des changements CSS/JS récents qui n’affectent qu’une famille de navigateurs.

Ressources et documentation

Pour approfondir l’implémentation technique, la documentation officielle des moteurs et des bibliothèques est utile :

• Documentation WebKit (notes de version pour Safari 26.2) : renseignements et détails techniques.
• Spécifications et guides sur les Core Web Vitals et la Performance API (MDN, W3C).
• Bibliothèques tierces comme web-vitals pour faciliter la collecte et l’envoi des métriques vers vos outils d’analyse.

Conclusion : une visibilité accrue pour l’expérience réelle

L’arrivée du support pour le Largest Contentful Paint et l’Event Timing API dans Safari 26.2 représente une avancée importante pour la mesure de la performance web. En permettant la collecte des valeurs LCP et INP depuis les navigateurs Apple, les équipes produit et performance disposent d’un panorama plus complet de l’expérience utilisateur réelle. Cela facilite la priorisation des optimisations et la vérification de leur effet sur des segments importants de trafic.

Pour tirer pleinement parti de ces nouveautés, il est recommandé de vérifier la configuration de vos outils d’analyse et RUM, d’ajuster vos pipelines de données, et d’appliquer des stratégies d’optimisation ciblées afin d’améliorer à la fois le rendu du contenu majeur (LCP) et la réactivité aux interactions (INP).