A design studio spends months on a website. The photography is real, not stock. The typography is custom, chosen specifically because it doesn't look like every other studio's site. The layout breathes. By every visual standard covered in conversations about what makes a site feel premium, this one qualifies. And then, a few weeks after launch, a strange pattern starts showing up in the feedback: nothing anyone can quite name, but the word "glitchy" keeps coming up from people who were also, somehow, impressed by how it looked.
That contradiction is the entire subject of this piece. It's a composite situation, not a specific named client, but it's a pattern common enough to be worth walking through in full — because the cause, once found, turns out to be one specific, well-documented, completely fixable thing: a page that visually jumps while it's loading, in a way too fast and too small to describe, but not too fast or too small to feel.
The symptom nobody could describe precisely
The complaints, when they came, were vague in a specific and telling way. Nobody said "your layout is broken." They said things closer to: the page feels a little off on my phone. I tried to tap the contact button and it moved. It felt like the site stuttered for a second. None of these are bug reports in the conventional sense — there's no error message, no broken link, nothing a visitor could screenshot and send over even if they wanted to help. It's closer to the sensation of a step that isn't quite where your foot expects it to be. You don't need to see the staircase to feel that something's wrong with it.
That kind of complaint is easy to dismiss, and that's exactly the danger. A designer looking at the finished site on a fast office connection, with the page already cached from twenty previous visits, will never reproduce the problem. It only shows up for a first-time visitor, on a real connection, loading the page cold — which is to say, it only shows up for exactly the audience a business can least afford to lose: the stranger who's never seen the site before and is deciding, in real time, whether it's trustworthy.
The number that finally made the problem visible
The actual diagnosis didn't come from a designer's eye. It came from a performance report — specifically, from a metric called Cumulative Layout Shift, one of Google's three Core Web Vitals, alongside loading speed and responsiveness. A layout shift occurs any time a visible element changes its position from one rendered frame to the next. CLS adds up the size and distance of every one of those unexpected movements across a page's load, and turns it into a single score. To provide a good user experience, sites should strive to have a CLS score of 0.1 or less, and poor values are greater than 0.25.
The site in question wasn't failing catastrophically — it wasn't sitting at some extreme number — but it was consistently landing in the "needs improvement" range on mobile, specifically on the homepage and the project pages, which happened to be exactly the two templates using the custom display typeface most heavily. That correlation turned out to be the whole story. Google's own internal research on how these thresholds were set is worth noting here, because it explains why a score in that middle range isn't a rounding error: in internal testing, levels of shift from 0.15 and higher were consistently perceived as disruptive, while shifts of 0.1 and lower were noticeable but not excessively disruptive. In other words, the research behind this metric wasn't built around some abstract technical ideal. It was built around the exact threshold at which real people start to consciously register that something is wrong — which maps precisely onto "glitchy" being the word visitors kept reaching for.
Finding where the movement actually lived
A single CLS number doesn't tell you where the shift is happening, only that it's happening somewhere. The next step was watching the page load in slow motion — literally, using a throttled connection in the browser's developer tools and stepping through the load frame by frame, the same way you'd review a hairline fracture rather than just noting that the vase is cracked somewhere.
The culprit, once isolated, was almost embarrassingly simple: the custom display typeface used for every headline on the site was a web font, loaded from a stylesheet, and before it finished downloading, the browser was rendering those headlines in a fallback system font — then replacing that fallback the instant the real font arrived. This is a well-understood behavior with two established names depending on configuration. Flash of unstyled text (FOUT) means the text shows up in the fallback font, visible to the visitor but not in the font family it should be, while Flash of Invisible Text (FOIT) means there's no alternative font, so the text doesn't show up until the font is loaded. The site had configured its fonts to avoid FOIT — text was never invisible — but that configuration created FOUT instead, and nobody had checked whether the fallback font and the custom font actually occupied the same amount of space on the page.
They didn't. The custom display face was wider and taller per character than the system fallback standing in for it, which meant every headline, every button label, every navigation item rendered first at one size and then visibly grew into another a few hundred milliseconds later — long enough to be invisible to a designer who'd seen the page load a hundred times, and long enough to register, subconsciously, as instability to someone seeing it for the first time. A detailed breakdown of this exact mechanism, including a real example of a publisher's site shifting when its fallback and web fonts don't share dimensions, is laid out well in Simon Hearne's widely cited writeup on the problem: setting body text to font-display: optional while setting the heading font to font-display: swap is one workable compromise between design and performance, since swapping in the heading font does not cause a layout shift in most cases except multi-line headings. The studio's site was doing the opposite — swapping in its most visually distinctive, least size-matched font, on exactly the elements most likely to span multiple lines on a phone screen.
Why this problem disproportionately hits premium sites
This is worth pausing on, because it's not an accident that this exact failure mode shows up so often on sites that are trying hardest to look expensive. A generic template using a default system font or a very common, well-matched web font rarely has this problem, simply because common fonts are more likely to have widely available, well-tuned fallback configurations already baked into the tools people use to load them.
A premium site, almost by definition, is more likely to be running a distinctive, less common display typeface — that's part of what makes it look considered rather than templated. But a more distinctive font is also, mechanically, more likely to differ sharply in width and height from whatever generic font a browser reaches for while it's still downloading. The same instinct that makes a site look less generic is the instinct that makes this specific failure more likely, unless the fallback is deliberately tuned to match. One real-world demonstration of this exact mismatch, cited in a breakdown of how fonts affect Core Web Vitals, describes a news site where a Helvetica fallback font doesn't occupy the same space as the Fira Sans web font loaded afterward, which generates a layout shift in the title that shifts all the content below it. That's precisely the mechanism at play here, just with a bespoke display face in place of Fira Sans.
There's a second reason this hits premium sites specifically: the whole value proposition of that kind of site rests on the idea that attention to detail at the visual level implies attention to detail everywhere else. A visible, physical jump on the page is a direct contradiction of that claim, delivered at the exact moment a visitor is forming their first impression. It's not just a bug. It's a bug that specifically undercuts the one thing the site was built to communicate.
What the fix actually involved
The fix had three layers, each addressing a slightly different piece of the same underlying mismatch, and none of them involved abandoning the custom typeface — the goal was never to make the site more generic, only to make the transition between fallback and final font invisible.
Matching the fallback font's metrics to the real font's metrics. Modern CSS allows a developer to define a fallback font-face with explicit overrides — properties like size-adjust, ascent-override, and descent-override — that force a generic system font to occupy exactly the same horizontal and vertical space as the custom font that will eventually replace it. A clear technical walkthrough of this exact technique explains that the fix is to tune your fallback stack using size-adjust, ascent-override, descent-override, and line-gap-override inside a second @font-face block that targets the system fallback font, and matching metrics tightly enough keeps layout shift close to zero even before the custom font arrives. In practice, this meant measuring the actual character widths of the display typeface against a few common system fonts, picking the closest match, and then adjusting that match's reported size until headlines occupied functionally identical space in both states. When that's done correctly, DebugBear's writeup on the problem notes, by choosing a good fallback font, using font-display: swap, and using font face descriptors, you can minimize such layout shifts and provide a better experience for your users.
Preloading the critical font file. Beyond matching metrics, the second layer was making sure the actual font file started downloading as early in the page load as technically possible, using a preload hint in the document head, rather than waiting for it to be discovered partway through loading the page's stylesheet. The goal here isn't to prevent the swap from happening — it's to shrink the window in which a mismatched version is visible at all, since a font that arrives before the browser finishes its first paint never has to swap in visibly in the first place.
Moving the whole font-loading process onto the framework's built-in handling. Because the site was already built in Next.js, the longer-term fix was switching from manually linked font files to the framework's native font module, which handles both of the above automatically rather than requiring them to be hand-tuned and maintained. Vercel's own writeup on the feature is direct about what it's solving: next/font automatically self-hosts your custom fonts, preventing layout shift and significantly reducing needed code. The mechanism behind that claim is the same metric-matching technique described above, just automated: next/font calculates the size-adjust property based on the actual font files, making the calculation available on the server before the font is even requested, which allows it to generate a fallback font that matches the spacing of your custom font, ensuring a seamless swap. The official Next.js documentation confirms this is on by default rather than something a developer has to remember to configure: for next/font/google, a boolean value sets whether an automatic fallback font should be used to reduce Cumulative Layout Shift, and the default is true.
It's worth being honest about how this fix was found rather than invented from scratch. This wasn't a novel technique discovered through trial and error — it's a documented, widely used solution that platform teams like Vercel's had already built, tested, and written publicly about. The actual work here was studying how that solution worked at the mechanical level — why metric overrides fix the problem rather than just masking it — decomposing it into the specific properties doing the work, and then rebuilding the site's own font-loading approach around that understanding rather than copying a configuration blind and hoping it applied cleanly to a different typeface and a different build. That distinction — understanding why a fix works well enough to adapt it, rather than pasting it and moving on — is most of what separates a fix that holds up from one that breaks the next time a font or a layout changes.
Confirming it actually worked
Once the fallback metrics were tuned and the font-loading approach was rebuilt, the same diagnostic process ran in reverse: reload the page on a throttled connection, step through the load frame by frame, and watch for movement. There wasn't any. The headline rendered once, in a fallback font sized and spaced identically to the real one, and the swap — when it happened — was invisible rather than felt.
It's worth being precise about what can and can't be claimed from a single composite case like this one. No specific before-and-after conversion number is cited here deliberately, because this is a composite pattern rather than a documented client engagement with controlled measurement. But the mechanism itself is well studied at scale, and the direction of the effect is not in doubt. Google's own published case studies on Core Web Vitals are worth citing directly here, because they involve real companies fixing exactly this kind of problem: Redbus found that reducing CLS from 1.65 to 0 significantly uplifted their domain rankings globally, and separately, Yahoo! Japan fixed CLS which led to a 98% reduction in poor pages and a 15% uplift in page views per session, while AliExpress improved CLS by 10 times and LCP by double, which translated to 15% lesser bounce rates.
It's also worth including the more skeptical side of this research rather than only the flattering case studies. A broader correlational analysis across seven sizable sites found a more modest relationship: Portent's own study reported that good CLS and sessions showed a correlation of 0.189, indicating a weak positive correlation, and a somewhat stronger one against conversions specifically. The honest takeaway from putting both of these next to each other isn't that fixing CLS is a guaranteed growth lever on its own — it's that it behaves like most trust-related fixes do: the sites with the worst, most visible problems see the clearest gains, while sites that were already reasonably stable see smaller, harder-to-isolate ones. A site with a CLS score deep in "poor" territory, with visible, describable jank, is in the first category, not the second.
What generalizes beyond this one case
The specific fix here — font fallback metrics, preloading, a framework's built-in font module — is narrow by design. The lesson underneath it is not. A website's "premium" quality was never only a visual question, even though visual decisions are the easiest part of it to evaluate in a screenshot and a pitch deck. A meaningful share of what a visitor actually experiences as quality or its absence is invisible in exactly this way: not a color choice or a layout decision, but a technical behavior that only shows up in motion, under real-world conditions, to a first-time visitor who will never articulate what felt wrong.
That has a practical implication for anyone evaluating their own site, premium or otherwise. A finished screenshot, or even a quick click-through on a fast connection, will not surface this class of problem. It requires deliberately testing the thing a static review skips: the load itself, on a throttled connection, watched frame by frame rather than judged by its final resting state. Most teams review the destination. Very few review the arrival.
It also says something about where design effort should actually go on a project that's trying to earn the word "premium" honestly. A distinctive typeface is a legitimate, valuable design decision — nothing here argues against using one. But choosing a distinctive font and then failing to account for how it behaves while it's still loading is choosing the visible half of a decision and skipping the invisible half, and the invisible half is exactly where a visitor's gut sense of whether a site feels solid actually gets formed. The two halves aren't separable. A font choice that isn't paired with a loading strategy isn't really finished — it's a design decision with its engineering consequences left for a visitor to discover first.
Where this leaves a site owner who isn't a developer
Nobody running a design studio, a boutique firm, or a professional practice needs to personally understand size-adjust or ascent-override. What's worth taking away instead is a standard to hold a build to: ask, specifically, whether the person building or maintaining the site has checked Cumulative Layout Shift on mobile, under a throttled connection, not just glanced at a performance score in good lighting on a fast laptop. Ask whether custom fonts are loaded through a method that handles fallback matching automatically, rather than a plain stylesheet link copied from a tutorial. These are small, specific, checkable questions — not vague reassurance-seeking about whether a site "feels fast" — and they're the kind of question that separates a build where performance was treated as part of the design from one where it was treated as somebody else's problem to find out about later, usually from a visitor who never says anything and just leaves.