Every page on adg-advisory.com shows a price in rupees somewhere: home, case studies, work with us, workshops, services, many posts. To draw that one rupee sign, the browser was downloading Montserrat's entire latin-extended font file, 68 KB, for a single glyph. In mobile lab runs, that file sat ahead of first paint in the loading chain. Blocking it on its own moved the home page's first contentful paint from 1.68 seconds to 1.23 seconds.
The fix was not to touch the stylesheets, which we had already tried. It was to stop asking the browser for a font it did not need.
One glyph does not need a whole font
We cut a 1.1 KB subset of the same font containing only the rupee sign, kept the weight range so it renders identically from light to bold, and declared it with a narrow unicode-range so the browser only ever fetches it to draw that one character. The sign looks pixel-identical. The other 67 KB simply stopped being requested.
The browser only knows to ask for what you tell it to ask for. A unicode-range is one of the few places on the web where you can tell it, precisely, which characters a font file is for, so it only loads when something on the page actually needs that character set, not the whole thing because one symbol lives inside it.
The blog list was carrying every article it linked to
The same day, we found the same mistake in a different shape. The /blog index page listed 55 posts, and its HTML was 475 KB, 78% of it the full text of every single article, including the 54 a visitor had not clicked on.
The cause was structural, not a missing compression setting: the page passed whole post objects, body text included, into the client-side component that renders the list. Everything handed to a client component gets serialised into the page (React's documentation on the client boundary spells out that props crossing it must be serialisable), whether the component displays it or not. The list only ever needed a title, topic, excerpt, pillar, author and read time, so we built a slimmer card that takes just those fields and passes nothing else across that boundary.
The page dropped from 475 KB to 150 KB (132 KB to 26 KB compressed), with no change to what a visitor sees or how search, filters and "load more" behave.
Not every fix that feels fast actually is
Along the way we also tried inlining the site's CSS, on the theory that fewer render-blocking stylesheets would be the bigger win. First paint improved by about 0.3 seconds, but the HTML itself roughly doubled in size, the home page's largest contentful paint got slightly worse, and the overall score did not move. We reverted it. The expensive thing is not always the thing that looks expensive; it is worth measuring the specific claim before keeping a change, not just the direction it was supposed to push things.
The pattern
Both bugs were invisible in a design review, because nothing looked wrong on screen. They only show up when you look at what actually crosses the wire: a font request that outweighs the page it serves, a list that quietly carries every detail page it links to. Checking that is not a one-off audit; it is a habit worth keeping on any page that grows without anyone revisiting what it sends.
This is the same discipline behind the Hexagram Audit: the problem that matters is rarely the one that is visible from the outside. If you want the same scrutiny applied to your own marketing architecture, the Hexagram Diagnostic is the free first step, and working with us covers what the full engagement looks like. A related story: the rendering bug that was hiding in our own diagnostic tool.
