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 Linktree fait onze fois plus de commandes 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 Linktree envoie au téléphone portable, plus de neuf 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,04 Mo Javascript, dans 3 fichiers ;
• balises : 0,7 Mo, dans 14 fichiers ;
• LinkTree : 3,9 Mo, dans 51 fichiers.

Le déchargement de 1 Mo dans un réseau décent prend peu de temps. Interpréter 3,9 Mo 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 quatre domaines Linktree sont composés de quatre résolutions DNS et de quatre présentations TLS - plusieurs tours et tours chacun, 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 5 requêtes, 60 Ko et un seul domaine n'a rien à payer. Même à 400 ms de latence, c'est à l'écran en une seconde environ.

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 60 Ko, 36 sont les HTML - c'est du contenu, c'est votre page. À 1,1 Mo de Linktree, le HTML est de 35 Ko et le reste est de la 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, il s'agit de 77 ko, ce qui compte encore un quart des charges de balises sur chaque page et un quinzième de Linktree.

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 pouvions concourir en nombre de fonctionnalités - c'est la course personnalisée dans cette catégorie, et nous avons expliqué dans notre comparaison des alternatives à Linktree qui les exécute mieux que nous sur chaque front. Nous avons choisi de concourir dans autre chose : votre page s'ouvre. Toujours. Aussi sur le téléphone portable avec une barre de réseau, également dans la 4G de l'intérieur, également 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.

60 ko arrive vraiment pour une page avec des images ?

Le 60 Ko est la page elle-même - structure, styles, le code qui le fait fonctionner et votre contenu, mesurés dans quatre de nos pages bio, avec des résultats compris entre 60,5 et 61,9 Ko. Vos images s'ajoutent à cela, et c'est pourquoi la compression est importante. La différence est le point de départ : ceux qui commencent à 1,1 Mo ont déjà dépensé tout leur budget avant d'atteindre votre photo de profil.

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 Linktree ou Beacons publique et recrée les blocs sans rien demander de leur soutien. Plus d'articles sur le sujet dans notre blog.