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 page of the largest of them makes eleven times more requests and transfers eighteen times more bytes than ours. And the column that hurts the most is not that of the total: it's JavaScript's — out of every ten bytes that the biggest one sends to the cell phone, about six are a program, it's 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.017 MB of JavaScript, in 3 files;
• the lightest of the others: 0.03 MB;
• the two biggest: 1.1 MB and 2.2 MB — sixty to a hundred and thirty times ours.

Unloading 1 MB in a decent network takes a short time. Interpret a megabyte 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 eight to sixteen domains of the largest are so many DNS resolutions and TLS presentations — several back and forth 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 with 14 requests, 200 KB and three domains pays far less of this than one with 80 requests and 1.5 MB. Measured from Portugal, first paint on ours lands between 300 and 510 ms.

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 200 KB, 38 are HTML — it's content, it's your page. At 1.9 MB of the second largest, the HTML is a small slice 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 fraction of what the biggest ones carry on any page.

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 requests 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 on number of features — it's the usual race in this category, and there is always someone who runs it better than us on each front. We chose to compete on something else: your page opens. Always. On a phone with one bar of signal too, on inland 4G too, in the diaspora too, 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 requests, how many KB transferred, and how long until the main content appears. compares to the 2.5 seconds line.

So 200 KB is not that little?

It is not, and it is worth saying so. Of those 200 KB, more than half is the theme background and the avatar — your content, not our machinery. The page HTML is 38 KB compressed, and the program that makes it work is 17. One of our pages without a theme background lands near 100 KB. Whoever picks a heavy background pays for it, and that is true on any platform.

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 page on another platform and recreates the blocks without asking for anything from their support. More articles on the topic in our blog.