Vitesse de chargement d’une landing page : combien de secondes avant de perdre vos visiteurs ?

Vous avez soigné l’accroche, le formulaire, les témoignages — et pourtant le taux de conversion reste bas. Avant de retoucher le texte, mesurez autre chose : le temps que met la page à s’afficher. Un visiteur qui clique sur une annonce ou un lien Google arrive avec une intention fraîche et une patience très courte ; si la page met du temps à répondre, cette intention se dissout avant même d’avoir vu votre promesse. La vitesse n’est pas un détail technique en marge du copywriting, c’est la première ligne de votre argumentaire de vente.

Ce que disent les études sur la vitesse et la conversion

Deux études, menées à des échelles différentes, convergent vers la même conclusion : la relation entre vitesse et conversion n’est pas linéaire, elle s’effondre à partir d’un certain seuil.

• Google (étude mobile Think with Google / SOASTA) : la probabilité de rebond augmente de 32 % lorsque le temps de chargement passe de 1 à 3 secondes, et de 90 % lorsqu’il atteint 5 secondes. Sur mobile, 53 % des visiteurs quittent purement et simplement un site qui met plus de 3 secondes à s’afficher.
• Portent a croisé plus de 100 millions de pages vues sur une vingtaine de sites B2B et B2C : les pages qui s’affichent en 1 seconde convertissent en moyenne à 39 %, contre 1,9 % à 2,4 secondes et seulement 0,6 % à 5,7 secondes — un écart qui dépasse le facteur 60 entre les deux extrêmes de l’échantillon.

Le détail chiffré varie selon les études et les secteurs, mais le schéma est constant : chaque seconde gagnée sous la barre des 3 secondes rapporte proportionnellement plus que la précédente, et chaque seconde perdue au-delà coûte proportionnellement plus cher que la précédente. Ce n’est pas une courbe qu’on peut lisser par un bon storytelling — un visiteur qui a fermé l’onglet ne lira jamais votre titre.

Le seuil qui compte vraiment : 3 secondes, pas 5

Retenez deux chiffres plutôt qu’un tableau de bord complexe. Sous 1 seconde : la zone où la page se ressent comme instantanée, où l’attention capturée par la publicité ou la recherche Google arrive intacte sur votre promesse. 3 secondes : le plafond dur — au-delà, plus de la moitié des visiteurs mobiles ont déjà quitté la page avant même de la voir se stabiliser. Entre les deux, chaque dixième de seconde de gagné se traduit en visiteurs qui restent assez longtemps pour lire votre accroche. Viser « sous 1 seconde » comme objectif et traiter 3 secondes comme la limite à ne jamais dépasser donne une cible claire, y compris pour discuter avec un prestataire technique.

Pourquoi tant de landing pages sont lentes

La lenteur vient rarement d’un seul gros problème : elle s’accumule, script après script, plugin après plugin.

• Sliders et carrousels en page d’accueil : plusieurs images pleine largeur chargées d’un coup, souvent non compressées.
• Polices web multiples chargées depuis un serveur tiers, chacune ajoutant une requête et un temps d’attente avant l’affichage du texte.
• Scripts tiers empilés : pixel Meta, pixel Google Ads, chat widget, outil de heatmap, popup de sortie — chacun ajoute son propre appel réseau, parfois plusieurs centaines de millisecondes à lui seul.
• Thèmes génériques et page builders (Elementor, Divi et équivalents) qui chargent le CSS et le JavaScript de dizaines de fonctionnalités non utilisées sur la page, en plus de celles réellement affichées.
• Images non optimisées : photos exportées directement depuis un appareil photo ou une banque d’images, jamais redimensionnées ni converties en format moderne.
• Hébergement mutualisé bas de gamme, qui répond lentement dès qu’il partage ses ressources avec d’autres sites au mauvais moment.

C’est aussi l’un des points les plus nets de notre comparatif Next.js vs WordPress pour une landing page : la lenteur d’un site WordPress n’est presque jamais une fatalité du CMS lui-même, mais la conséquence directe de l’empilement de plugins et d’un thème généraliste — un problème structurel qu’aucun réglage ponctuel ne résout durablement.

Comment mesurer la vitesse réelle de votre page

Ne vous fiez pas à votre propre ressenti en ouvrant la page sur votre ordinateur au bureau, connecté en fibre : ce n’est pas la condition de la majorité de vos visiteurs. Trois vérifications suffisent :

1. PageSpeed Insights (outil gratuit de Google) : donne un score et les trois métriques Core Web Vitals qui comptent — LCP (temps d’affichage du plus gros élément visible), INP (réactivité aux interactions) et CLS (stabilité visuelle pendant le chargement). Le rapport mobile compte plus que le rapport ordinateur.
2. GTmetrix ou WebPageTest : permettent de simuler une connexion 4G plutôt que le wifi du bureau, et de voir précisément quelle ressource (image, script, police) bloque l’affichage.
3. Un test manuel en 4G, téléphone en mode avion puis données mobiles réactivées : rien ne remplace l’expérience réelle d’un visiteur pressé.

