DEV Community: Artur Smirnov

A 4 MB logo drawn at 36 pixels: the two files that skipped the image optimiser

Artur Smirnov — Fri, 07 Aug 2026 22:41:56 +0000

A landing page I measured last week sends 11.7 MB to a phone. Two files account for 11.2 MB of it:

file	weight	how it appears
`how_it_works.png`	6.9 MB	one enormous raster image
`logo.png`	4.1 MB	a 2048 px file, drawn on screen at 36 px

Four megabytes of logo to paint an icon the size of a fingernail.

The part that makes this worth writing about is not the number. It is that the rest of the page was done correctly. The before/after sample images on the same page go through the framework's image component and arrive on mobile at 71 KB and 54 KB, properly narrowed to w=640. Someone set that up, and it works.

So the site does not have a person who doesn't care about images. It has two <img> tags.

The optimiser is opt-in, and nothing tells you when you opted out

Every modern framework ships an image pipeline — next/image, Nuxt Image, Astro's <Image>, Gatsby, whatever your stack calls it. Point it at a file and you get resizing, format negotiation, a srcset, lazy loading, the lot.

Point nothing at it and you get the original file, at original size, forever.

That is the whole bug. The two heavy files were plain <img> tags. They render identically to the optimised ones. Same layout, same crop, same visual result at every breakpoint. There is no warning, no build error, no lint rule firing by default, and no visual difference to catch in review — because at 36 px on screen, a 2048 px source and a 72 px source look exactly the same.

It usually happens the same way, too. The optimised images are the ones that arrived in the content pipeline — product shots, gallery items, anything in a loop. The unoptimised ones are the furniture: a logo dropped in during the first hour of the project, a diagram exported from Figma and dragged into the hero. They get placed once, early, by someone who is not yet thinking about performance, and then they are never touched again because they are never wrong.

How to check yours in about a minute

Open DevTools, Network, filter to Img, disable cache, reload. Sort by size, largest first.

Then look at the URLs, not the file names. Optimised assets carry the pipeline's signature — /_next/image?url=…&w=640&q=75, /_ipx/, /_vercel/image, a CDN transform path, something with dimensions in the query string. Unoptimised ones are just /logo.png.

Anything at the top of that list without a transform in its URL is a file that skipped the pipeline. That's your answer, and it takes longer to read this paragraph than to run it.

Two follow-ups worth thirty seconds each:

Compare rendered size to natural size. In the Elements panel, hover the image: Chrome shows both. A 2048 px file in a 36 px box is a 57× overshoot in each dimension.
A logo almost never needs to be a raster at all. Ours is an icon: SVG, or a 72 px PNG at 2× if the mark is too painterly to vectorise. Either one is measured in kilobytes.

The honest part: quote weight, not time

I ran the first cold visit at 32 seconds. The second, with a warm cache, was under two.

Both are real, and quoting either one alone is misleading. So the correct thing to say is either both numbers with the conditions attached, or neither — and to build the argument on weight, which does not move: 11.7 MB stays 11.7 MB regardless of whose connection measures it.

This matters more than it sounds when you're telling someone else about their site. Load time is a property of the path between two machines; you measured your own network, not their customer's. Weight is a property of the page itself. One of those you own, the other you're borrowing.

Why this is worth an hour of anyone's time

The site I measured belongs to someone about to buy TikTok and Instagram ads. That traffic is phones on cellular with no patience, and every ad dollar was going to buy a visitor who leaves before the page assembles.

Routing two files through the pipeline that was already set up, giving the logo an SVG, and slicing the tall diagram into sections turns 11.7 MB into under a megabyte — without a single change to the design. Nothing moves, nothing is redrawn, nothing needs approval from whoever owns the brand.

That's the shape of the best performance work: not a redesign, not a rewrite, just finding the things that quietly bypassed a system you already built.

I build browser tools where measurement is the job — parametric product configurators and engineering calculators, where the geometry and the costing come from the same parameters so they can't quietly disagree. Work at smirnov-artur.github.io/webgl, and I'm on Telegram at @smirnovarturr or at paladei702@gmail.com.

If you run the URL check above and find something at the top of the list without a transform in it, I'd be curious what it was. My money is on a logo.

Your page weight is not a number, it's a range: 14 MB one visit, 55 MB the next

Artur Smirnov — Fri, 07 Aug 2026 22:32:20 +0000

I measure other people's pages and write to the owners about what I find, so I care a lot about which of my numbers are safe to quote. My working rule for a long time was:

Load time is a range — it depends on the network. Page weight is stable. Build the argument on weight.

That rule is mostly right, and last week it was wrong in a way I want to write down, because the failure is more interesting than the rule.

Same page, two visits, ten minutes apart

	visit 1	visit 2
total transferred	14,486 KB	55,245 KB
requests	533	638
first-party only	6,499 KB	4,388 KB
time to ready	25.3 s	11.5 s

Nearly four times the weight — and it got faster.

