Le jour où on a rapatrié les polices Google Fonts sur le serveur d’un site e-commerce de taille moyenne, le LCP au 75e percentile est passé de 3,8 s à 2,1 s. Aucune optimisation de bundle JS, aucune réduction de poids d’image, aucun changement de CDN. Juste un fichier .woff2 servi depuis le même domaine, sous le même certificat TLS. La page n’avait pas maigri d’un kilo-octet. Elle avait juste cessé d’aller chercher une ressource critique sur un DNS distant dont le resolver mettait 90 ms à répondre un lundi matin. La souveraineté numérique, quand on fait du SEO technique, ce n’est pas une posture géopolitique. C’est une discipline de performance.
On vous répète que les Core Web Vitals sont un levier de classement documenté. On vous dit de compresser vos images, de réduire le JavaScript inutilisé, de surveiller l’INP. Mais on oublie souvent la question de la localisation et du contrôle de vos dépendances. Une page qui charge en 1,3 s sur la fibre d’un bureau lyonnais peut en mettre 4,2 s sur une connexion mobile depuis un datacenter de Googlebot aux États-Unis, simplement parce que votre fichier de police passe par un DNS public, un CDN tiers, et trois routes réseau que vous ne maîtrisez pas.
Ce que les dépendances externes coûtent à votre LCP
Le Largest Contentful Paint mesure le temps nécessaire pour afficher le plus gros élément visible de la fenêtre. Dans la plupart des pages, cet élément est une image hero ou un bloc de texte. Ce bloc de texte dépend d’une police. Cette police, vous la chargez depuis fonts.googleapis.com. Le navigateur découvre le CSS de la police, parse la règle @font-face, repère l’URL distante du fichier de fonte, résout le DNS de fonts.gstatic.com, établit une connexion TLS, puis télécharge le fichier. Tout cela est bloquant pour le rendu du texte, sauf si vous avez manuellement mis en place des stratégies d’affichage (font-display: swap). Par défaut, la plupart des navigateurs masquent le texte tant que la police n’est pas arrivée, ce qu’on appelle le FOIT (Flash of Invisible Text). Chaque saut de réseau ajoute une latence cumulée.
⚠️ Attention : même avec font-display: swap, le LCP peut être mesuré sur un texte en fallback dont la mise en page change à l’arrivée de la police, ce qui peut dégrader le score de Cumulative Layout Shift.
On ne mesure pas assez l’impact des dépendances réseau sur le chemin critique de rendu. Une requête vers un CDN externe ajoute une résolution DNS, une négociation TLS, un temps aller-retour. Si ce CDN est hébergé aux États-Unis et que votre serveur est à Francfort, le handshake peut prendre le double du temps d’une connexion locale. Pour un site qui sert des clients majoritairement européens, chaque dépendance hébergée outre-Atlantique devient un micro-goulot qui s’additionne.
Google Fonts : le piège silencieux du First Contentful Paint
Le cas le plus banal et le plus coûteux qu’on rencontre en audit, c’est le chargement des polices Google Fonts. La documentation officielle propose de les importer via un lien CSS. Ce lien déclenche une chaîne de requêtes qui retarde le rendu du texte, donc le First Contentful Paint, et bien souvent le LCP.
Auto-héberger vos polices consiste à télécharger les fichiers .woff2, à les placer dans votre projet, à les déclarer via une règle @font-face dans votre propre feuille de style, et à les servir depuis le même domaine que votre page. Cela élimine les résolutions DNS externes, les connexions TLS supplémentaires, et les risques de latence variable. En prime, vous gardez le contrôle sur la mise en cache et les entêtes HTTP, ce qui permet d’adapter la stratégie de cache à vos utilisateurs récurrents.
En pratique :
- Téléchargez les fichiers depuis Google Fonts ou via un outil comme google-webfonts-helper.
- Intégrez-les à votre build, en les versionnant.
- Servez-les avec un Cache-Control agressif et un ETag stable.
- Utilisez font-display: swap pour éviter le FOIT.
- Préférez les sous-ensembles (latin, latin-ext) pour réduire le poids.
💡 Conseil : si vous utilisez une surcouche comme Next.js, le composant next/font avec l’option
subsetsest déjà conçu pour auto-héberger les polices Google. Pas besoin d’ajouter un lien externe, le framework génère les fichiers statiques dans le répertoire de sortie.
Quand votre script analytics ralentit le TTFB et perturbe Googlebot
Le script analytics chargé en asynchrone ne bloque pas le rendu initial, mais il occupe le thread principal pendant son exécution et, surtout, il ajoute une requête réseau. Si ce script est hébergé sur un domaine tiers (google-analytics.com, un CDN de plateforme A/B testing), le navigateur doit résoudre ce domaine et établir une connexion. Pour Googlebot, qui ne charge pas les scripts JavaScript de manière interactive, l’impact peut sembler nul. Mais la présence d’un domaine tiers dont la résolution est lente peut affecter le temps de chargement global de la page, et donc indirectement le temps d’indexation.
Plus vicieux : quand le service analytics ou A/B testing est dégradé, la requête reste en attente et ralentit l’émission du CPU idle, ce qui retarde la mesure du TTI (Time To Interactive). Si vous utilisez un RUM (Real User Monitoring) pour suivre vos Core Web Vitals, la dégradation d’une dépendance externe pollue vos propres métriques.
Auto-héberger un outil comme Plausible, Matomo ou Umami change la donne. Le script est servi depuis votre propre domaine, sous votre certificat, avec une latence maîtrisée. La suppression d’un aller-retour DNS et TLS peut faire gagner 80 à 150 ms sur le TTFB, selon la distance du serveur tiers. Et Googlebot n’aura jamais à attendre un domaine externe pour finaliser le crawl, ce qui est précieux quand vous avez un crawl budget serré.
Le DNS et le TLS de vos dépendances, angles morts de l’audit Core Web Vitals
La plupart des audits Lighthouse ou PageSpeed Insights se concentrent sur le poids des ressources, le nombre de requêtes, le temps de blocage du thread principal. Ils ne vous disent pas que telle ou telle requête part vers un DNS que votre resolver met 110 ms à répondre un jour de semaine, contre 30 ms le soir. Cette variance touche toutes les ressources externes : scripts, polices, pixels de tracking, widgets de chat.
Si vous ne maîtrisez pas l’infrastructure DNS de vos dépendances, vous subissez leur fluctuations. Une solution concrète consiste à lister toutes les requêtes externes de vos pages critiques et à mesurer leur latence avec un outil comme WebPageTest (mode multi-régional). Dès que le temps de résolution DNS dépasse 50 ms sur plusieurs tests, considérez que cette dépendance menace votre stabilité de LCP.
Pour les dépendances inévitables, utilisez des techniques de préconnexion (preconnect) et de préchargement DNS (dns-prefetch). Ces balises indiquent au navigateur d’anticiper la résolution et la connexion TLS. Mais elles ne vous donnent pas la souveraineté : elles ne font que limiter les dégâts.
La souveraineté de vos outils de développement a aussi un impact
Le build, le state management, l’éditeur de code : à chaque étape de la chaîne, vous injectez des dépendances. Lorsqu’on parle de souveraineté numérique pour un site performant, il ne s’agit pas uniquement de ce qui se passe côté client. Le temps de build, la fiabilité des services externes utilisés pendant le développement, et même les décisions de state management influencent ce qui arrive en production.
Un projet qui dépend d’un IDE cloud peut voir son workflow ralenti si le service est indisponible. Sur le choix entre Claude Code et un Cursor IDE, la question de la souveraineté des données et de la latence d’inférence devient critique : un modèle d’IA hébergé hors d’Europe peut injecter de la latence dans vos itérations, ce qui retarde les corrections de performance urgentes. De même, un state management React avec Zustand maîtrisé localement permet d’éviter des dépendances à des API distantes pour chaque mutation d’état, ce qui réduit les appels réseau au strict nécessaire.
Ce sont des maillons indirects, mais alignés sur la même logique : chaque morceau de votre infrastructure technique doit être questionné sous l’angle du contrôle. Les Core Web Vitals se jouent aussi dans votre terminal.
Mesurer pour reprendre le contrôle
Avant de rapatrier quoi que ce soit, cartographiez vos dépendances. Ouvrez l’onglet Network des DevTools, filtrez par domaine externe, et notez chaque requête vers un domaine que vous ne possédez pas. Pour chaque dépendance, demandez-vous : « Que se passe-t-il si ce service met 2 secondes à répondre ? » Ensuite, testez.
Un test simple : bloquez chaque domaine externe via un proxy local (Charles, mitmproxy) ou via une règle de pare-feu, et mesurez l’impact sur le LCP en mode Slow 3G. Vous verrez combien de temps est volé à votre rendu principal. Souvent, une seule requête de police lente suffit à faire basculer la page dans la zone « Needs Improvement ».
Le rapatriement des ressources ne se résume pas à les copier sur votre serveur. Il implique de redéfinir votre gestion de cache, vos entêtes, et de versionner les assets. Mais une fois en place, la stabilité des Core Web Vitals devient une conséquence mécanique de cette souveraineté, pas une course permanente contre les aléas des fournisseurs.
Questions fréquentes
Est-ce que toutes les dépendances externes nuisent aux Core Web Vitals ?
Non. Une ressource chargée en deferred ou async, non critique pour le premier rendu, et servie par un domaine dédié mais proche de vos utilisateurs, peut être neutre. Le risque vient de ce qui bloque le rendu ou s’exécute sur le thread principal dans la fenêtre critique d’interaction.
Faut-il auto-héberger toutes les images et vidéos ?
Ce n’est pas toujours possible ni pertinent, surtout pour les médias lourds. Un CDN d’images bien configuré, avec un domaine personnalisé qui évite une résolution DNS supplémentaire via CNAME flattening, peut concilier performance et souveraineté partielle. Mais ne servez jamais vos images critiques depuis un bucket cloud sans CDN.
L’auto-hébergement des polices et scripts rend-il le site plus difficile à maintenir ?
Pour les polices, la maintenance se limite à une mise à jour occasionnelle des fichiers, processus qu’on automatise en quelques lignes dans le build. Pour les scripts analytics, des solutions comme Plausible s’installent en deux commandes sur un VPS. Le principal frein n’est pas technique, c’est l’habitude de déléguer à des services tiers.
