Fast to Load, Slow to Scroll: What Profiling Our Own Site on a Phone Found

The portfolio lists sixteen client projects, each a full-width browser frame with a screenshot, a story column, and a handful of small scroll-linked animations. Modern browsers can skip rendering content that is far off screen — the CSS property is called content-visibility — and the page used it. But it used it on the whole list at once: one box, 15,600 pixels tall. Skipping is per element. The moment the top of that box came near the phone's screen, the browser laid out, painted, decoded and started animating all sixteen frames together.

You cannot see that in a load test, because it happens after the page has 'loaded'. You can see it with one line in the browser console: document.getAnimations().length. At the top of the live page, before anyone scrolled, 139 animations were running. On the home page, whose chapters are each a separate box under 2,600 pixels, the same count was 39. That single comparison was the diagnosis.

The fix was to make every row its own box, with an estimated height so the scrollbar stays honest and a little padding so the box does not clip the frame as it drifts. After the change the live page renders none of the sixteen rows at the top and two to five at a time while scrolling, each image decoding as its row arrives — exactly the home page's behaviour. The animation count at the top went from 139 to 15.

The second cost was decorative. Most of our pages had a soft teal glow behind the hero: a large disc with a 130-pixel blur, and an eleven-second animation that made it slowly breathe. A blur that stands still is rasterised once. A blur that moves is re-composited at full screen size on every frame it is on screen, which on a phone means the graphics processor is busy before the page has finished loading. On the portfolio page, four small stat tiles sat on top of that moving glow with a backdrop-filter of their own — so the tiles re-blurred the moving backdrop every frame as well.

Both idioms came out. Glows on every page are static now; the tiles use a plain translucent fill that looks the same. The one exception is the home page's hero, whose three slow blooms are the site's single sanctioned ambient animation. We then counted the same way across the whole site: a loading shimmer that kept sliding under images long after they had loaded — eighteen of them still running on the home page — and a pulsing green dot in every browser-frame address bar, thirty-four of them. Both now run a few times and stop. The audit line is getAnimations().filter(a => a.effect.getTiming().iterations === Infinity), and the answer on every page but the home is now zero.

Backdrop-filter — the frosted-glass look — is cheap on a panel that scrolls with the page, because the content behind it does not change. It is expensive on anything sticky or fixed, because the content behind it changes on every scroll frame and the blur is recomputed each time. We had it on the project pages' sticky action bar, on the tools hub's sticky category strip, on the cookie banner, and on the mute button floating over a playing video, where it was recomputed on every video frame. Every one of those is a near-opaque plain fill now. The tool pages' 176 frosted panels, which scroll with the page, cost nothing per frame and were flattened anyway for consistency.

The way to find these is to scroll first and then count, because a navigation bar often becomes translucent only once the page has moved: [...document.querySelectorAll('*')].filter(e => getComputedStyle(e).backdropFilter !== 'none'). On our site the only element left in that list is the cookie banner while it is open.

Modern frameworks prefetch the pages a visitor might open next, which is a good default for a primary call to action and a bad one for a link nobody taps. Tracing the requests on a fresh visit showed the cookie banner's small 'Learn more' link fetching the cookie policy page — four requests, 35 KB — on the first visit of every page of the site. The 'Back to home' link on every legal page fetched the entire home page, 66 KB, before the visitor had done anything. Someone landing on a privacy policy from an app store listing was downloading half the home page in the background.

Those links now prefetch only when a finger or a pointer actually reaches for them, which is what the navigation bar's logo already did. The audit is to count requests carrying the framework's prefetch marker before any interaction; on our site that count is now zero on every page except the home, which keeps one deliberate prefetch of the contact page.

Two smaller things rounded the week out. The cookie banner covered the lower 40 % of a phone screen until answered — an icon tile, four sentences and a second row of buttons — over the first content of every page. It is one short paragraph and two side-by-side buttons now, 21 % of the screen, and its Decline button has a label instead of a bare ✕ that read as 'close'.

And the stylesheet. We inline CSS into the HTML so that nothing render-blocking stands between the visitor and the first paint, which means every byte of the stylesheet ships inside every page — and, in a framework that streams components, inside the page's data payload and every prefetch as well. One global sheet for 155 routes sent the 129 tools' utilities to the marketing pages and the marketing pages' utilities to the tools. Splitting it into a base plus one sheet per route group cut each document by about 4 KB compressed. That is honest and small: I had estimated it would halve the stylesheet, and measurement said 15 %, because the two halves of the site share most of their vocabulary. Measure before you promise.

None of this needs a lab. It needs a phone-sized viewport, the browser's console, and the habit of looking after the page has loaded rather than before. The checks below took us from a page that stalled to one that scrolls like the home page, and each one is a single line.

Every number above was measured on nexinfinitymeta.ai, and every fix shipped the same day it was measured, behind the same gates we use for client work: a scripted motion harness, a per-page stylesheet coverage check, a byte budget per route, and a parity check across all 219 indexed pages. The earlier post on why a website feels slow on mobile covers the loading half of the problem. This is the scrolling half, and it is where most 'fast' pages are still slow.