La vitesse de chargement d'une page dépend-elle des ressources tierces qu'elle charge ?

Google fait-il une différence entre ses propres scripts et ceux des autres ?

Non. Google mesure la vitesse perçue par l'utilisateur final, sans distinguer l'origine des ressources. Si votre page charge Analytics, Tag Manager, Font API ou n'importe quel service Google, ces appels réseau entrent dans le calcul global de performance.

Cette déclaration tranche un débat récurrent : certains SEO pensaient que les ressources Google bénéficiaient d'un traitement préférentiel. C'est faux. Un script Analytics mal optimisé pèse autant qu'un widget Facebook ou une balise publicitaire tierce dans l'évaluation finale.

Comment Google évalue-t-il concrètement la vitesse de chargement ?

Le moteur se base sur les Core Web Vitals collectées via le Chrome User Experience Report (CrUX). Ce sont des données terrain, issues de vrais utilisateurs sur de vrais appareils, pas des tests synthétiques en laboratoire.

Les métriques clés sont le Largest Contentful Paint (LCP), le First Input Delay (FID) ou son successeur l'Interaction to Next Paint (INP), et le Cumulative Layout Shift (CLS). Chacune capture un aspect de l'expérience : temps de rendu du contenu principal, réactivité aux interactions, stabilité visuelle.

Pourquoi cette approche « expérience utilisateur globale » change-t-elle la donne ?

Parce qu'elle rend caduque toute tentative de contournement. Vous ne pouvez pas optimiser seulement votre HTML et ignorer les scripts tiers. Si un tag manager fait exploser le temps d'exécution JavaScript, si un pixel de tracking bloque le rendu, si une police Google Fonts mal chargée provoque un layout shift, tout cela impacte votre score.

Google ne regarde pas « ce qui vient de chez vous » versus « ce qui vient d'ailleurs ». Il regarde ce que vit l'utilisateur. Un site rapide avec beaucoup de scripts tiers bien optimisés surclassera un site lent avec peu de dépendances.

• Aucune exception pour les ressources Google : Analytics, Tag Manager, Fonts, Maps, tout compte.
• Les Core Web Vitals sont mesurées côté utilisateur via CrUX, pas en laboratoire.
• L'origine d'une ressource n'influence pas son impact sur le score de vitesse.
• Un script tiers rapide et bien intégré vaut mieux qu'une ressource locale mal optimisée.
• La performance est une responsabilité end-to-end : vous êtes comptable de tout ce qui charge sur votre page.

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui, totalement. Les tests montrent que les ressources Google pèsent sur les Web Vitals exactement comme n'importe quelle autre dépendance. Un site qui charge Google Analytics de manière non optimisée peut voir son LCP ou son INP dégradé de façon mesurable.

Les audits PageSpeed Insights signalent régulièrement gtag.js, analytics.js ou googletagmanager.com comme contributeurs au temps de blocage du thread principal. Aucun passe-droit. Les outils de Google eux-mêmes vous reprochent d'utiliser… les outils de Google, si vous le faites mal.

Quelles nuances faut-il apporter à cette affirmation ?

La déclaration reste vague sur un point : comment Google gère-t-il les ressources qui échouent à charger ? Si un CDN tiers est hors ligne et bloque le rendu, est-ce imputé au site ou existe-t-il une tolérance pour les pannes externes ? [A vérifier]

Autre zone grise : les ressources chargées après l'interaction utilisateur. Si un script Analytics ne se déclenche qu'après un scroll ou un clic, son impact sur le LCP est nul, mais il peut encore affecter l'INP ou le Total Blocking Time. Le « global » de « expérience utilisateur globale » reste flou : s'arrête-t-il au onload, au fully loaded, ou inclut-il toute la session ?

Dans quels cas cette règle pourrait-elle ne pas s'appliquer comme attendu ?

Si votre site a un trafic trop faible pour apparaître dans CrUX, Google n'a pas de données terrain et peut se rabattre sur d'autres signaux ou ne pas appliquer pleinement le ranking boost lié aux Web Vitals. Dans ce cas, la vitesse compte toujours, mais son poids dans le classement devient incertain.

Autre cas limite : les pages avec beaucoup de JavaScript côté client. Si l'essentiel du contenu est rendu par React ou Vue après le chargement initial, les métriques traditionnelles ne capturent pas toujours l'expérience réelle. Google a introduit l'INP pour mieux couvrir ces scénarios, mais des angles morts subsistent. Un site SPA peut afficher de bons Web Vitals sur la première page et ramer sur les transitions internes.

Que faut-il faire concrètement pour optimiser les ressources tierces ?

Auditer chaque script chargé sur vos pages est la première étape. Utilisez la couverture de code dans Chrome DevTools pour identifier les scripts qui s'exécutent mais ne servent à rien sur certaines pages. Un tag Analytics sur une page de confirmation de commande sans tunnel d'achat, par exemple, peut être chargé en différé.

Pour les ressources Google spécifiquement : chargez gtag.js ou analytics.js en async ou defer, utilisez le preconnect pour les domaines tiers (<link rel="preconnect" href="https://www.googletagmanager.com">), et envisagez le lazy loading des balises non critiques via GTM. Les Google Fonts doivent être chargées avec font-display: swap pour éviter le blocage du rendu.

Quelles erreurs éviter absolument ?

Ne chargez jamais de scripts tiers en mode bloquant dans le <head> sans raison valable. Chaque milliseconde compte avant le First Contentful Paint. Si un script doit s'exécuter tôt, privilégiez le preload avec as="script" plutôt qu'un appel synchrone.

Autre piège classique : multiplier les domaines tiers. Chaque nouveau domaine implique une résolution DNS, un handshake TLS, une connexion TCP. Si vous chargez Analytics depuis google-analytics.com, des fonts depuis fonts.googleapis.com, et des maps depuis maps.googleapis.com, vous payez le coût de trois connexions distinctes. Utilisez resource hints (preconnect, dns-prefetch) pour anticiper ces connexions.

Comment vérifier que mon site respecte ces bonnes pratiques ?

Lancez un audit PageSpeed Insights et regardez la section « Diagnostics ». Identifiez les scripts qui bloquent le thread principal plus de 50 ms. Vérifiez que vos ressources Google sont bien chargées en async et que leur taille est minimale (pas de version non minifiée).

Testez aussi avec WebPageTest en throttling 3G pour simuler des conditions réseau dégradées. Si votre LCP explose à cause d'un script Analytics qui met 4 secondes à répondre, vous avez un problème architectural. Les données CrUX dans la Search Console vous donnent une vue terrain : comparez vos métriques mobile et desktop, identifiez les pages problématiques.

• Charger tous les scripts tiers (y compris Google Analytics) en async ou defer
• Utiliser preconnect pour les domaines critiques (googletagmanager.com, fonts.gstatic.com)
• Auditer la couverture de code et supprimer les scripts inutilisés
• Implémenter font-display: swap pour toutes les Google Fonts
• Lazy-loader les tags non critiques via GTM ou un gestionnaire de consentement
• Monitorer les Web Vitals terrain via CrUX dans la Search Console