Les leviers qui font vraiment la différence

Par ordre d’impact généralement observé, du plus rentable au plus marginal :

1. Les images : compressez, redimensionnez à la taille réellement affichée, convertissez en WebP ou AVIF, et différez le chargement (loading="lazy") de tout ce qui n’est pas visible au premier écran. C’est presque toujours le gain le plus rapide à obtenir.
2. Les polices : limitez-vous à une ou deux familles, hébergez-les vous-même plutôt que d’appeler un serveur tiers à chaque visite, et utilisez font-display: swap pour que le texte s’affiche immédiatement dans une police de secours pendant le chargement.
3. Les scripts tiers : auditez chaque tracker et chaque widget. Un chat en direct ou un pixel publicitaire mal chargé peut ajouter, à lui seul, une à deux secondes ; chargez-les en différé (async/defer) et supprimez ceux dont personne ne regarde plus les données.
4. La génération statique : une page pré-générée au build et servie depuis un CDN répond en général bien plus vite qu’une page assemblée à la volée par un CMS et ses plugins à chaque visite.
5. L’hébergement : pour une page dont le rôle est de convertir, un hébergement mutualisé d’entrée de gamme est rarement le bon calcul face au coût d’acquisition du trafic qui l’alimente.

Ce qu’il ne faut pas sacrifier pour gagner quelques millisecondes

La vitesse se poursuit facilement jusqu’à l’absurde : vider une page de ses témoignages, de ses visuels produit ou de ses badges de confiance fait gagner quelques millisecondes et perdre bien plus en pouvoir de conviction. L’objectif n’est pas la page la plus légère possible, mais la page la plus rapide compte tenu de ce dont elle a besoin pour convaincre — voir les 9 sections d’une landing page qui convertit pour ce qui doit y rester. Optimisez le poids des images et des scripts, pas le contenu qui vend.

Le raccourci : partir d’une base déjà rapide

Le plus gros gain de vitesse ne se joue pas dans un réglage fin après coup, mais dans le choix de la fondation technique. Les templates LanderKit sont des pages Next.js pré-générées (aucun CMS, aucun plugin, aucun appel serveur à chaque visite), avec images déjà optimisées et sans script superflu — la base la plus courante pour dépasser 90 sur PageSpeed Insights sans y toucher. C’est particulièrement sensible sur une page e-commerce mono-produit comme notre template e-commerce produit, où chaque visiteur qui abandonne pendant le chargement est un panier perdu — vous pouvez tester sa vitesse réelle sur la démo live. Même logique sur une page de liste d’attente à fort volume comme notre template SaaS waitlist, où la vitesse conditionne directement le nombre d’inscriptions collectées avant le lancement.

La vitesse n’est qu’un des leviers d’une landing page qui convertit, mais c’est celui qui conditionne tous les autres : un formulaire parfait ou un CTA irrésistible ne servent à rien si la moitié des visiteurs a déjà quitté la page avant de les voir. Pour la vue d’ensemble, relisez notre guide 12 leviers pour augmenter le taux de conversion de votre landing page.

Core Web Vitals CLS : pourquoi les éléments qui bougent sur votre landing page font perdre des clics

Un bouton qui se décale de quelques centimètres au moment précis où le visiteur s’apprête à cliquer, un bandeau de cookies qui pousse tout le contenu vers le bas, un titre qui change de taille une fois la police chargée : ce phénomène a un score officiel chez Google depuis 2020, le CLS (Cumulative Layout Shift). Voici ce qu’il mesure exactement, le seuil de 0,1 qui compte, et comment stabiliser une landing page sans sacrifier le design.

Le CLS additionne, sur toute la durée de vie d’une page, l’ampleur de chaque décalage visuel inattendu d’un élément déjà visible à l’écran — pas le premier affichage d’un contenu qui apparaît depuis un espace vide, mais le déplacement d’un élément qui occupait déjà une position stable. Chaque décalage est pondéré par deux facteurs : la part de l’écran affectée par le mouvement, et la distance parcourue par les éléments qui bougent. Un bouton qui descend de deux centimètres pèse donc plus lourd dans le score qu’un léger réajustement de quelques pixels sur un élément secondaire. C’est le troisième des trois Core Web Vitals de Google, aux côtés du LCP (vitesse d’affichage) et de l’INP (réactivité aux clics), que nous détaillons chacun dans un article séparé.

Les causes les plus fréquentes sur une landing page