Both numbers are real. Nothing was cached differently on purpose, nothing changed on their server. If I had measured once and written a message, I'd have quoted either 14 MB or 55 MB with equal confidence, and been equally wrong either way.

What was actually happening

An Instagram feed widget in the footer. On the second visit it pulled eight or more videos, 2.3–4.0 MB each, from cdninstagram.com.

How many it manages to fetch depends on how quickly the run reaches the footer and how long it lingers — which is a property of my measurement, not of their page. And the inversion makes sense once you see it: on the faster visit the page became ready sooner, so the footer widget got more time to keep pulling videos before I stopped counting. Speed caused the weight.

Note the third row, too. Their own first-party bytes moved from 6,499 KB to 4,388 KB — a third of a swing, from a source I haven't fully explained. Even the "stable" half of the measurement is only stable-ish.

So the amended rule:

Measure weight twice. If the second run differs by more than about 1.5×, stop measuring the page and go find the third-party widget. Then write about the widget, not about "page weight."

And: never fold third-party video into "the weight of their site." Those bytes are real and worth telling someone about, but they belong to an embed, and putting them in a single total lets one wrong assumption discredit every other number in the message.

The other blind spot: the heaviest file is often not yours

A related case, from a different kind of site — a product that audits pages for SEO and speed. I ran its own home page through the same lens.

The heaviest single file was Google Tag Manager: 169,522 bytes over the wire, 498,110 decompressed. For comparison, on the same page:

their own JS bundle: 116,026 bytes over the wire
their CSS: 81,318 over the wire

The analytics tag is bigger than the application. On a page-speed product.

I don't think anyone was careless. GTM is pasted in once, near the beginning, by whoever set up analytics, and it never appears in a bundle report again — it isn't in your package.json, your bundler never sees it, and your build output never mentions it. It is invisible to exactly the tools you'd use to look for it, including, in that case, the site's own product.

Both stories are the same story: the things that distort a page most are the things outside the boundary your tooling draws. A bundler measures your bundle. A framework's image pipeline measures the images you handed it. An embed measures nothing at all and answers to no one.

What I actually do now

Two cold runs, always. One run is an anecdote.
Split first-party from third-party in the report, never a single grand total. The split is usually the finding.
If the two runs disagree by more than 1.5×, don't quote a weight at all — name the widget and quote its files.
Sort by transfer size and read the domains, not just the file names. If the top entry isn't served from the site's own domain, that's the headline.
Quote decompressed size next to over-the-wire size for scripts. 169 KB sounds survivable; 498 KB of JavaScript to parse on the main thread is a different sentence about the same file.

None of this is sophisticated. It is just the difference between a number you can defend and a number that collapses the first time the recipient reloads their own page and sees something else.

Why bother

Because an unsolicited measurement is worth exactly as much as its credibility. Send someone "your site is 55 MB", have them check and see 14, and you have not made a small error — you have converted yourself into spam, and every accurate thing you also said goes in the bin with it.

The two-run rule costs one extra page load. It is the cheapest insurance I know of.

I build browser tools where this kind of measurement is the job — parametric product configurators and engineering calculators, where the geometry and the costing come from the same parameters so they can't quietly disagree. Work at smirnov-artur.github.io/webgl, and I'm on Telegram at @smirnovarturr or at paladei702@gmail.com.

If you have a page where two cold runs disagree by more than 1.5×, I'd genuinely like to see it. My guess is there's a video embed in your footer.

Your dropdown menu is 7 MB, and it ships on every page you have

Artur Smirnov — Fri, 07 Aug 2026 22:31:47 +0000

A product page on a jewellery store weighs 8,293 KB. That is bad but unremarkable — plenty of stores are heavy, and the usual explanation is "it's a product page, it has photos."

Then I measured a second page on the same store, and the diagnosis changed completely.

7,011 KB of that product page is 27 theme images. Twenty-five of them are photographs in the dropdown navigation menu. And the same 7 MB is on the home page.

Identical. Not similar — the same set of files, the same bytes, on a page that has nothing to do with the product.

Why the second page is the whole finding

One page measurement can only tell you a page is heavy. It cannot tell you whose fault it is, and that distinction is the difference between a useful message and an annoying one.

Three explanations fit a single heavy page equally well:

this particular page has a lot on it,
the platform or theme is heavy by default,
something shared is riding along on every page.

Measure a second, unrelated page on the same site and the three separate instantly. Whatever is identical between two unrelated pages is shared furniture. Whatever differs is the page.

Here the 7 MB was identical. So it isn't the product page, and it isn't a general platform tax either — it's a menu. Every visitor downloads twenty-five navigation photographs to look at a checkout page, a policy page, a 404.

That reframing is what makes it fixable. "Your product page is 8 MB" invites a shrug. "Your dropdown menu is 7 MB and it ships on every page" is a specific object with an owner.

The mechanism, and why the browser can't save you

Three properties, and it takes all three:

