La vitesse d'un site n'est pas un luxe technique. Pour un artisan, un restaurateur, un cabinet libéral ou un commerce béarnais, c'est ce qui décide si un prospect appelle, prend rendez-vous, demande un devis, ou repart sur la fiche du concurrent affichée juste en dessous.
Google le mesure depuis 2017 et a fait de la performance un signal de classement mobile en 2018 (mise à jour « Speed Update »), puis a élevé les Core Web Vitals au rang de signal d'expérience en juin 2021. Cet article rassemble les chiffres officiels, les seuils en vigueur en 2026, les vraies causes des sites lents au Béarn, et les leviers techniques que j'applique chez PilotOne.
Ce que les études Google ont établi sur le comportement des visiteurs
La référence fondatrice est une étude conjointe Google/SOASTA Research publiée en février 2017 sous le titre « Find Out How You Stack Up to New Industry Benchmarks for Mobile Page Speed », qui analysait 900 000 landing pages mobiles dans 126 pays. Le contexte technique de 2017 (3G dominante, sites WordPress non optimisés) n'est plus celui de 2026, mais les chiffres sur le comportement des visiteurs face à un site lent sont restés cités depuis car la psychologie de l'attente n'a pas radicalement changé. Citations littérales, sourcées Think with Google PDF officiel :
« 53 % des visiteurs mobiles quittent une page qui met plus de trois secondes à charger » (étude 2017, p. 1).
Quand le temps de chargement passe de 1 s à 3 s, la probabilité de rebond augmente de 32 %. De 1 s à 5 s, elle augmente de 90 %. De 1 s à 6 s, +106 %. De 1 s à 10 s, +123 % (étude 2017, p. 3).
Quand le nombre d'éléments DOM d'une page (textes, titres, images) passe de 400 à 6 000, la probabilité de conversion chute de 95 % (étude 2017, p. 2).
Où en est la performance web mobile aujourd'hui
Depuis 2017, beaucoup a changé : la 4G puis la 5G se sont généralisées, Google a fait des Core Web Vitals un signal de classement direct (juin 2021), et la pression sur les sites pour s'optimiser n'a fait que monter. Le Web Almanac HTTP Archive, publication annuelle de référence sur l'état du web, mesure la progression dans son édition 2025 (almanac.httparchive.org/en/2025/performance) :
62 % des pages mobileatteignent désormais un LCP classé « bon » par Google (< 2,5 s), contre 74 % sur ordinateur.
Reste donc 38 % des pages mobile au-dessus du seuil, dont 13 %classées « médiocre » (LCP > 4 s), soit presque le double du taux observé sur desktop (7 %).
Le poids médian d'une page d'accueil mobile est de 2,6 Mo en 2025, en hausse de 8,4 % par rapport aux 2,4 Mo de 2024.
Un projet en tête ?
Discutons de vos besoins. Premier échange gratuit et sans engagement.
Pour traduire en concret béarnais : si votre site met aujourd'hui plus de 4 secondes à afficher son contenu principal sur smartphone, vous appartenez aux 13 % de pages mobile classées « médiocres » par Google. Sur les requêtes locales concurrentielles (« plombier Pau », « restaurant Navarrenx »), c'est ce qui départage votre site et celui d'un concurrent à contenu équivalent. Et sur le terrain, une part importante des prospects qui cliquent depuis Google Maps ou la SERP reviennent en arrière avant d'avoir vu le bouton « Appeler ». Ce sont des appels qui n'arrivent jamais et que vous ne pouvez même pas mesurer dans votre carnet de rendez-vous.
Les Core Web Vitals : la grille officielle Google 2026
Depuis l'intégration de l'INP en mars 2024 (remplaçant le FID), Google publie trois métriques officielles regroupées sous le terme Core Web Vitals. Sources et seuils, citation littérale web.dev/articles/vitals :
LCP (Largest Contentful Paint). Mesure le temps avant que le plus grand élément visible de la page (image principale, titre H1, bloc héroïque) soit affiché. Cible : « LCP should occur within 2.5 seconds of when the page first starts loading ». Au-delà de 4 s, c'est classé Poor.
INP (Interaction to Next Paint). Mesure la réactivité globale de la page aux interactions clavier, souris, tactiles. Cible : « pages should have a INP of 200 milliseconds or less ». Au-delà de 500 ms, Poor.
CLS (Cumulative Layout Shift). Mesure les sauts de mise en page pendant le chargement (image qui apparaît et pousse le texte vers le bas au moment où on cliquait). Cible : « pages should maintain a CLS of 0.1 or less ».
Google précise que ces seuils sont mesurés « at the 75th percentile of page loads », c'est-à-dire qu'il faut qu'au moins 75 % de vos visiteurs voient ces seuils respectés, pas seulement le test PageSpeed à un instant donné. Et les mesures sont segmentées entre mobile et desktop : un site qui passe sur ordinateur mais rame sur smartphone reste classé en Poor sur l'axe mobile, qui est désormais l'index principal de Google (« mobile-first indexing »).
Pourquoi les sites locaux béarnais sont si souvent lents
En auditant les sites des artisans, restaurateurs et professions libérales de la zone Pau-Navarrenx-Oloron-Salies, je retrouve presque toujours les mêmes causes, dans cet ordre de fréquence.
1. WordPress empilé de plugins
La plupart des sites WordPress installés par des prestataires régionaux comptent entre vingt et trente extensions. Chaque plugin charge son propre CSS, son JavaScript, parfois plusieurs polices web supplémentaires. Cumulé, on arrive à des pages mobiles qui pèsent 4 à 8 Mo, là où une page bien construite tourne entre 200 Ko et 1 Mo. Quand l'étude Google indique que 70 % des pages mobiles analysées dépassent 1 Mo, et que 12 % dépassent 4 Mo, ce sont précisément ces sites-là.
2. Images non optimisées et trop grosses
Une photo de chantier, de plat de restaurant ou de salon de coiffure prise au smartphone fait souvent 4 à 6 Mo en JPEG. Sans redimensionnement ni conversion en format moderne (WebP, AVIF), elle est servie telle quelle au visiteur. Sur 4G rurale béarnaise, ça suffit à pousser le LCP au-delà de 5 s même quand le reste du site est correct. Solution : redimensionner à la taille d'affichage réelle (max 1200 px de large pour un visuel principal mobile), compresser en WebP, et servir des tailles différentes selon l'écran via l'attribut srcset.
3. Hébergement mutualisé bas de gamme
Un hébergement à 3 € par mois sur un serveur mutualisé partagé avec 500 autres sites donne mécaniquement un Time to First Byte (TTFB) de 800 ms à 2 s avant même que le HTML commence à arriver. Sur la zone Béarn, cela se voit particulièrement quand le serveur est aux États-Unis : la latence aller-retour ajoute 150 à 250 ms à chaque requête. Solution : hébergement en France ou Allemagne (Frankfurt) et CDN devant pour rapprocher les fichiers du visiteur.
4. Thèmes et page builders surdimensionnés
Les page builders (Elementor, Divi, WPBakery) sont conçus pour offrir un maximum de flexibilité visuelle, mais ils génèrent du HTML très verbeux, avec des imbrications de div multiples, du CSS inline parasite et un volume de JavaScript souvent inutile pour le visiteur final. Sur des thèmes premium très chargés (multipurpose), le score Lighthouse mobile dépasse rarement 50.
L'effet sur la conversion : ce que les chiffres laissent entrevoir
Si un site béarnais reçoit 200 visites mobiles par mois sur sa page d'accueil (chiffre vérifiable dans Google Search Console pour chaque exploitant), et que son LCP mobile est dans la zone « médiocre » de Google (au-delà de 4 secondes), la combinaison du seuil Google « bon » à 2,5 s et des chiffres comportementaux de l'étude Google/SOASTA 2017 permet d'estimer qu'une fraction significative des visiteurs partent avant d'avoir vu le contenu principal. Un saut de mise en page (CLS > 0,1) ajoute des clics au mauvais endroit et des abandons supplémentaires.
La perte n'apparaît jamais directement dans le carnet d'appels reçus, parce qu'elle est composée d'appels qui n'ont jamais été passés. C'est exactement le type de fuite qu'un site optimisé évite, sans que le commerçant en voie autre chose qu'une augmentation progressive de ses contacts entrants après refonte.
Ce que je fais chez PilotOne pour livrer un site rapide
Tous mes sites tournent sur la même architecture : Next.js (framework React), rendu côté serveur, hébergement Render Frankfurt, et CDN Cloudflare proxy. Voici les choix techniques précis qui font la différence sur les Core Web Vitals.
Server-Side Rendering plutôt que SPA pure
Le HTML de chaque page est généré sur le serveur et envoyé pré-construit au navigateur. Le visiteur voit le contenu apparaître dès la première frame, sans attendre qu'un gros bundle JavaScript se télécharge, s'exécute, et fasse des appels API. Bénéfice direct sur le LCP et sur le SEO (les robots d'indexation lisent le HTML, pas le JavaScript exécuté).
Images modernes automatiques
Le composant next/imageconvertit chaque image en WebP ou AVIF. Selon l'étude WebP officielle de Google Developers, WebP produit des fichiers en moyenne 25 à 34 % plus légers que JPEG à qualité visuelle équivalente. AVIF, plus récent, descend autour de 50 % de réduction par rapport à JPEG (mesures publiques type Ctrl Blog 2023, à qualité visuelle équivalente DSSIM). Le composant génère aussi plusieurs tailles selon la largeur d'écran (192, 384, 512, 640, 750, 828, 1080, 1200, 1920 px) et applique le lazy loading aux images sous la ligne de flottaison. Sur pilotone.fr, l'image hero principale en mobile pèse environ 10 Ko en WebP au lieu de 30 à 80 Ko en JPEG équivalent.
Cache navigateur agressif sur les assets statiques
Tous les fichiers CSS, JavaScript, images, polices sont servis avec l'en-tête HTTP Cache-Control: public, max-age=31536000, immutable, c'est-à-dire un an de cache navigateur. Une fois la première visite faite, toutes les visites suivantes affichent la page en quelques dizaines de millisecondes : tout est déjà sur l'appareil. Le hash de build Next.js change à chaque déploiement, ce qui invalide automatiquement les assets modifiés sans purger les autres.
Cache Edge Cloudflare pour les premières visites
Pour qu'un visiteur béarnais qui arrive sur le site pour la première fois n'attende pas un aller-retour Frankfurt, j'ai mis pilotone.fr derrière Cloudflare avec proxy actif et résolution DNS en CNAME vers le service Render (jamais en A record vers l'IP partagée Render, qui empêche Cloudflare de mettre en cache). Vérification curl en avril 2026 : la deuxième requête sur n'importe quelle page renvoie cf-cache-status: HIT, c'est-à-dire un service depuis le datacenter Cloudflare le plus proche du visiteur (Paris CDG pour la France) au lieu de Frankfurt. Gain mesuré : environ 50 ms de TTFB en moins par requête.
Zéro plugin tiers sur le site vitrine
Là où un WordPress moyen exécute 15 à 30 scripts tiers (chat, popup, traducteur, analytics multiples, RGPD modal, sliders, formulaires, sécurité, etc.), pilotone.fr en charge deux : Umami (analytics respectueux RGPD, 5 Ko) et le code du site lui-même. Pas de jQuery, pas de bibliothèque tierce de slider, pas de tracker publicitaire. Chaque script supplémentaire ajoute du JavaScript à parser et exécuter, ce qui dégrade INP.
Polices web auto-hébergées et préchargées
Les polices Google Fonts via CDN Google ajoutent une requête DNS et TLS vers fonts.googleapis.com et fonts.gstatic.com avant que le texte s'affiche. Solution Next.js : les polices sont téléchargées au build, servies depuis le domaine principal, préchargées dans le HTML. Pas d'effet FOIT (texte invisible) ni FOUT (saut de police). Bénéfice CLS et LCP simultané.
Comment tester votre site existant en cinq minutes
Avant de me confier votre site, je vous encourage à le mesurer vous-même avec des outils gratuits et neutres.
Google PageSpeed Insights (pagespeed.web.dev). Entrez votre URL, attendez 30 s, regardez le score mobile. Sous 50, votre site est cassé techniquement. Entre 50 et 90, marge d'optimisation. Au-dessus de 90, propre. Surtout, regardez la section « Core Web Vitals Assessment » qui indique les chiffres réels mesurés sur vos vrais visiteurs des 28 derniers jours (Chrome User Experience Report).
Google Search Console> section Expérience > Signaux web essentiels. Affiche l'évolution dans le temps de vos URLs classées Bonnes, À améliorer ou Médiocres, par appareil. Si vous avez beaucoup d'URLs en rouge sur mobile, votre référencement local en pâtit mécaniquement.
Lighthousedans Chrome DevTools (touche F12 puis onglet Lighthouse). Audit complet en local, simulant un appareil mobile sur 4G lente. Très utile pour reproduire l'expérience d'un visiteur en zone rurale Béarn avec une connexion moyenne.
Test mobile-friendly Google(search.google.com/test/mobile-friendly). Vérifie la compatibilité tactile, la taille des polices, l'absence de zoom horizontal forcé. Critère obligatoire pour le mobile-first indexing.
Les leviers prioritaires si vous voulez accélérer un site existant
Si vous restez sur WordPress et que refondre n'est pas envisageable aujourd'hui, voici l'ordre des actions à plus fort impact :
Compresser et redimensionner toutes les images. Une seule image hero non optimisée peut gagner à elle seule 1 à 2 secondes de LCP. Plugins gratuits : ShortPixel ou EWWW Image Optimizer.
Désactiver et désinstaller tous les plugins inutilisés. Souvent, on trouve sur les sites des extensions installées il y a deux ans pour tester, jamais supprimées, qui chargent toujours leurs scripts.
Activer la compression Brotli ou Gzip côté serveur, et un cache de page (WP Rocket, W3 Total Cache, ou cache intégré du thème).
Mettre Cloudflare gratuit en proxy devant le site. Un CDN public à coût zéro réduit la latence pour les visiteurs en France quand le serveur est aux États-Unis ou en Asie. Attention à la configuration DNS (CNAME vers le hostname de l'hébergeur, pas vers une IP partagée).
Supprimer ou alléger les sliders et carrousels. Une page d'accueil avec un slider de 5 images animées en JavaScript est à elle seule responsable de la moitié du poids de la page.
Si après tout ça le score Lighthouse mobile reste sous 70, la racine du problème est probablement architecturale (thème lourd, hébergement bas de gamme). À ce stade, refondre coûte souvent moins cher long terme que continuer à patcher.
Conclusion : la vitesse n'est plus négociable en 2026
Avec l'index mobile-first, les Core Web Vitals comme signal de classement, la concurrence locale qui s'intensifie sur Google Maps, et des visiteurs qui décident en moins de trois secondes s'ils restent ou repartent, un site lent n'est plus un détail technique. C'est une fuite de chiffre d'affaires invisible et continue.
Chez PilotOne, je conçois des sites Next.js en partant de l'objectif : LCP mobile sous 1,8 s sur 75 % des chargements, INP sous 100 ms, CLS sous 0,05. Tous mesurés en conditions réelles via Chrome User Experience Report, pas seulement sur un test PageSpeed isolé.
Si vous voulez savoir où vous en êtes avant d'envisager quoi que ce soit, je peux faire un audit gratuit de votre site actuel : trois pages testées, PageSpeed mobile + desktop, Search Console si vous me donnez accès, rapport écrit avec les leviers prioritaires chiffrés. Demandez l'audit, c'est sans engagement et vous ressortez avec un plan d'action que vous pouvez exécuter vous-même ou faire exécuter par n'importe quel prestataire.