• Images et vidéos sans dimensions définies — sans attribut width/height ni aspect-ratio CSS, le navigateur ne réserve aucun espace et pousse le contenu suivant dès que le fichier finit de charger.
• Polices web qui changent la taille du texte — un repli sur police système suivi du chargement de la police définitive (FOUT) peut changer la largeur du texte et donc la hauteur des blocs, en particulier sur les titres.
• Bandeau de consentement aux cookies injecté en haut de page — s’il pousse le contenu vers le bas au lieu de s’afficher en overlay, il décale tout ce qui est déjà visible, souvent pile au moment où le visiteur commence à lire ; voir notre article sur le bandeau de cookies.
• Popups et notifications injectées après coup — popup de bienvenue, notification d’achat en temps réel ou widget de chat qui s’ouvrent quelques secondes après le chargement et repoussent le contenu plutôt que de se superposer à lui.
• Publicités et embeds tiers sans emplacement réservé — un iframe publicitaire ou une vidéo intégrée qui ne révèle sa taille finale qu’une fois chargée.
• Contenu inséré dynamiquement au-dessus d’un élément existant — un message d’erreur de formulaire, une alerte de stock ou un badge de réduction ajouté juste au-dessus du bouton d’achat plutôt qu’à un emplacement déjà réservé.

Image hero de landing page : photo, illustration ou capture d'écran ?

L'image hero occupe la moitié de l'écran le plus précieux de votre landing page — celui que 100 % des visiteurs voient. Photo humaine, capture produit, illustration ou pas d'image du tout : comment choisir selon votre offre, ce que la recherche dit des visages et de la mémorisation des images, et les erreurs les plus répandues.

L'image hero a un seul travail : faire comprendre plus vite ce que la page vend, ou pour qui. Elle ne doit ni décorer, ni « habiller », ni gagner un prix de direction artistique. Le test est simple : si on remplace votre image par un rectangle gris, la page perd-elle du sens ? Si la réponse est non, l'image ne travaille pas — elle occupe seulement l'espace le plus cher de la page. Ce rôle de support du message est documenté de longue date : une étude de Terry Childers et Michael Houston publiée en 1984 dans le Journal of Consumer Research sur l'effet de supériorité de l'image montre que les contenus présentés visuellement sont mieux mémorisés que les mêmes contenus présentés en texte seul — à condition que l'image porte le sens, pas qu'elle l'accompagne vaguement. Une image qui montre le produit ou le résultat fait mémoriser l'offre ; une image d'ambiance générique ne fait rien mémoriser du tout.

Les erreurs qui coûtent le plus cher

• La photo de banque d'images reconnaissable — poignée de main, équipe souriante en réunion : le visiteur l'a déjà vue ailleurs, elle signale l'interchangeable et abîme la crédibilité.
• Le carrousel d'images en hero : personne n'attend la deuxième slide, chaque rotation vole l'attention au message, et le poids se cumule.
• L'image trop lourde : une image hero non compressée retarde le rendu du seul écran que tout le monde voit — elle est presque toujours l'élément LCP de la page, celui que mesure Google (voir notre article sur la vitesse de chargement).
• Le texte incrusté dans l'image : illisible sur mobile, invisible pour les lecteurs d'écran et pour les moteurs de recherche — le message appartient au HTML, pas aux pixels.
• L'image qui contredit le titre : un titre « simplicité » sur une capture d'interface surchargée — le visiteur croit l'image, pas le texte.

Quelle police de caractère choisir pour une landing page qui convertit ?

Une police de caractère agit avant même d'être lue : elle installe une personnalité de marque, et sa lisibilité influence la perception de l'effort à fournir pour agir. Deux études — l'une en marketing, l'autre en psychologie cognitive — expliquent pourquoi le choix typographique d'une landing page n'est pas un détail esthétique, et comment le trancher.

Le titre, les arguments, les libellés de formulaire et le texte du bouton d'appel à l'action passent tous par une police de caractère avant d'arriver au visiteur — et ce choix agit deux fois, indépendamment du message qu'il porte. D'abord en installant une personnalité perçue avant même la lecture : une étude de Pamela Henderson, Joan Giese et Joseph Cote, publiée dans le Journal of Marketing, a analysé 210 polices selon 24 caractéristiques de dessin et montre qu'elles se regroupent en six dimensions perçues — élaborée, harmonieuse, naturelle, ornée, épaisse, compressée — qui déclenchent des impressions de marque mesurables et reproductibles (Henderson, Giese & Cote, 2004). Ensuite en modulant l'effort perçu de l'action qui suit, comme le montre la suite de cet article.

Où l'effet de fluidité compte le plus sur votre page

• Le texte du bouton CTA : une police décorative sur « Réserver mon appel » ajoute une friction de lecture au moment précis où elle est la plus coûteuse.
• Les libellés et messages d'un formulaire — voir notre guide de la microcopie de formulaire : une police difficile aggrave l'anxiété déjà documentée face à un champ obligatoire.
• Les blocs de réassurance (garantie, FAQ, mentions) : ce sont eux qui doivent paraître les plus faciles à traiter, pas les plus stylés.
• Le titre principal, à l'inverse, tolère — et parfois recherche — une police plus travaillée : il fixe la personnalité de marque avant que l'effort de lecture ne devienne pertinent.