The files are around 2400 px wide, sitting in slots of roughly 300 px.
They carry loading="eager", so they're fetched immediately rather than when the menu opens.
None of them has a srcset.

That last one is the trap. A modern browser is perfectly willing to fetch a smaller variant — but only if you offer one. With no srcset, there is no smaller variant in existence, and the browser is obliged to take the 2400 px file to paint 300 px of it. This is not the browser being conservative. It has nothing else to choose from.

The same pattern, on a different store: 25 images larger than their slots, 5,480 KB total, and srcset on none of the 25. The banner is 3609×5414 — 19.5 megapixels, 1,432 KB — in a 340×460 slot. Five circular category thumbnails are 2380×2380, 210–291 KB each, in 74×74 slots. That's 32× wider than needed, per circle, for decoration.

Nobody chose any of this. Theme images get uploaded once at whatever size the source file happened to be, through an admin panel that accepts them without comment.

Do this on your own store, it takes two minutes

Open your home page, DevTools → Network → Img, disable cache, reload. Note the total.
Open a product page, or any page as unlike the home page as you can find. Note the total.
Subtract. The overlap is what every visitor pays on every page.

Then, for anything big in the overlap, check two things in the Elements panel: the natural size against the rendered size, and whether the tag has a srcset at all. Overshoot plus no srcset is a file that literally cannot be delivered smaller.

Sort the overlap by size and fix downward. On both stores above, the top five files were most of the problem.

What I threw away, because it matters

I ran a detector across a batch of these stores, and roughly a third of what it flagged was wrong. Since the whole point is to tell owners true things, here is what fooled it:

"Six buttons have run off the right edge." It was a carousel. Off-screen slides are how carousels work.
"A row of products is faded out at opacity: 0.01." That was a scroll-triggered reveal, caught mid-animation because my script scrolled faster than a human ever would.
"This product card has no price." One store had 209 price elements on the page. My regex simply didn't recognise the Indian digit-grouping format.
"Overflow of 175 px at 390 px wide." At 320 px the overflow was zero — which is impossible for a genuine layout break, since narrower is always worse. The culprit was a hidden cart panel parked off-screen.

The rule I now use: a finding that gets better as the viewport gets narrower is not a layout break, and a signal from code is never the same thing as a working feature. Reproduce twice, and look at a screenshot before you believe any of it.

The general version

Most "your site is slow" advice fails because it can't assign responsibility. Owners on hosted platforms have heard it all and have a ready and often correct answer: that's just how the platform is.

The two-page subtraction is the cheapest way past that. It costs two page loads, needs no access to their account, and it converts an opinion into an object: this menu, these twenty-five files, this many megabytes, on every page you have.

If you run the subtraction on your own store, I'd like to hear what was in the overlap. So far mine is winning at 7 MB of menu.

Chrome is downloading your 22 MB mp4 while the 3.8 MB webm sits one line below

Artur Smirnov — Fri, 07 Aug 2026 22:19:42 +0000

Here is a <video> tag I found on a live production site. Read it and see if anything looks wrong:

<video autoplay loop muted preload="auto">
  <source src="/videos/bg-loop.mp4"  type="video/mp4">
  <source src="/videos/bg-loop.webm" type="video/webm">
</video>

Nothing looks wrong. That is the shape everyone writes. It is also shipping 22,730,246 bytes to every Chrome visitor when the file on the next line is 3,807,102 bytes of the same clip.

Six times heavier. One line apart.

Why

The rule is one sentence, and it is not "pick the best one":

The browser plays the first <source> whose type it can decode. It never looks at the rest.

Chrome decodes mp4. So Chrome reads line one, says yes, and stops. The webm underneath is never evaluated — not compared, not considered, not even fetched. It exists purely to make the markup look thorough.

The habit comes from a real era: for years webm support was patchy and mp4 was the safe fallback, so mp4-first was correct defensive markup. That era ended. The habit didn't, and nothing in the page complains, because nothing is broken. The video plays. The layout is fine. There is no console error, no failed request, no red anything. The only symptom is the bandwidth bill and the phone that gets warm.

And preload="auto" on that tag means it isn't even deferred — the browser starts pulling all 22 MB immediately, before the visitor has decided to stay.

The fix is to swap two lines.

It travels in packs

I found the same shape on a second, unrelated site the same week, with an extra layer:

<source src="/videos/banner-logo.mov"  type="video/mp4">
<source src="/videos/banner-logo.webm" type="video/webm">

Look at the first line twice. The file is .mov, the declared type is video/mp4, and the server answers with Content-Type: video/quicktime. Three different opinions about one file, in one line.

That site also served two other QuickTime files — 3,374,781 and roughly 1,267 KB — with no alternative source at all. Not mis-ordered; simply the only option, in a container that has no business being a web delivery format.

Two independent sites, one week. This isn't an anecdote about one careless team, it's a default that survives review because it reads as correct.

Check your own in thirty seconds

