Your link in bio opens inside Instagram, not in Chrome

What an in-app browser actually is

When someone taps a link in an Instagram profile, iOS and Android hand the app a WebView — a browser engine embedded inside another application. It shares the rendering engine with Safari or Chrome, but almost nothing else. It has its own storage, its own cookie jar, its own lifecycle, and it can be killed the moment the user swipes back to the feed.

That gap matters because the page you built and tested on a desktop with a fast connection is not the page your audience receives. They receive a cold WebView, launched on a cellular connection, competing for memory with a video feed that is still playing behind it.

The four things that break

1. JavaScript arrives late, or not at all

A page that renders itself in the browser has to download a framework, parse it, execute it, and only then paint. On a cold WebView over a weak connection, that is seconds of blank screen. Some in-app browsers also block or delay third-party scripts, and content blockers on iOS apply inside the WebView too. If your links only exist after JavaScript runs, some visitors never see them.

The fix is not optimisation, it is order of operations. Render the page on the server so the markup that arrives already contains the links, and treat JavaScript as an enhancement that can fail without taking the page with it.

2. Storage is partitioned and short-lived

Cookies and local storage set inside an in-app WebView often do not persist and are not shared with the system browser. Anything that depends on remembering a visitor across sessions is unreliable here. That is one of the reasons analytics built on client-side cookies undercounts in-app traffic — the visitor looks new every time.

Counting on the server, at the moment of the click, sidesteps the problem entirely and needs no cookie at all.

3. Images dominate the load

A background photo straight from a phone camera is commonly three to six megabytes. On a good connection that is a pause; on a congested cell it is an abandonment. And because a background image is usually the largest element on screen, it is also what the Largest Contentful Paint metric measures.

• Resize to the width a phone actually displays — around 1080px is plenty.
• Re-encode to AVIF or WebP rather than shipping the original JPEG.
• Blur a background slightly before compressing it. It shrinks the file and makes the text on top readable at the same time.
• Set a hard byte budget and step the quality down until the file fits, rather than skipping compression when it does not.
• Strip EXIF. Phone photos carry GPS coordinates, and a public page is the wrong place for them.

4. Custom URL schemes do not open

Links written as tg:// or whatsapp:// behave inconsistently inside a WebView; some are silently ignored. Use the https forms — t.me and wa.me — which resolve in the browser and then hand off to the app if it is installed.

How to test it honestly

1. 01Open your own page from inside the Instagram app, not from your desktop.
2. 02Do it on cellular data with Wi-Fi switched off.
3. 03Turn JavaScript off in your mobile browser and load the page again. Every link should still be there and still work.
4. 04Check the total transfer size. A link-in-bio page has no excuse to exceed a few hundred kilobytes.

Why this is a design constraint, not a technical detail

Every visual decision on a link-in-bio page is paid for in load time by an audience on a phone. A gradient mesh with backdrop blur looks excellent on a laptop and drops frames in a WebView. An autoplaying embedded player costs several hundred kilobytes before the visitor has decided whether they want it.

That does not mean the page has to be plain. It means the interesting parts should be typography, layout and colour, which cost nothing to transmit, rather than effects that cost a great deal. The pages that perform best in this context tend to be the ones that look deliberate rather than decorated.