Bio Fast Page : parce que le poids décide des clics

Vous publiez une histoire, des milliers de personnes la voient, quelques centaines touchent le lien bio. Et puis il y a un numéro qu'aucun tableau de bord ne vous montre : combien ont fermé la page avant qu'elle ne s'ouvre. Sur un écran vide, dans le compteur, avec une barre de filet, trois secondes ressemblent à dix. La personne retourne au flux et votre clic est décédé sans laisser de dossier.

Le poids de votre page bio n'est pas un détail technique. C'est un filtre à l'entrée de tout ce que vous faites : chaque gramme de plus est une tranche du public qui n'atteint jamais votre contenu.

Les chiffres, mesurés par nous

Le 14 août 2026, nous avons mesuré les pages bio-publiques sur les trois plateformes, toutes par la même méthode : le HTML plus tous les scripts et les feuilles de style qu'il envoie, c'est-à-dire ce qu'un téléphone portable avec un cache vide doit vraiment se décharger avant de pouvoir dessiner le page, déjà compressée comme voyageant sur le net.

Une page de la plus grande d'entre elles fait onze fois plus de demandes et transfère dix-huit fois plus d'octets que les nôtres. Et la colonne qui fait le plus mal n'est pas celle du total : c'est celle de JavaScript - sur dix octets que le plus gros envoie sur le téléphone portable, environ six sont un programme, ce n'est pas votre page. On répète la mesure sur plusieurs pages de chaque plateforme et les chiffres bougent peu : ce n'est pas une page malheureuse, c'est l'architecture.

Le poids que vous ne pouvez pas voir : le téléphone portable doit tout lire

Ce méga et peu arrive compressé. Non compressé, c'est ainsi que le téléphone portable doit lire, exécuter et conserver en mémoire, le compte est différent :

• Kortilink : 0,017 Mo de JavaScript, en 3 fichiers ;
• la plus légère des autres : 0,03 Mo ;
• les deux plus grandes : 1,1 Mo et 2,2 Mo — soixante à cent trente fois le nôtre.

Le déchargement de 1 Mo dans un réseau décent prend peu de temps. Interpréter un mégaoctet de JavaScript sur un téléphone portable à 150 euros prend beaucoup de temps — et son temps de processeur, ce qui ne s'améliore pas car le signal est bon. C'est pourquoi une page comme celle-ci reste lente sur le Wi-Fi sur un ancien téléphone, et c'est la partie qui n'apparaît presque jamais dans les comparaisons.

Ce qu'une demande coûte dans un réseau faible

Dans une bonne connexion fibre, la latence - le temps d'un aller-retour vers le serveur - tourne entre 10 et 20 millisecondes. Dans un 4G faible, dans un train ou dans une campagne, il monte facilement à 300 à 400 millisecondes par voyage. La bande passante peut même exister ; C'est la latence qui tue.

Une note d'honnêteté, car cet argument est obsolète : l'ancienne limite de « six liens par domaine » ne s'applique plus. Les trois plates-formes servent par HTTP/2, ce qui fait passer de nombreux fichiers par une seule connexion. Cinquante-cinq demandes dans le même domaine ne sont plus cinquante-cinq trajets en ligne.

Ce qui continue de coûter, c'est autre chose, et celui-ci n'a pas disparu :

• Chaque nouveau domaine paie l'intégralité de l'entrée. Le HTTP/2 partage un lien, mais uniquement dans le même domaine. Les huit à seize domaines des plus grands sont autant de résolutions DNS et de présentations TLS - plusieurs en allers et retours chacune, avant le premier octet utile. Notre page vit dans un seul domaine.
• Les demandes sont découvertes dans la chaîne. Le navigateur ne sait pas qu'il a besoin du fichier C tant qu'il n'a pas lu le fichier B, qui n'a été demandé qu'après avoir lu A. Chaque maillon de la chaîne paie la latence entière, multiplexée ou non.
• octets sont des octets. À 1,5 Mbps réel - un 4G faible au sérieux - un méga et peu prend près de six secondes à peine en passant le câble.

Une page de 14 requêtes, 200 Ko et trois domaines paie bien moins que celle de 80 requêtes et 1,5 Mo. Mesuré depuis le Portugal, le premier rendu des nôtres se situe entre 300 et 510 ms.

2,5 secondes : la ligne qui s'ouvre à l'abandon

Le benchmark de l'industrie est clair : le web.dev, dans le Core Web Vitals, définit que le contenu principal d'une page doit apparaître en moins de 2,5 secondes L'expérience est considérée comme bonne. Au-dessus de cela, la probabilité d'abandon augmente chaque seconde - et le trafic d'une bio est presque entièrement mobile, le scénario où les pages lourdes souffrent le plus. Données publiques de l'archive HTTP Les données publiques montrent la même tendance pendant des années : les pages grossissent plus rapidement que les réseaux ne s'améliorent.

Dans un bon réseau, toutes les plates-formes semblent rapides, y compris les lourdes. La différence apparaît exactement là où vous ne cherchez pas : sur le téléphone portable de votre suiveur avec un réseau faible. Vous ne voyez jamais votre page ralentir, car vous la mettez en cache. Il voit toujours.

D'où vient le poids ?