Don't read your markup — markup is what you meant. Open devtools, Network tab, filter to Media, hard-reload, and read which file the browser actually fetched and how many bytes it took.

Then compare that against what's in the HTML. If the fetched file is not the smallest one you offered, your <source> order is upside down.

How to not overstate this, which matters if you're telling someone else

I audit other people's sites and write to the owners, so a wrong number costs me the entire conversation. Three ways I have watched video-weight claims fall apart under checking — all three are mistakes I had to catch in my own measurements:

Never sum the sources. The browser fetches exactly one. Adding the mp4 and the webm together to produce a scary total describes a download that has never happened to anyone.

preload="metadata" without autoplay means the body is never fetched. You can curl that file and get 30 MB, and the number is real and completely irrelevant — no visitor downloads it until they press play. Before quoting a video's weight, check the tag: it counts if there's autoplay, or preload="auto". Not otherwise. I had ten weight findings once and lost six to this check and its image equivalent.

The image version is srcset. Fetch an <img>'s src with a script and you get the full-size original; the browser, meanwhile, picked a 400px variant. If the tag has srcset, your measured weight is fiction.

What survives all three is the good stuff: a single <source> with autoplay, an image with no srcset, and any JS or CSS file — those have no responsive negotiation at all, which is exactly why findings in code are the most reliable ones you can make.

The general shape

The interesting bugs in a page are rarely errors. An error announces itself; someone eventually fixes it. What persists for years is markup that is syntactically perfect and semantically backwards — a correct list in the wrong order, a correct type attribute on the wrong file, a correct preload hint on something that shouldn't preload.

Nothing in your toolchain flags any of it. A linter sees valid HTML. A build sees valid HTML. Lighthouse will tell you the page is heavy but not that the lighter file was sitting right there, unused, one line below.

The only thing that catches this class of bug is opening the network panel and comparing what you offered with what was taken.

If you check your own and the order was backwards, I'd like to know — I have two cases and I suspect the true rate is embarrassing.

Your best line is in your meta description, and nobody reads it

Artur Smirnov — Fri, 07 Aug 2026 22:16:29 +0000

I audit strangers' websites — I open a page, measure what it ships, and write to the owner about what I found. Somewhere around the fourth one I stopped noticing it as a coincidence:

The single best sentence about the business was in the meta description. Not on the page. Not in the h1. In a tag nobody looks at.

Four sites in a row. Different countries, different industries, different people. Same shape every time.

Why this happens, and it isn't carelessness

The two lines get written at different moments, by different versions of you.

The h1 gets written early, while you are still nervous about being taken seriously. So it comes out sounding like the category: Make Smarter Decisions, Modern Solutions for Modern Teams, Your Partner in X. You are writing for an imagined investor.

The meta description gets written late, usually because a checklist told you the field was empty, usually in one pass, usually five minutes before you stop caring. Nobody is watching. So you just say what the thing is.

That's the whole mechanism. The description is honest because it was written when you'd stopped performing.

The four

A social analytics tool. The h1: Make Smarter Social Media Decisions. Fine, and interchangeable with two hundred other tools. The description named two of its actual metrics — invented vocabulary, specific to that product, the kind of words a user repeats back to you. The words that make the product itself were sitting in the tag.

An AI portrait generator. Every competitor in that market runs a subscription. The description contained four words: pay once, no subscription. That is not a feature, it is the entire reason to choose them over anyone else. It appeared nowhere on the visible page.

An electronics retailer. Their description mentioned a payment arrangement specific to their country — a workplace scheme that lets people buy against payroll. No competitor offered it. It was the one genuinely unfalsifiable difference they had, and it lived in the tag. Meanwhile the browser tab on their home page read "Home".

A children's activity centre — the reverse case, and my favourite. Here the inner pages were sharper than the entrance. A single activity page named the state it operates in. The home page didn't — and the town shares its name with a far more famous town elsewhere. So the page most people land on was the one page that failed to say where on earth it was.

That last one is why I don't think this is a rule about descriptions. It's a rule about where attention goes: the page you rewrite most is the page you overthink most, and the pages you never revisit keep telling the truth.

The check, and it takes thirty seconds

Open your own site. View source, or just open devtools:

document.title
document.querySelector('h1').innerText
document.querySelector('meta[name="description"]').content

Put the three next to each other and ask one question: which of them would make a stranger understand what you sell?

If the answer is the third one, you already have your headline. You wrote it. You just filed it somewhere no human being reads.

Then do the same for two or three inner pages, because of the fourth case above. Compare what the deepest page claims about you with what the front door claims. The gap is usually the interesting part.

What this is not

It isn't SEO advice. I'm not telling you to tune description length, or that this moves rankings — I haven't measured that and I'm not going to imply I have. Search engines frequently rewrite the description they display anyway.

The claim is narrower and, I think, more useful: the copy problem you think you have is often not a writing problem but a filing problem. The sentence exists. It's in the repository. It's just in the wrong field.

