BIO FAST PAGE: Because the weight decides the clicks

You publish a story, thousands of people see it, a few hundred touch the bio link. And then there is a number that no dashboard shows you: how many have closed the page before it opens. On a blank screen, in the meter, with a net bar, three seconds look like ten. The person returns to the feed and your click has died without leaving a record.

The weight of your bio page is not a technical detail. It's a filter at the entrance of everything you do: every gram more is a slice of the audience that never reaches your content.

The numbers, measured by us

On August 14, 2026, we measured bio-public pages on the three platforms, all by the same method: the HTML plus all the scripts and style sheets it sends — that is, what a cell phone with an empty cache really has to unload before being able to draw the Page, already compressed as traveling on the net.

A Linktree page makes eleven times more orders and transfers eighteen times more bytes than ours. And the column that hurts the most is not that of the total: it's that of JavaScript — out of every ten bytes that Linktree sends to the cell phone, more than nine are a program, they are not your page. We repeat the measurement on several pages of each platform and the numbers move little: it is not an unhappy page, it is the architecture.

The weight you can't see: the cell phone has to read it all

That mega and little arrives compressed. Uncompressed, which is how the cell phone has to read, execute and keep in memory, the account is different:

• Kortilink: 0.04 MB JavaScript, in 3 files;
• Beacons: 0.7 MB, in 14 files;
• Linktree: 3.9 MB, in 51 files.

Unloading 1 MB in a decent network takes a short time. Interpret 3.9 MB of JavaScript on a 150 euros mobile phone takes a long time — and it's processor time, which doesn't improve because the signal is good. That's why a page like this remains slow on Wi-Fi on an old phone, and it's the part that almost never appears in comparisons.

What a request costs in a weak network

In a good fiber connection, latency — the time for a round trip to the server — runs at 10 to 20 milliseconds. In a weak 4G, in a train or in a countryside, it easily rises to 300 to 400 milliseconds per trip. The bandwidth can even exist; It is latency that kills.

A note of honesty, because this argument is out of date: the old limit of «six links per domain» no longer applies. The three platforms serve by HTTP/2, which makes many files pass through a single connection. Fifty-five requests to the same domain are no longer fifty-five trips in line.

What continues to cost is something else, and this one has not disappeared:

• Each new domain pays the entire entry. The HTTP/2 shares a link, but only within the same domain. The four Linktree domains are four DNS resolutions and four TLS presentations — several rounds and rounds each, before the first useful byte. Our page lives in one domain.
• Requests are discovered in chain. The browser does not know that it needs the C file until it has read file B, which only asked after reading A. Each link in the chain pays the entire latency, multiplexed or not.
• Bytes are bytes. at 1.5 real Mbps — a weak 4G seriously — a mega and little takes close to six seconds just passing the cable.

A page of 5 requests, 60 KB and a single domain has none of this to pay. Even at 400 ms of latency, it's on screen in about a second.

2.5 seconds: the line that separates open from giving up

The industry benchmark is clear: the web.dev, in the core web vitals, defines that the main content of a page should appear in less than 2.5 seconds to the experience is considered good. Above that, the probability of abandonment grows every second — and the traffic of a bio is almost all mobile, the scenario where heavy pages suffer the most. Public data from the http Archive public data show the same trend for years: Pages get fat faster than networks improve.

In a good network, all platforms look fast — including heavy ones. The difference appears exactly where you are not looking: on your follower's cell phone with a weak network. You never see your page slow, because you have it cached. He always sees.

Where does the weight come from?

A list of ten buttons doesn't need a megabyte of JavaScript. Weight is not your content — it's what the platform adds:

• Tracking and Advertising scripts, which serve the platform's business model, not yours;
• Frameworks of JavaScript that build the visitor's cell phone page instead of delivering it ready;
• Sources and external widgets, each with their own domain and latency toll.

That's why Kortilink's bio uses Rendering on the server: the server delivers the already built HTML, and the phone just needs to show it. No framework to boot, without hundreds of kilobytes of JavaScript to interpret before the first button appears. Notice the table above: of our 60 KB, 36 are the HTML — it's content, it's your page. At 1.1 MB of Linktree, the HTML is 35 KB and the rest is machinery.

And we are not pure: our page also brings things that not everyone uses — the icons of social networks, the six languages. The difference is that what is rare will only be sought when it is needed. A bio with Stories asks for two more files, about 11 KB; One with little used blocks, plus 6 KB. In the worst case it's 77 KB — still a quarter of what Beacons loads on each and every page, and a fifteenth of Linktree.

What can you do now, on any platform

Let's be fair: part of the weight is in your hands, whatever the tool.

1. tests as your followers see. In Chrome, open the DevTools, activate the network limitation «Slow 4G» and load your bio with deactivated cache. It's the real experience of a lot of your audience.
2. Compress the images. A 2 MB cover photo destroys any platform optimization.
3. Avoid built-in widgets. An embedded player can cost more orders than the entire page. A button that opens the native app converts better and weighs almost nothing.
4. Cut blocks. Less blocks is less weight and less hesitation — two gains for the price of one.

And an honest note: Speed doesn't save a poorly built bio. An instant page with the wrong link at the top converts it badly. Speed decides how many arrive; The structure decides how many click. For the second part, see the seven errors that cost clicks in a bio.

Because we insist on this

We could compete in number of features — it's the custom race in this category, and we explained in our Comparison of alternatives to Linktree who runs it better than us on each front. We chose to compete in something else: your page opens. always. Also on the cell phone with a network bar, also in the 4G of the interior, also in the diaspora where the connection does not always help.

Because every visitor who gives up on the blank screen was a stream, a sale or a contact that you had already made — and that you lost in the last meter of the way.

Frequently asked questions

How do I measure the speed of my bio page?

Uses Google's PageSpeed Insights or the Network Tab of Chrome DevTools with limitation 'Slow 4G' and cache disabled. Look at three numbers: how many orders, how many KB transferred, and how long until the main content appears. compares to the 2.5 seconds line.

60 KB really arrives for a page with images?

The 60 KB is the page itself — structure, styles, the code that makes it work and your content, measured in four of our bio pages seriously, with results between 60.5 and 61.9 KB. Your images add up to that, and that's why compression matters. The difference is the starting point: those who start at 1.1 MB have already spent their entire budget before reaching your profile picture.

How did you measure it, and can I repeat it?

You can. We downloaded the HTML from each page, and then all the JavaScript and style files it names, adding the bytes as they travel compressed — no estimates. We did not count the photographs (change from page to page) or the requests that each platform makes after drawing, such as statistics. This last decision benefits the competition, not us: their numbers are a minimum, and the real is greater. On your side, Chrome's DevTools on the Network tab, with 'Disable Cache' on, give you the same type of reading for any page.

Switching platforms because of speed is worth the work?

If your analytics show a lot of visits and few clicks, and your audience is on mobile networks, it probably does — and the work is smaller than it looks: our importer reads your public Linktree or Beacons page and recreates the blocks without asking for anything from their support. More articles on the topic in our blog.