Preconnect, preload, dns-prefetch : préparer les connexions avant que le navigateur en ait besoin

Avant même de télécharger un fichier, le navigateur doit résoudre le nom de domaine, ouvrir une connexion TCP et négocier le chiffrement TLS — trois allers-retours réseau invisibles, répétés pour chaque domaine tiers que la page appelle (police, widget de chat, vidéo, script de paiement). Les resource hints dns-prefetch, preconnect et preload permettent d'anticiper ce travail avant que le navigateur ne découvre qu'il en a besoin. Bien utilisés, ils grignotent des centaines de millisecondes sur le LCP ; mal utilisés, ils ralentissent la page qu'ils étaient censés accélérer.

<link rel="dns-prefetch"> ne fait que résoudre le nom de domaine à l'avance — l'opération la moins coûteuse des trois, quelques dizaines de millisecondes gagnées, sans effet de bord notable. On peut l'appliquer largement, sur tous les domaines tiers connus de la page, sans risque. <link rel="preconnect"> va plus loin : DNS, poignée de main TCP et négociation TLS, les trois d'un coup. Le gain est plus net — on retire du chemin critique jusqu'à deux allers-retours réseau complets — mais le coût aussi : la connexion reste ouverte, mobilise de la mémoire et du CPU côté navigateur, et si aucune requête ne l'utilise dans les quelques secondes qui suivent, tout ce travail est perdu. <link rel="preload"> est différent dans sa nature : il ne prépare pas une connexion, il télécharge une ressource précise (un fichier de police, une image, un script) en lui donnant une priorité élevée, avant que le navigateur ne la découvre normalement dans le HTML ou le CSS.

Où ça compte vraiment sur une landing page