One more thing worth checking while you're in there, since it costs nothing: how many h1 elements the page actually has. On one of these four the answer was nine. That is not a ranking catastrophe, but it does mean the page has no single most important statement — which, if you've read this far, is exactly the problem we started with.

I build browser tools where the same discipline applies to numbers instead of sentences — parametric product configurators and engineering calculators, where the geometry and the costing are computed from the same parameters so they can't quietly disagree. Work at smirnov-artur.github.io/webgl, and I'm on Telegram at @smirnovarturr or at paladei702@gmail.com.

If you run the three-line check on your own site, I'd like to hear whether the description won. My guess is it wins more often than anyone expects, and I'd like a bigger sample than four.

Why your Wix site feels slow: 4.9 MB of HTML before a single image, and which half you can actually fix

Artur Smirnov — Fri, 07 Aug 2026 22:07:06 +0000

A store owner posted that his Wix site took about six seconds before it responded to anything. He had already done the obvious: converted images to webp, shrunk them to size. It changed nothing. His question was the honest version of a question a lot of people have:

"Once you have already made those changes, and the site is still slow — is there anything else we can do? Or just suffer?"

Three days, no replies. And the replies he would eventually get were predictable: compress your images. Which, in his case, was both wrong and slightly insulting, because he'd done it.

The interesting thing is that this question is answerable — precisely, with a number — and almost nobody answers it, because doing so requires an experiment rather than an opinion.

First: the images really were fine

Before looking for a culprit I checked the thing he said he'd already fixed, because the worst outcome here is telling someone to keep digging in a hole that's finished.

Of 108 media references on the home page, images were being requested at 147×147, 160×160 and 162×162 pixels, q_80, in webp — exactly the size of the slots they sit in, with no headroom. There was not one oversized image on the page. His image work was done and continuing it would have been a waste of his weekend.

(One exception: the og:image was requested at 2500×2500. That is a social-preview asset, not something a visitor waits on.)

So the images were a dead end, which meant the weight was somewhere people don't usually look.

The HTML document is 4.9 MB

Not the page. The document — before a single image, font, or external script.

Over the wire it arrives compressed at 1,230 KB. Decompressed, the thing the browser has to parse is 4,888 KB.

I ran it cold three times, bypassing cache: 1,260,005 / 1,259,977 / 1,259,993 bytes. A spread of 28 bytes across three runs. That is not a measurement artefact; that number is real and stable, and you can build an argument on it.

What is inside those 4,888 KB:

part	size	share
inline `<script>`	1,579 KB	32.3%
inline `<style>` — 88 separate blocks	1,291 KB	26.4%
the actual markup	2,017 KB	41.3%

And inside the scripts, two JSON blobs that the browser must parse on the main thread before the page becomes interactive:

wix-warmup-data — 1,193 KB
wix-viewer-model — 238 KB

Breaking down the first one by key:

key	size	what it is
`platform.ssrPropsUpdates`	939.7 KB	serialized props for every element on the page
`appsWarmupData.dataBinding`	197.3 KB	CMS collections bound to this page
`platform.ssrStyleUpdates`	50.5 KB
`pages`	15.4 KB

Nearly a megabyte of JSON describing the props of every component, shipped inline in the document, parsed synchronously before anything responds. That is where the six seconds went — not into his images.

The part that makes this usable: the control

Here is where most performance write-ups stop, and where they stay useless. Because the obvious response to everything above is:

"Fine — but that's the platform. I didn't write any of that. What am I supposed to do, rebuild the site?"

That response is reasonable and it deserves an actual answer, not a shrug. So I measured two more pages on the same platform, in the same account, on the same day. Same builder, same infrastructure, same everything — the only variable is how much is on the page.

page	document	warm-up blob	`ssrPropsUpdates`	`<style>` blocks
home	4,888 KB	1,193 KB	940 KB	88
a gift-card page	2,642 KB	5.5 KB	0	31
a near-empty page	1,855 KB	40.7 KB	0	36

Two conclusions, and they point at different people:

1. About 1.9 MB is an irreducible platform tax. His own nearly-empty page — a page with essentially nothing on it — still ships 1,855 KB. He was right, and it's proven by his own site rather than by my opinion. No optimisation he performs will remove that floor.

2. The home page adds roughly 3.0 MB on top of the floor, and that part is its own construction. The 940 KB ssrPropsUpdates block exists only on the home page — it is literally 0 KB on both of the others. It isn't emitted by the platform as a constant; it's generated in proportion to the number of components on that particular page.

So the answer to "or just suffer?" is both, in a ratio: about 40% of the weight is a floor he cannot touch, and about 60% is his page's own composition, which he can. That is a completely different conversation from "your platform is bloated" and from "compress your images", and neither of the usual answers gets anywhere near it.

The general form

The control experiment is the whole technique, and it generalises past no-code builders:

To separate the platform's cost from yours, hold the platform constant and vary only your content.