Une liste de dix boutons n'a pas besoin d'un mégaoctet de JavaScript. Le poids n'est pas votre contenu, c'est ce que la plate-forme ajoute :

• Suivi et publicité Scripts, qui servent le modèle économique de la plate-forme, pas le vôtre ;
• Cadres de JavaScript qui créent la page de téléphone portable du visiteur au lieu de le livrer prêt ;
• Sources et widgets externes, chacun avec son propre domaine et son propre péage.

C'est pourquoi la bio de Kortilink utilise Rendu sur le serveur : le serveur fournit le code HTML déjà construit, et le téléphone doit simplement l'afficher. Pas de framework pour démarrer, sans des centaines de kilo-octets de JavaScript à interpréter avant que le premier bouton n'apparaisse. Remarquez le tableau ci-dessus : sur nos 200 Ko, 38 sont HTML - c'est le contenu, c'est votre page. À 1,9 Mo de la deuxième plus grande, le HTML est une petite tranche et le reste est une machinerie.

Et nous ne sommes pas purs : notre page apporte également des choses que tout le monde n'utilise pas - les icônes des réseaux sociaux, les six langues. La différence est que ce qui est rare ne sera recherché que lorsque cela est nécessaire. Une biographie avec Stories demande deux autres fichiers, environ 11 Ko ; Un avec des blocs peu utilisés, plus 6 Ko. Dans le pire des cas, c'est 77 ko, ce qui est encore une fraction de ce que les plus gros portent sur n'importe quelle page.

Que pouvez-vous faire maintenant, sur n'importe quelle plateforme

Soyons justes : une partie du poids est entre vos mains, quel que soit l'outil.

1. Tests que vos abonnés voient. Dans Chrome, ouvrez les devTools, activez la limitation du réseau «Slow 4G» et chargez votre bio avec le cache désactivé. C'est la véritable expérience d'une grande partie de votre public.
2. Compressez les images. Une photo de couverture de 2 Mo détruit toute optimisation de la plate-forme.
3. Évitez les widgets intégrés. Un lecteur embarqué peut coûter plus de commandes que la page entière. Un bouton qui ouvre l'application native se convertit mieux et ne pèse presque rien.
4.  Couper les blocs. Moins de blocs, c'est moins de poids et moins d'hésitation - deux gains pour le prix d'un.

Et une note honnête : la vitesse n'enregistre pas un bio mal construit. Une page instantanée avec le mauvais lien en haut le convertit mal. La vitesse décide du nombre d'arrivées ; La structure décide du nombre de clics. Pour la deuxième partie, voir les sept erreurs qui coûtent des clics dans un bio.

Parce que nous insistons là-dessus

Nous pourrions rivaliser sur le nombre de fonctionnalités — c'est la course habituelle dans cette catégorie, et il y a toujours quelqu'un qui la court mieux que nous sur chaque front. Nous avons choisi de rivaliser sur autre chose : votre page s'ouvre. Toujours. Aussi sur un téléphone avec une seule barre de réseau, aussi en 4G à l'intérieur des terres, aussi dans la diaspora, où la connexion n'aide pas toujours.

Parce que chaque visiteur qui abandonne sur l'écran vierge était un flux, une vente ou un contact que vous aviez déjà établi - et que vous avez perdu au dernier mètre du chemin.

Questions fréquentes

Comment mesurer la vitesse de ma page bio ?

Utilise le PageSpeed Insights de Google ou l'onglet Réseau de Chrome DevTools avec une limitation de la 4G et du cache. Regardez trois chiffres : combien de commandes, combien de Ko ont été transférées et combien de temps avant que le contenu principal n'apparaisse. Se compare à la ligne de 2,5 secondes.

Alors 200 Ko, ce n'est pas si peu ?

Non, et il vaut mieux le dire. Sur ces 200 Ko, plus de la moitié est le fond du thème et l'avatar — votre contenu, pas notre machinerie. Le HTML de la page fait 38 Ko compressés, et le programme qui la fait fonctionner en fait 17. Une de nos pages sans fond de thème approche les 100 Ko. Qui choisit un fond lourd le paie, et c'est vrai sur n'importe quelle plateforme.

Comment l'avez-vous mesuré et puis-je le répéter ?

Vous pouvez. Nous avons téléchargé le code HTML de chaque page, puis tous les fichiers JavaScript et de style qu'il nomme, en ajoutant les octets au fur et à mesure qu'ils voyagent compressé - pas d'estimations. Nous n'avons pas compté les photographies (passer d'une page à l'autre) ni les demandes que chaque plate-forme effectue après, telles que les statistiques. Cette dernière décision profite à la compétition, pas à nous : leur nombre est un minimum et le réel est plus grand. De votre côté, les devtools de Chrome sur l'onglet Réseau, avec "Désactiver le cache", vous donnent le même type de lecture pour n'importe quelle page.

Changer de plate-forme à cause de la vitesse vaut le travail ?

Si vos analyses affichent de nombreuses visites et quelques clics, et que votre audience est sur les réseaux mobiles, c'est probablement le cas - et le travail est plus petit qu'il n'y paraît : notre importateur lit votre page publique sur une autre plateforme et recrée les blocs sans rien demander de leur soutien. Plus d'articles sur le sujet dans notre blog.