• Une police Google Fonts non auto-hébergée — chaque visite déclenche une connexion vers fonts.googleapis.com puis fonts.gstatic.com ; un preconnect vers ces deux domaines réduit le délai avant que le fichier de police ne commence à se télécharger (l'auto-hébergement, que nous détaillons dans notre article sur Google Fonts et le RGPD, supprime carrément le problème).
• Un bouton ou un widget Stripe embarqué — le script de paiement charge depuis js.stripe.com ; un dns-prefetch discret évite au visiteur d'attendre la résolution DNS au moment précis où il clique sur le bouton d'achat.
• Une vidéo YouTube ou Vimeo en fond de hero — plusieurs domaines tiers (lecteur, CDN vidéo, tracking) s'ajoutent d'un coup ; ici, mieux vaut souvent différer le chargement de l'iframe elle-même plutôt que de multiplier les preconnect, comme nous le développons à propos de la vitesse de chargement.
• Un widget de chat en direct — Crisp, Intercom ou équivalent chargent leur propre script depuis un domaine distinct ; utile à préconnecter si le widget doit apparaître rapidement, comme nous le couvrons dans notre article sur le chat en direct.
• Le pixel de tracking Meta ou GA4 — ces scripts n'ont presque jamais besoin d'un preconnect : ils ne bloquent rien de visible, et leur exécution différée n'a aucun impact sur le LCP, comme nous le détaillons pour le pixel Meta et le tracking GA4.

Core Web Vitals LCP : pourquoi le premier écran de votre landing page met trop de temps à s’afficher

Le LCP (Largest Contentful Paint) mesure le temps qu'il faut pour que le plus grand élément visible au premier écran s'affiche entièrement — sur une landing page, c'est presque toujours l'image hero ou le titre principal. Au-delà de 2,5 secondes, Google considère l'expérience mauvaise, et le visiteur aussi : il a déjà commencé à douter que la page a fini de charger. Voici ce que mesure exactement le LCP, pourquoi il traîne souvent sur les pages riches en visuels, et comment le corriger sans sacrifier le design.

Le LCP fait partie des trois Core Web Vitals de Google, aux côtés du CLS (stabilité visuelle) et de l'INP (réactivité aux interactions), que nous détaillons dans un autre article. Contrairement au temps de chargement total ou au onLoad du navigateur, le LCP ne s'intéresse qu'à un seul repère : le moment où l'élément le plus grand du viewport visible devient pleinement rendu. Un site peut continuer à charger des scripts, des polices ou des sections plus bas dans la page pendant plusieurs secondes après un bon LCP — cela n'a plus d'impact sur ce score précis, mais peut en avoir sur l'INP ou le ressenti global.

Les causes les plus fréquentes sur une landing page

• Une image hero trop lourde ou mal formatée — un JPEG ou PNG exporté à la taille d'écran desktop, servi tel quel au mobile, ou sans compression moderne (WebP, AVIF).
• Un temps de réponse serveur (TTFB) trop long — hébergement mutualisé surchargé, absence de mise en cache, ou rendu dynamique côté serveur à chaque requête au lieu d'un site statique pré-généré.
• Des ressources qui bloquent le rendu — CSS ou polices chargées de façon synchrone avant que le navigateur ne puisse peindre quoi que ce soit à l'écran.
• Une image découverte trop tard par le navigateur — chargée via JavaScript, en arrière-plan CSS non préchargé, ou cachée derrière un carrousel qui ne révèle la première image qu'après exécution d'un script.
• Une police web qui retarde l'affichage du titre — si le titre est le plus grand élément visible et que la police personnalisée bloque son rendu, c'est elle qui détermine le LCP, pas l'image.

Core Web Vitals INP : pourquoi une landing page rapide au chargement peut quand même perdre des clients

Une landing page peut afficher son hero en 800 ms et pourtant laisser un visiteur cliquer sur le CTA sans que rien ne se passe pendant une demi-seconde. Ce décalage a un nom depuis mars 2024 : l'INP, le Core Web Vital qui mesure l'interactivité, pas le chargement. Voici ce qu'il mesure, le seuil qui compte, et comment l'améliorer sur une landing page Next.js.

L'INP est un facteur de classement Google, mais son impact le plus direct reste comportemental. Une étude d'Ioannis Arapakis, Souneil Park et Martin Pielot présentée à la conférence CHIIR 2021 (voir l'étude) montre que des délais de réponse dépassant 7 à 10 secondes sur mobile déclenchent une hausse mesurable de la frustration et de la fatigue perçue chez l'utilisateur — et que la tolérance chute encore plus vite dès que l'interaction se répète sans réponse fluide. Une autre étude plus ancienne mais toujours citée, celle de John Hoxmeier et Chris DiCesare présentée à l'AMCIS 2000, établit qu'un temps de réponse système qui s'allonge fait baisser la satisfaction perçue de façon quasi linéaire, bien avant tout seuil d'abandon complet. Ces deux travaux ne portent pas spécifiquement sur des landing pages de vente, mais le mécanisme qu'ils documentent — la frustration monte à mesure que l'écart entre l'action et la réponse visuelle se creuse — est exactement ce que l'INP cherche à quantifier sur le web actuel.

Ce qui plombe l'INP sur une landing page, concrètement

• Les scripts tiers chargés en priorité — pixel Meta, tag Google Ads, chat en direct : quand ils s'exécutent au clic plutôt qu'en tâche de fond, ils bloquent le thread principal pile au moment où le visiteur interagit. Voir notre article sur le pixel Meta et l'API de conversions pour les faire tourner côté serveur plutôt que dans le navigateur.
• Les carrousels et sliders animés en JavaScript, dont les gestionnaires d'événements recalculent des positions à chaque interaction — souvent plus coûteux qu'ils n'y paraissent, comme détaillé dans notre article sur les carrousels sur une landing page.
• La validation de formulaire trop gourmande, quand chaque frappe clavier déclenche une re-validation complète du champ plutôt qu'un contrôle ciblé.
• Les widgets de chat et de pop-up tiers qui s'initialisent au chargement puis interceptent les clics suivants pendant qu'ils finissent de s'hydrater.
• Les longues tâches JavaScript (« long tasks ») de plus de 50 ms qui monopolisent le thread principal — souvent un bundle mal découpé plutôt qu'une seule fonction fautive identifiable.

Optimiser les images d’une landing page : formats, poids et chargement

Sur une landing page, les images représentent presque toujours la majeure partie du poids téléchargé — plus que le HTML, le CSS et le JavaScript réunis. C’est aussi le poste où l’on gagne le plus vite : choisir le bon format, servir la bonne taille, compresser correctement et charger dans le bon ordre suffit souvent à faire basculer un score PageSpeed sans toucher au design ni au copywriting.

Le budget d’attente est court. Une étude de Fiona Nah publiée en 2004 dans Behaviour & Information Technology a mesuré le « temps d’attente tolérable » des internautes pour récupérer une information : il se situe autour de 2 secondes, et un retour visuel pendant le chargement allonge sensiblement cette tolérance (voir l'étude). Deux secondes, c’est le temps qu’une seule photo exportée telle quelle depuis un appareil met à arriver sur une connexion mobile moyenne.

Choisir le bon format : le tableau de décision

TTFB : le temps de réponse serveur qui plombe votre landing page avant même le premier pixel

Avant que le navigateur n'affiche le premier pixel, il attend une réponse du serveur : c'est le TTFB, le temps de réponse serveur. Un TTFB élevé grignote le budget de temps de tous les indicateurs qui suivent, LCP en tête, souvent sans qu'on l'ait jamais mesuré directement. Ce qu'il mesure exactement, ce que dit la recherche sur son impact commercial, et comment le réduire sans changer de design.

L’intuition que « ça agace » ne suffit pas à convaincre un client ou un associé de prioriser un sujet aussi technique — la recherche, elle, est plus précise. Dans une étude fondatrice publiée en 2004 dans la revue Behaviour & Information Technology, Fiona Fui-Hoon Nah a mesuré le temps d’attente que les internautes tolèrent avant d’abandonner une page : au-delà d’environ deux secondes sans aucun signal de chargement, l’attention décroche et l’abandon devient probable (Nah, 2004). Plus récemment, une étude menée par Wojciech Stadnik et Zdzisław Nowak sur une plateforme e-commerce réelle sous Magento a établi un lien direct et mesurable entre le temps de chargement moyen des pages et le taux de conversion observé, en s’appuyant sur des données Google Analytics de trafic réel plutôt que sur des tests en laboratoire (Stadnik & Nowak, 2018). Le TTFB n’est qu’une composante du temps de chargement total, mais c’est la première : tout retard accumulé ici se répercute intégralement sur toutes les métriques suivantes.

Les causes fréquentes d’un TTFB élevé sur une landing page

• Hébergement mutualisé surchargé ou géographiquement éloigné — un serveur qui traite des centaines de sites simultanément, ou situé loin de l’audience réelle de la page (données publicitaires géociblées, par exemple), ajoute une latence réseau et un temps de file d’attente cumulés.
• Rendu généré à la volée à chaque requête — un CMS ou un framework qui reconstruit la page dynamiquement (requêtes base de données, appels API, assemblage de template) au lieu de servir un fichier statique déjà prêt.
• Absence de cache ou de CDN — sans mise en cache en périphérie de réseau, chaque visiteur déclenche le traitement complet côté serveur d’origine, même si le contenu n’a pas changé depuis la dernière visite.
• Fonctions serverless en démarrage à froid — une architecture basée sur des fonctions qui s’exécutent à la demande peut ajouter plusieurs centaines de millisecondes lors des premiers appels après une période d’inactivité, si la page principale dépend de ce type de fonction plutôt que d’être pré-générée.
• Plugins ou middlewares excessifs — sur un CMS généraliste, chaque plugin actif (analytics, popups, A/B testing serveur, personnalisation) ajoute un traitement avant l’envoi de la réponse.

Landing page et connexion lente : concevoir pour la 3G, le mode économie de données et les zones mal couvertes

Une campagne Meta pour un artisan tourne un samedi matin : une partie des clics arrive depuis une camionnette garée dans une zone rurale, en 4G faible ou en 3G de secours. Ce visiteur-là ne va pas attendre que 3 Mo de JavaScript et des images en pleine résolution se chargent avant de voir le numéro de téléphone. Ce que la recherche dit de la tolérance des visiteurs mobiles aux délais, et ce qui, très concrètement, permet à une landing page de rester utilisable sur un réseau lent ou instable.

Une étude de Ioannis Arapakis, Souneil Park et Martin Pielot, publiée en 2021 lors de la conférence ACM CHIIR, a mesuré la réaction de vrais utilisateurs mobiles à dix niveaux de latence contrôlée, de 337 ms à environ 13 secondes. Premier enseignement : les visiteurs mobiles se montrent environ quatre fois plus tolérants aux délais que les utilisateurs desktop mesurés dans des travaux comparables. Deuxième enseignement, plus utile pour une landing page publicitaire : passé un seuil de 7 à 10 secondes, cette tolérance s'effondre — les participants rapportent se sentir nettement plus tendus, frustrés et pressés d'abandonner. Le réseau mobile pardonne davantage qu'on ne le pense, mais jusqu'à un point précis, au-delà duquel l'attente devient une expérience négative mémorable plutôt qu'un simple désagrément.

Ce qu'on adapte concrètement sur une landing page

• Images responsives en WebP/AVIF, servies à la bonne taille via srcset plutôt qu'une seule image haute résolution redimensionnée en CSS — voir notre guide optimiser les images d'une landing page.
• Pas de vidéo en autoplay dans le hero quand Save-Data est actif ou que effectiveType renvoie « 2g »/« 3g » — remplacer par l'image poster, sans perdre l'intention détaillée dans notre article sur la vidéo en landing page.
• Chargement différé (lazy loading) sous la ligne de flottaison, complété par des skeleton screens plutôt qu'un espace vide qui donne l'impression d'une page cassée pendant la récupération des données.
• Éviter les carrousels et widgets JavaScript lourds en première vue — notre comparatif sur les carrousels en landing page détaille déjà pourquoi ils coûtent plus qu'ils ne rapportent ; sur réseau lent, le coût grimpe encore.
• preconnect/preload réservés aux ressources vraiment critiques — sur une connexion à latence élevée, chaque connexion supplémentaire ouverte trop tôt retarde les autres ; voir notre guide sur preconnect et preload.
• Chat en direct et widgets tiers chargés en différé, jamais de façon bloquante, comme détaillé dans notre article sur le chat en direct — un script tiers lent à répondre peut retarder l'affichage de tout le reste de la page.

PageSpeed Insights, Lighthouse, GTmetrix : pourquoi les scores de vitesse ne concordent jamais

PageSpeed Insights annonce 45 sur mobile, GTmetrix affiche 92 sur la même URL, et Lighthouse en local dans Chrome grimpe à 98. Trois outils, trois avis contradictoires sur la même landing page — et aucun des trois ne ment. Voici ce que chacun mesure réellement, pourquoi les chiffres divergent, et lequel regarder pour décider quoi corriger.

Lighthouse (qu'il tourne dans Chrome DevTools, en ligne de commande, ou derrière PageSpeed Insights) fait toujours la même chose : il charge la page une fois, dans un environnement contrôlé, avec un réseau et un processeur simulés selon un profil fixe. C'est ce qu'on appelle des données de laboratoire — reproductibles, utiles pour comparer un avant/après, mais issues d'un seul chargement synthétique. PageSpeed Insights, lui, affiche en plus des données de terrain : les métriques réellement mesurées chez vos visiteurs Chrome au cours des 28 derniers jours, agrégées par Google via le Chrome User Experience Report (CrUX) et présentées au 75ᵉ centile, comme nous le détaillons dans notre article sur le LCP. Ce sont deux blocs distincts dans le même rapport : le score chiffré (0 à 100) ne provient que du passage de laboratoire, tandis que le verdict « Bon / À améliorer / Mauvais » sur les Core Web Vitals, lui, s'appuie sur le terrain quand assez de trafic existe. Une page peut donc afficher un score de laboratoire élevé et, juste en dessous, un badge rouge sur le LCP réel — les deux chiffres cohabitent sans se contredire, ils ne répondent simplement pas à la même question.

Une méthode simple pour arrêter de courir après un chiffre

1. Choisissez un seul outil de laboratoire pour vos comparaisons avant/après un changement (toujours Lighthouse, ou toujours GTmetrix avec les mêmes réglages) — comparer un score GTmetrix d'hier à un score PageSpeed Insights d'aujourd'hui ne veut rien dire.
2. Lancez trois passages, pas un seul, et retenez la médiane plutôt que le premier chiffre affiché : cela filtre une bonne partie du bruit lié à la charge du moment.
3. Une fois le site en ligne avec du trafic réel, basculez votre attention sur le rapport « Signaux Web essentiels » de Search Console : c'est la seule mesure qui compte pour le référencement et qui reflète vos vrais visiteurs.
4. Ne visez jamais 100/100 comme objectif en soi : au-delà des seuils « Bon » de chaque métrique (2,5 s pour le LCP, 0,1 pour le CLS, 200 ms pour l'INP), les points supplémentaires n'ont plus d'effet mesurable ni sur le classement ni sur la conversion.
5. Traitez un écart de 3 à 5 points entre deux passages du même outil comme du bruit ; un écart de 20 points ou plus, lui, signale un vrai changement à investiguer.

La Speculation Rules API : rendre le clic sur le CTA d’une landing page vraiment instantané

Un visiteur clique sur « Réserver une démo » ou « Rejoindre la liste d’attente », et attend un instant que la page suivante se charge — quelques centaines de millisecondes qui suffisent à faire hésiter. Le prefetch de Next.js télécharge déjà les données de cette page à l’avance, mais pas son rendu. La Speculation Rules API de Chrome va un cran plus loin : elle exécute et affiche la page cible en arrière-plan avant même le clic, pour une navigation qui semble ne prendre aucun temps du tout.

Deux niveaux de déclenchement, deux niveaux de risque

• « moderate » (au survol ou au pointerdown) : le prérendu ne se déclenche que lorsque le visiteur montre une intention réelle de cliquer — la souris survole le lien, ou le doigt touche l’écran avant le relâchement. C’est le réglage le plus sûr pour une landing page : le nombre de pages prérendues pour rien reste faible, et le gain de temps couvre déjà l’essentiel du délai perçu.
• « eager » (dès l’apparition du lien à l’écran) : le prérendu démarre dès que le bouton d’appel à l’action entre dans le viewport, sans attendre un signal d’intention. Le gain de temps est maximal si le visiteur clique effectivement, mais le coût en bande passante et en requêtes serveur inutiles grimpe vite si beaucoup de visiteurs ne cliquent jamais — à réserver aux pages où le taux de clic sur ce lien précis est déjà connu comme élevé.

L’idée de deviner à l’avance ce qu’un visiteur va demander pour le lui servir plus vite n’est pas nouvelle : dès 1995, une étude d’Azer Bestavros, présentée à la conférence ACM CIKM et consacrée à la spéculation pour réduire la charge serveur et le temps de service sur le Web (voir l'étude), posait déjà le compromis central de toute stratégie de préchargement prédictif : anticiper une requête que le visiteur ne fera finalement jamais consomme de la bande passante et des ressources serveur pour rien, et ce coût grandit avec le nombre de pages spéculées. Sur une landing page, ce compromis se traduit concrètement : chaque URL ajoutée aux règles de spéculation est une page potentiellement chargée, exécutée et rendue en pure perte si le visiteur ne clique pas — d’où l’intérêt de limiter la liste au strict chemin de conversion plutôt que de spéculer sur l’ensemble des liens de la page.

Le bfcache : ce qui se passe vraiment quand un visiteur appuie sur « retour » depuis votre landing page

Un visiteur clique sur « Payer » ou « Réserver un créneau », quitte votre landing page vers Stripe ou Calendly, puis appuie sur retour. Selon un simple en-tête HTTP, deux choses très différentes se produisent : soit sa page réapparaît instantanément, scroll et formulaire intacts, soit le navigateur recharge tout depuis zéro. Le bfcache décide laquelle — et sur Next.js, il se désactive plus facilement qu'on ne le pense.

Une étude de Lara Catledge et James Pitkow, menée à Georgia Tech sur une version instrumentée du navigateur XMosaic et présentée en 1995 à la 3^e conférence internationale sur le World Wide Web (voir l'étude), a suivi 107 utilisateurs pendant 21 jours et mesuré la répartition réelle de leurs actions de navigation : cliquer sur un lien hypertexte arrivait en tête à 52 %, et le bouton retour suivait immédiatement à 41 % — devant tout autre moyen de naviguer, y compris taper une URL. Ce chiffre date d'avant même l'existence du paiement en ligne redirigé vers un domaine tiers, des liens de réservation Calendly ou des formulaires Typeform intégrés par iframe externe — toutes ces étapes qui, sur une landing page moderne, envoient volontairement le visiteur ailleurs avant de le faire revenir. Le retour arrière n'y est pas un raccourci occasionnel : c'est une partie prévisible et fréquente du parcours de conversion lui-même.

Les autres blocages fréquents, indépendants du framework

• Un écouteur d'événement unload — souvent hérité d'un ancien widget de chat ou d'un script analytics — désactive le bfcache sur desktop dans Chrome et Firefox. L'alternative sans effet de bord est l'événement pagehide, qui couvre les mêmes usages sans bloquer la mise en cache.
• Une connexion WebSocket ou une transaction IndexedDB laissée ouverte au moment où le visiteur quitte la page — typique d'un widget de chat en direct qui garde le fil actif en arrière-plan.
• Une confirmation beforeunload (« voulez-vous vraiment quitter cette page ? ») ajoutée sur un formulaire multi-étapes pour éviter une perte de saisie : utile pour le visiteur, mais à tester spécifiquement, certains navigateurs traitant ce cas différemment du simple unload.

Cache-Control et CDN : la stratégie de cache d’une landing page Next.js sur Vercel

Une landing page bien mise en cache se charge en quelques dizaines de millisecondes, sans jamais réveiller le serveur. Mal réglé, ce même cache sert une promo de la veille à tout le monde — ou pire, la réponse destinée à un visiteur à un autre. Ce que fait vraiment Next.js sur Vercel, et comment régler Cache-Control sans se faire piéger.

Trois caches, trois rôles

• Le cache du navigateur — stocké sur l’appareil du visiteur, il évite une requête réseau complète lors d’une deuxième visite. Réglé par l’en-tête Cache-Control renvoyé par le serveur (max-age).
• Le cache CDN (Vercel Edge Network) — une copie de la réponse posée sur des serveurs répartis géographiquement, entre le navigateur et la fonction serveur. C’est lui qui fait qu’un visiteur à Lyon reçoit la page depuis Paris et non depuis la région où l’application est déployée. Réglé par la directive s-maxage, distincte de max-age.
• Le cache interne de Next.js — le Full Route Cache (le HTML et le payload React déjà générés pour une route statique) et le Data Cache (le résultat d’un fetch côté serveur). C’est cette couche qui décide si une page est régénérée à chaque requête ou servie telle quelle depuis le dernier build.

L’intérêt du cache n’est pas seulement le chiffre affiché dans un outil de mesure : c’est de franchir des seuils psychologiques documentés depuis plus d’un demi-siècle. Dans une étude fondatrice de 1968 encore largement citée en ergonomie logicielle, Robert B. Miller (« Response Time in Man-Computer Conversational Transactions ») distingue trois paliers : en dessous de 0,1 seconde, une réponse est perçue comme instantanée ; en dessous d’une seconde, l’enchaînement des actions reste perçu comme continu, sans rupture de concentration ; au-delà de dix secondes, l’attention se détourne. Une réponse servie depuis le cache CDN de Vercel se compte en dizaines de millisecondes ; une réponse qui traverse une fonction serveur, une résolution DNS à froid et une connexion TLS peut facilement dépasser la seconde sur un premier chargement. Ce n’est pas une nuance cosmétique : c’est la différence entre une page qui « répond » et une page qui « charge ».