Same account, same stack, same day. A near-empty page in the same system is the floor. Whatever your real page ships above that floor, you built — regardless of who wrote the code that emits it.

This works for a CMS theme, a component library, an analytics stack, a framework's hydration payload. Every one of those arguments usually dead-ends in "well, that's just what X does". The empty-page control turns it into a number, and a number is something an owner can make a decision about.

Two things I measured and then threw away

This matters more than the findings, because a wrong claim about someone's site costs you the entire conversation.

The search box. His actual complaint was that site search felt slow. I tried hitting the platform's search endpoint directly and got 400 Bad Request three times in a row. It was tempting to write "your search endpoint is returning 400" — it would have looked like a sharp catch. It would also have been a lie. Three consecutive 400s from an undocumented endpoint mean I guessed the request format wrong, not that his search is broken. What went back to him instead was: I could not measure this from outside, and here is how you check it yourself in a minute.

Load time. The document arrived in 4,754 / 4,896 / 5,106 / 5,114 ms. Beautifully consistent numbers — and useless as an argument, because that is my connection to his server, not what his customer experiences on the other side of an ocean. Weight is a property of the page. Time is a property of the path between two machines. Only one of those belongs in a claim about someone else's site.

There were also 21 platform apps installed. I mentioned it as a direction and gave no number, because I didn't measure each one's contribution and I'm not going to invent it.

Why bother being this careful

Because the whole value of an unsolicited measurement is that it's true. The moment one number in it is wrong, the recipient is right to discard all of them — and they will, along with the person who sent it.

The discipline is cheap: reproduce cold three times, run a control that holds the platform constant, and delete anything you cannot separate from your own network, your own cache, or your own guess at an API. What survives is short, and it's worth something.

I build browser tools where this kind of thing is the job — parametric product configurators and engineering calculators, where the geometry and the costing are computed from the same parameters so they can't disagree. Work at smirnov-artur.github.io/webgl, reachable on Telegram at @smirnovarturr or at paladei702@gmail.com.

If you run this control on your own stack, I'd be curious what your floor turns out to be. Mine keeps coming in higher than anyone expects.

Four false positives in one evening: telling a broken web app from a broken measurement

Artur Smirnov — Fri, 07 Aug 2026 21:51:14 +0000

I spent an evening opening other companies' product configurators — 3D and parametric tools on manufacturers' sites — looking for things that were genuinely broken. Twenty-seven of them.

The findings were real. But the part worth writing down is that four separate times in one evening, my tooling told me an application was broken when it was fine. Every one of those four passed automated checks that looked rigorous. What caught them was a screenshot.

If you write scripts that judge pages you don't own — uptime checks, competitor teardowns, scraping health, QA of an embedded widget — you will hit these. Here is the full list of signals that lied to me, and the one control that never has.

The four false positives

All four produced the same symptom: no <canvas> on the page, and an almost empty innerText. That looks damning when the page is literally titled "Configurator". It is also what three completely healthy situations look like:

The tool starts on a click. An orange button launches it. My script measured an unopened door and reported an empty room. Four automated passes — raw HTTP with a browser UA, my own browser, two runs from a clean profile, a control on the same domain — all four confidently examined a page that hadn't started yet.
The entire UI lives inside the canvas. One hall configurator draws its menus, its undo/redo and its PDF export in WebGL. Empty DOM text is correct there, not a defect.
The tool is behind a login. I was measuring a sign-in page. Fifty-four characters of text and one button reading "Anmelden".
The page is a landing page about the configurator, not the configurator.

No network-level or DOM-level check distinguishes these from an actual failure. A screenshot distinguishes all four instantly.

So the first rule I now follow, before any measurement at all:

Take the screenshot first. Look at the picture. What you cannot see in the image, you do not measure.

It costs one second and it is the highest-yield step in the whole process. The corollary is that automation answers "is it reachable", never "does it work." When you catch yourself designing a fifth automated pass, what you actually need is one human opening the page and clicking the obvious thing.

Signals that lied, and why

"No canvas" and "empty innerText". The two least reliable signals I use. Demoted permanently: they are now a reason to look at a screenshot, never a finding.

Reading pixels off someone else's WebGL canvas. I nearly built a proof-of-emptiness on this. Copy the canvas into a 2D context, count non-transparent pixels, get zero — on a perfectly live scene. WebGL clears the drawing buffer after compositing unless preserveDrawingBuffer is set. The zero is an artefact of the spec, not evidence about their app.

ERR_ABORTED, even on the company's own domain. One site showed eight failed requests, its own domain, its own scripts. That passed my "only count first-party failures" filter and looked like the real thing. Re-run waiting for networkidle instead of domcontentloaded: sixty-five responses, all 200, zero errors. My own measurement was cutting the page off mid-load. A failure is a 4xx or 5xx status in a response — not a request that got aborted, and you must wait for the network to settle before you believe anything.

A third-party widget failing. Their chat widget threw net::ERR_FAILED plus CORS. Real, reproducible — and it did exactly the same thing on two unrelated sites, in different countries, on different accounts. That is my environment being filtered, not their code. Same for analytics, tag managers and captcha endpoints: when those fail, you have measured your own ad blocker.

transferSize from a persistent browser profile. Returns zero or garbage, because the response came from cache. Weight gets measured from a clean profile or not at all.

403 with no User-Agent. One door configurator returned 403 and 118 bytes to a headless request, and 200 to the same request with a real browser UA. The site was healthy; my headless client was being filtered, and I almost filed it as broken. Without a genuine User-Agent, every 403, timeout and empty body you collect is worthless. Likewise 403/503 from a WAF: that is a block against a datacentre IP, not a defect.

A 300×150 canvas. That is the HTML default and proves nothing.

Single beautiful observations that didn't reproduce. I saw requests to a URL containing a literal undefined/undefined. Gorgeous finding. It did not appear on either re-run, so it does not exist.

The control that always works

Everything above is one question wearing different costumes: am I being filtered?

For a while I answered it with external text proxies — fetch the same URL through a service on another network, compare. Then all four services I used went down at once: 403, 522, 521, 429. Which taught me the more useful lesson — I ran a known-good file through the same proxies and got the same 521 back. The proxies were down, not the sites. An error from your verification tool is not evidence about your target.

The replacement is better than what it replaced, needs nothing external, and works every time:

Fetch the neighbouring object, from your own network, in the same request.

A 404 on a file? Request the file next to it in the same directory.
An empty page? Request a different page on the same domain.
A dead domain? Request their homepage.

The logic is airtight. Geo-filters, datacentre blocks and User-Agent screening kill the whole connection. None of them can selectively 404 one filename and serve its neighbour.

A worked example. A decor texture returned 404 at 564 bytes. Its neighbour in the same directory, same User-Agent, same client, same second, returned 200 at 1877 bytes. No filtering mechanism in existence produces that. The file is genuinely missing. Another: a site whose configurator subdomain returned 200 with a 31-byte body — the entire payload being an HTML comment reading  — while its main domain served me full pages normally.

For JavaScript errors specifically, note that a text proxy is useless in principle: it doesn't execute scripts, so it can only confirm HTML delivery. There, reproduction from a clean profile plus a control page on the same domain is what you have — or a human on a different connection, whose home ISP is more convincing than any proxy.

What survives all of it

These findings don't depend on clicks, environments or filters:

A 4xx/5xx status from the company's own domain, with a neighbouring object returning 200.
A response body too small to contain anything — 31 bytes has nothing to run.
No TCP connection at all. My strongest confirmed case: curl returns code 000 and zero bytes, my browser times out at 45 seconds, an external network reports ERR_ADDRESS_UNREACHABLE, and a direct TCP connection to their IP on ports 80 and 443 refuses. DNS resolves; there is no machine behind it. Meanwhile their main site is healthy and links that tool from the menu three times.
A library version read out of their own served file.

The checklist

Screenshot first. If you can't see it, stop.
Launch the interactive thing. Click the button. An unopened tool measures as a broken one.
Real User-Agent on every request, always.
Wait for networkidle. Count response statuses, not aborted requests.
Reproduce twice, from a clean profile.
Run the neighbour control. No control, no finding.
First-party domain only. Their scripts, their responses.
Anything that fails a step gets dropped without regret.

One operational note that cost me an evening: give every site its own tab. A single timeout leaves a navigation hanging, and every subsequent goto fails with "interrupted by another navigation". Eight sites I had recorded as dead turned out to be one stuck window.

The reason this discipline is worth the trouble: I use these findings to start conversations with the companies that own the tools. A message that says "your configurator throws thirteen unhandled exceptions on every load, here they are, I checked twice and from a second network" is worth a great deal — and a message that says it about a tool which is actually fine closes that door permanently and poisons every other message you send. The rigour isn't perfectionism. It's the thing that makes the finding usable at all.

I build the kind of tool I was auditing — parametric product configurators and engineering calculators for the browser, where the geometry and the costing are computed from the same parameters so they can't drift apart. Work at smirnov-artur.github.io/webgl, and I'm reachable on Telegram at @smirnovarturr or at paladei702@gmail.com.

If you audit pages you don't own, I'd like to hear which signal fooled you — I suspect the list above is incomplete in ways I can't see from where I'm standing.

Zero bytes of geometry: a metal lattice sphere-traced in a 14.9 KB page

Artur Smirnov — Fri, 07 Aug 2026 21:04:59 +0000

There is no model file on this page. No mesh, no texture, no .glb, no HDR environment map. The object you orbit is a mathematical function evaluated per pixel, and the whole thing — renderer, distance field, post chain — arrives in a 14.9 KB HTML document.

Live demo: https://smirnov-artur.github.io/webgl/lattice/

Open the network panel before you judge that claim. Four requests, 64.5 KB over the wire, and 49 KB of that is two web fonts — the typography outweighs the renderer three to one. The counter in the corner of the page reads GEOMETRY 0 B because it is telling the truth.

What the object actually is

A graded gyroid: a triply-periodic minimal surface, the structure used in additive manufacturing when you want stiffness or heat transfer without mass. The entire solid is five lines of signed distance field:

float g = dot(sin(p * k), cos(p.yzx * k));   // gyroid, TPMS
float d = (abs(g) - wall) / (k * 1.7);       // shell around the surface
d = max(d, length(p) - 1.0);                 // outer skin
d = max(d, 0.30 - length(p));                // inner cavity
d = max(d, min(dot(p, A), dot(p, B)));       // section wedge subtracted

k is a function of radius, not a constant. That is the "graded" part: the cell gets finer toward the core, the way a real printed lattice is graded where the loads concentrate.

The section cut is the part people ask about. It is two half-spaces subtracted from the field — which is why the cut face shows a genuine cross-section through the lattice instead of a hollow capped shell. Drag the SECTION slider and you are re-cutting a solid, not playing back an animation of a pre-made mesh. There is no mesh to make.

The parts that took the longest

An analytic entry test. Every ray gets a ray/bounding-sphere intersection first. Pixels that miss the specimen cost two dot products instead of a full march. On a shot where the object covers a third of the frame, that is most of your pixels bought for nothing.

Silhouette coverage out of failure. Grazing rays run out of march steps before they converge — that is what makes ray-marched edges crunchy and full of holes. Instead of throwing those rays away, I keep their closest approach to the surface and reuse it as partial coverage. The rim fills in and the edge antialiases, and it costs nothing extra because the number was already computed and discarded.

No HDR file. The environment is a two-stop sky plus a warm softbox and a cool rim, each a broad cosine lobe with a tight core. Roughness widens the lobe instead of sampling a blurrier mip, so the whole image-based lighting is about a dozen instructions and zero bytes downloaded. This is the single biggest reason the page weighs what it does: an HDR environment is usually the heaviest asset in a scene like this, and here it does not exist.

Metal BRDF with roughness-aware Fresnel, per-channel dispersion (the reflected ray is fanned around the view tangent, wider at grazing angles), and heat-tempering colours — straw into blue — graded by depth into the core. SDF soft shadows and AO, skipped entirely on faces turned away from the key light. A volumetric core accumulated in front of the first hit, so the glow only leaks out through open cells and the section cut.

The post chain is hand-written too: bright-pass with a soft knee, two levels of separable Gaussian, then a composite doing ACES (Hill fit), edge-weighted chromatic aberration, unsharp, vignette, grain and dither, converting to linear Display-P3 where the display supports it.

The performance trick worth stealing

Quality here is expressed as ray-march pixels per CSS pixel, not as a fixed resolution. A 1× laptop should not be undersampled and a 3× phone should not be melted, and those are the same setting expressed correctly.

The adaptive scaler measures frame time against an estimate of the refresh period rather than against a fixed 16.7 ms. This matters more than it sounds. If you compare against 16.7 ms on a vsynced display, every frame looks marginally "slow", the scaler ratchets down, and it can never climb back — you end up at half resolution on hardware that had headroom the whole time.

Context is requested with alpha:false, antialias:false, depth:false, stencil:false, powerPreference:high-performance, and a first attempt at failIfMajorPerformanceCaveat:true. A null answer there means the browser would fall back to a software rasteriser — so the low tier gets selected up front instead of after the user watches five seconds of slideshow.

Measured, not estimated

Desktop, RTX 3050, hardware ANGLE/D3D11:

	value
FPS	60 (vsync ceiling)
page weight over the wire	64.5 KB across 4 requests
of which, two web fonts	49 KB
the document carrying the entire renderer	14.9 KB
geometry + textures	0 B

The march resolution sits around 0.9× CSS pixels on the laptop and about 0.5× device pixels on a 390×844 phone at DPR 3, adapting continuously.

One honest correction, because I got this wrong in my own notes first: an earlier version said 95 KB. That was the uncompressed total. Over the wire, gzipped, it is 64.5 KB. Both numbers were real measurements — they just measured different things, and I had not said which.

Why build it this way

Because "it's only 14.9 KB" is not the point — it is the receipt. A distance field is a parametric object. The three sliders on that page are not presets, they are terms in the equation, and the solid re-forms around them because there was never a fixed model to violate. That property is the whole reason I use SDFs for engineering work: when the client says "now make the wall thinner", nothing has to be re-exported.

Raw WebGL 2, no library, hand-written GLSL, one HTML file. Drag to orbit — the camera is on a critically damped spring rather than a linear follow, which is a small thing you feel immediately and never consciously notice.

If you build things like this, I would genuinely like to hear how you handle grazing-ray coverage — the closest-approach trick is the best I have found, but I doubt it is the best there is.

I take on WebGL work, mostly real-time product configurators and engineering visualisation. More at smirnov-artur.github.io/webgl, or Telegram @smirnovarturr.