DEV Community: Artur Smirnov

A lattice with no mesh: sphere-tracing a signed distance field in raw WebGL2

Artur Smirnov — Tue, 11 Aug 2026 14:49:56 +0000

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

There's no 3D model behind this page — no mesh, no textures, no .glb file. The lattice is a graded gyroid, a triply-periodic minimal surface, and it exists purely as a signed distance function (SDF): a formula that, given any point in space, returns how far that point is from the surface. The whole scene is one WebGL2 fragment shader that "sphere-traces" that function — walks a ray forward by the returned distance, over and over, until it's close enough to the surface to count as a hit. Raw WebGL2, no three.js, no library at all: one inline <script>, 31.8 KB of source.

The geometry is a lie, in the best way

The only thing actually submitted to the GPU is a single full-screen triangle, generated in the vertex shader straight from gl_VertexID — no vertex buffer, no attributes, nothing to upload. The page's own on-screen HUD confirms it: geometry: 0 B. Every bit of surface you see on the lattice sphere is computed per-pixel in the fragment shader, not stored anywhere.

I wrapped gl.drawArrays to count how many times it's actually called per frame: 7 — one for the SDF scene pass, and six for the post-processing chain (a bright-pass, a two-level separable Gaussian blur, then a composite that does ACES tonemapping, per-channel chromatic aberration, vignette, and film grain). The HUD's own draw / passes readouts agree.

Making it look like metal, not plastic

The raymarch itself wasn't the hard part — the hard part was getting the surface to read as tempered steel instead of gray plastic. Two tricks did most of the work:

Dispersion per color channel. Instead of one refraction path, the shader traces three slightly offset paths through the same field, one per channel — that's what gives the edges the faint color fringe you'd expect from real glass or stressed metal.
Radial grading, one smoothstep. The lattice cell size shrinks toward the core and opens up at the skin — dense in the middle, sparse at the edge — driven by a single smoothstep on the cell frequency term. No second field, no extra noise layer.

Numbers, measured on this page, not claimed

I don't trust "buttery smooth" as a spec, so here's what I actually measured on this machine (RTX 3050, 1250×1276 canvas, DPR 1) — the page's own live HUD agrees with all of it:

60 fps steady, vsync-capped — confirmed two ways: the page's own EMA-smoothed frame-time readout, and an independent requestAnimationFrame counter over a 6-second steady-state window
~65 KB total transferred for the entire page — 15 KB gzip for HTML+CSS+JS+shaders combined, ~50 KB for two subsetted variable fonts, zero images, zero model files
3 quality tiers (56 / 80 / 88 raymarch steps for low/mid/high), chosen automatically: first a probe for a software-rasterizer fallback (drops straight to low), then touch input + screen size (drops to mid)

Where it breaks

Antialiasing is off on purpose — the shader leans on device-pixel-ratio and the post pass instead of MSAA, so if you force DPR down, the lattice edges alias visibly. If WebGL2 isn't available at all, there's a static fallback panel instead of the canvas; I've only verified that path on evergreen browsers, not on anything old enough to actually need it. And running a raymarcher flat-out at 60fps draws real, continuous GPU power — I haven't added a frame cap or measured battery impact on a laptop.

Happy to go deeper into the distance field, the tiering logic, or the dispersion shader if anyone's curious.

'Thanks for contacting us' is not proof: four ways a website message disappears

Artur Smirnov — Sat, 08 Aug 2026 07:02:21 +0000

I audit websites from the outside and then write to whoever owns them, which means I spend a lot of
time in other people's contact channels — forms, chat widgets, published addresses. Over one week
that came to seventy-odd contact pages and around a hundred messages.

The thing I did not expect to learn: whether a message arrives is a completely separate question
from whether the form works. Four failure modes, all measured, all of them holes that a site owner
cannot see from the inside, because from the inside everything looks fine.

1. The careers mailbox turns customers into applicants

Four of my letters went to addresses of the form jobs@, careers@, bewerbung@, karriere@.

All four came back as job applications. Not one exception.

"Thanks so much for your interest in joining our team… unable to reply"

Empfangsbestätigung Ihrer Bewerbung — confirmation of receipt of your application

The second one is the one to sit with. That message was about the company's broken product
configurator on their own website. The reply was a receipt confirming my application for a job.

The mechanism is an applicant tracking system. careers@ is not a mailbox with a person behind it,
it is an intake pipe: everything that lands there becomes a candidate record with a status field, and
nobody in sales or engineering will ever open it. Two of the four were the same well-known hiring
platform.

Why this hits site owners specifically: the careers address is the easiest address on the whole
site to find. It is on the jobs page, in the footer, in the structured data, and it is indexed. It is
frequently the only address a company publishes as plain text, because the sales route is a form.
So an outsider with something useful to tell you — a customer, a supplier, a stranger who found a bug
in your checkout — reaches for the address that is visible, and it is the one address in the company
where their message provably will not be read.

Worth ten minutes of your time:

Is there a non-careers address published in plain text anywhere on your site? If the only reachable string is careers@, that is your business channel now, whether you meant it or not.
Does your ATS auto-reply to everything, including messages that are obviously not applications?
Does anyone read the "unqualified" bucket in the ATS? That is where your bug report lives.

2. Captcha markup is not captcha

I nearly discarded most of a channel over this one.

Census of seventy contact pages: markers for hcaptcha or recaptcha present in the HTML of
sixty-five. Visibly rendered captcha widgets: zero.

On some hosted platforms an invisible captcha is mixed into every form by default and switched on
selectively — the markup is a platform default, not a decision anyone made about that shop. Filtering
by "the page contains the string hcaptcha" would have thrown away ninety-three per cent of the
channel, including every shop whose form happily accepted my message and replied with a confirmation.

What actually blocks a form is a rendered widget: a visible h-captcha / g-recaptcha container
or an actual hCaptcha iframe on the page. That costs one request to check, against a string match
that is worse than useless because it is confidently wrong.

Two related things, both measured:

Cloudflare Turnstile in managed mode leaves cf-turnstile-response empty until submit. I watched a token field stay blank for sixty seconds and marked the form unreachable. It was not: the token is fetched at submission time. On another site I had written off as "Turnstile, no way through", the challenge solved itself in a normal browser tab — an 837-character token appeared a few seconds after load, the form went, and the page said "Thank you — Your form has been submitted successfully". Waiting for the token before clicking is pointless. Check the result, not the field.
Invisible reCAPTCHA (data-size="invisible") and the Enterprise variant are not barriers by design — no human step exists in the mechanism. A visible v2 checkbox is a different matter.

For an owner this cuts both ways. If you added a captcha because of spam, verify it renders at
all — you may be protected by a string in your HTML and nothing else. And if it does render, know
what it costs: a visible challenge on a B2B contact form is a toll charged to every genuine inquiry,
in exchange for stopping bots that mostly are not stopped by it.

3. Your success indicator is probably lying

I need to know whether a message went, so I have become uncomfortably well informed about how forms
signal success. Three real cases:

Fields cleared, URL changed, no message sent that I could prove. The submit went through, the connection dropped on the same action, everything looked like a successful navigation. I logged it as unconfirmed and did not resend, because a duplicate is worse than a miss.
Fields stayed filled, no error, no success. Two attempts, checkValidity() true, form intact. The click had been dispatched to a background renderer — the button was "pressed" in a tab that was not in front. No error anywhere.
Four forms redirected to ?contact_posted=true and showed "Your e-mail has been sent." I checked, and without that URL parameter the confirmation string does not exist on the page at all. The confirmation is a consequence of the parameter, not evidence of delivery on its own.

The only thing I now accept as proof is confirmation text rendered on the page after submission.
Cleared fields lie. A URL change lies. A missing error message proves nothing whatsoever: the absence
of a failure signal is not the presence of a success.

For owners: go and submit your own contact form and watch what the page tells you. If the answer
is "it scrolls to the top and the fields are empty", a meaningful share of your visitors will
conclude it failed. They will submit again, or they will leave and not come back. Say the word
"sent", in a sentence, where the fields used to be.

4. Delivered is not delivered

Bounces come in two shapes and one of them is easy to miss entirely.

The ordinary one is mailer-daemon. The other arrives from postmaster@ on the recipient's own
domain, and it means the published address forwards to somebody's personal mailbox and the
forwarding broke. A search for mailer-daemon alone does not see it. This one does:

newer_than:7d (from:mailer-daemon OR from:postmaster OR subject:undeliverable
  OR subject:undelivered OR "delivery has failed")

Three more findings from the same pile:

554 5.7.1 Relay access denied from an address published on the company's own contact page. That mailbox does not accept external mail at all. Nobody there knows.
Business auto-replies land in Promotions. A manufacturer's "Your request to us" receipt, with a printout of the fields I had filled in, was sitting in the Promotions tab and never in the inbox. I had recorded that delivery as unproven for a day. If your own order confirmations or inquiry receipts go out with marketing headers, this is happening to your customers too — and they will not go looking.
Some hosted form products reject free mail domains. @gmail.com was rejected outright by two different vendors' contact forms. As an anti-spam measure it is understandable. As a filter on your inbound it is brutal: a large share of small-business owners, sole traders and individual customers have no other address.

The ten-minute check on your own site

Not from your office network, and not from the account that owns the site:

Open your contact page on a phone, on mobile data, in a private window.
Submit a real message using a Gmail address. Watch what the page says afterwards, word for word.
See where it lands — inbox, Promotions, spam — and how long it takes.
Follow every publicly visible address on your site and check what is on the other end: a mailbox someone opens, or an intake system.
Send one message to each of those addresses from outside your own domain and see which ones come back.

Every one of the four failures above is invisible from inside the company and every one of them
costs inbound. The first three cost you the message. The fourth costs you the message and tells the
sender it went.

If you run the ten-minute check and something in it surprises you, I would be glad to hear which
one — I am collecting failure modes and I doubt these four are the last of them.

I do outside audits of sites and storefronts, and the repairs that follow.
Portfolio: smirnov-artur.github.io/webgl ·
Telegram @smirnovarturr · paladei702@gmail.com.

The image loads and stays invisible: the opacity: 0 is on the wrapper, not the image

Artur Smirnov — Sat, 08 Aug 2026 06:57:03 +0000

Someone posted this on a support forum and got no answers for a week:

The featured image is displayed correctly on desktop browsers and iPad (Chrome and Safari), but
the featured image is missing on iPhone. […] HTML output contains the <figure> and <img>
element […] No JavaScript errors in the browser console. CSS shows normal values (display: block,
correct height, opacity 1).

Every sentence of that is true, carefully checked, and points away from the cause.

The image is in the markup. The image is downloaded. getComputedStyle on the <img> returns
display: block, a correct height, opacity: 1. Nothing is wrong with the image, and he had spent
a week establishing that with increasing precision.

It took me one look at the page source to find it, and only because I was looking one level up.

What was actually there

The theme wraps the featured image in a <figure> and puts an animation class on it:

<figure class="ext-animate--on wp-block-post-featured-image">
  <img src="…">
</figure>

And in the stylesheet, exactly one rule:

.ext-animate--on:not(.ext-animate--off) { opacity: 0; transform: scale(0.8); }

The class is removed by the theme's own JavaScript once the element scrolls into view. That is the
entire fade-in mechanism: start at zero, let a script take the class off, the CSS transition does the
rest.

If that script does not run, or does not reach this element, the wrapper stays at opacity: 0
forever. The image inside it is loaded, laid out, correct in every respect, and invisible — because
you cannot see through a transparent parent no matter how opaque the child is.

His own investigation could not find this, and it is worth being precise about why: he inspected
the image, and the zero was on the figure. Every value he read was genuinely normal. The tooling
told him the truth about the wrong element.

(The device-specific part has a likely explanation in the same file: the theme respects
prefers-reduced-motion. If "Reduce Motion" is on in iOS accessibility settings, the reveal can be
suppressed while the starting state stays put — visible everywhere, invisible on exactly one phone.
That one I flagged as a suspicion rather than a measurement, because I could not reproduce it on his
device.)

The general shape

Anything that hides an element hides its subtree, and none of it shows up on the child:

on an ancestor	the child's own computed style
`opacity: 0`	`opacity: 1` — untouched
`visibility: hidden`	inherited, so this one does show
`height: 0` + `overflow: hidden`	correct height, correct everything
`transform: scale(0)`	no trace
`clip-path: inset(100%)`	no trace
`content-visibility: hidden`	no trace
a `::before` overlay painted on top	nothing at all, in any property

So when an element is loaded, laid out, and not on screen, stop reading its style and walk up:

function whyInvisible(el) {
  const out = [];
  for (let n = el; n && n !== document.documentElement; n = n.parentElement) {
    const s = getComputedStyle(n);
    const r = n.getBoundingClientRect();
    const bad = [];
    if (+s.opacity === 0)            bad.push('opacity:0');
    if (s.visibility === 'hidden')   bad.push('visibility:hidden');
    if (s.display === 'none')        bad.push('display:none');
    if (s.transform.includes('matrix(0') ) bad.push('transform scaled to 0');
    if (s.clipPath !== 'none')       bad.push('clip-path:' + s.clipPath);
    if (r.width === 0 || r.height === 0) bad.push(`box ${r.width}×${r.height}`);
    if (bad.length) out.push([n.tagName.toLowerCase() + '.' + n.className, bad.join(', ')]);
  }
  console.table(out);
}

whyInvisible(document.querySelector('img.your-image'));

Run that, and the answer is a row in a table instead of a week of forum silence.

One more habit worth building, because it costs nothing: when a fade-in is involved, check the
element with JavaScript disabled. Reveal-on-scroll animations written as "start hidden, let a script
un-hide" have a failure mode with no error message — the script that was supposed to fix it simply
never ran, and the page looks like the CSS is broken. If your site does this, the starting state
should be visible and the animation should be an enhancement, not the other way round.

The other half: when the image is fine and your measurement is broken

I audit sites from the outside and write to the owners, which means my detector has to be right
before I put a claim in an email. Three of the ways it lied to me, all on live sites, all inside one
week:

"Eleven broken images." The detector flagged every image where naturalWidth === 0 after
scrolling to the bottom. All eleven were carousel slides that vertical scrolling never wakes — and
their URLs still carried &width=30, which is the theme's placeholder. Nothing was broken. Fix:
never claim a broken image from the DOM; make an actual request for each candidate URL and only
report 4xx/5xx from the server. On another store that same check confirmed eight genuine 404s, so
it removes fiction without removing findings.

"Two hundred and forty-eight broken images, including the logo." Every image on the site lived on
a separate image host, and every single one came back 403 with Cf-Mitigated: challenge and a
three-kilobyte body, while the main domain answered 200. Cloudflare was challenging my address,
and an <img> request cannot solve a challenge, so all of them failed at once.

That one has a heuristic worth memorising, because it identifies the class instantly: if the
company logo is also "broken", it is almost certainly you. A live business notices a missing logo
the same day. A hundred per cent failure rate is a property of your connection, not of their site.
The same goes for 406 — some servers return it for short User-Agent strings and 200 for a full
Chrome one.

"A whole row of products faded to nothing." The screenshot showed it twice, and the computed
style backed it up: opacity: 0.01 on the slider wrapper. Which is the exact bug from the first half
of this article, so I nearly sent it. It was false. The theme reveals blocks with
IntersectionObserver, my script was paging through the document at 320 ms per screen and then
calling scrollIntoView, which restarted the reveal. At 450 ms per screen with a three-second hold,
every block read opacity: 1, on three separate pages.

Note the sting in that: a computed style is usually the thing that settles an argument, and here it
lied, because I photographed an animation mid-flight. The distinguishing test is the distribution.
Some blocks at 1 and some at 0.01 is their code. All of them faded, or none, is your own scrolling.

The rule underneath all four

Every one of these is the same mistake wearing a different costume: I measured the environment and
attributed it to the object.

The check is cheap. Take three of your results at random and look at them by eye. If they all point
at the same thing — the same host, the same wrapper, the same status code — you have found a property
of the page's furniture or of your own connection, not a property of the objects you thought you were
measuring. Real defects do not distribute that evenly. A finding that comes back at a hundred per cent
or at zero per cent is a finding about your instrument.

And before anything goes in front of the person who owns the site: confirm it a second way, and let
the second way be different in kind. Not the same script run twice — a different tool, or a different
angle. Over one week that rule killed roughly two thirds of what my detector produced, and every
single thing that survived it held up.

If you have an element that is loaded and invisible, paste the whyInvisible function above into the
console and point it at the element. It is usually the second or third row.

I do audits like this on real sites, and the repairs that follow.
Portfolio: smirnov-artur.github.io/webgl ·
Telegram @smirnovarturr · paladei702@gmail.com.

Your store weighs 1.7 MB and still takes 18 seconds: the number that matters is 364 requests

Artur Smirnov — Sat, 08 Aug 2026 06:55:02 +0000

Page weight is the number everyone checks, and it is the reason this store has been slow for
months without anyone finding out why.

I measured a Shopify storefront twice, cold cache, an hour apart:

	visit 1	visit 2
`DOMContentLoaded`	1.2 s	2.6 s
`load`	18.7 s	18.1 s
transferred	2 637 KB	1 736 KB
requests	364	343

1.7 MB. By weight this is a healthy page — lighter than most of the stores I look at, and lighter
than plenty of pages that finish in under two seconds. It still spends eighteen seconds finishing.

Why the owner does not see it

Look at the first row. The document is parsed and interactive in one to three seconds. The owner
opens the shop, the header is there, the products are there, they scroll, they click, everything
responds. Nothing about that experience says "eighteen seconds".

The tail is not nothing, though. Until load fires you are still holding connections open, still
running the browser's networking machinery, still competing for bandwidth on a phone that has very
little of it. Images below the fold arrive late. Anything that hangs off window.onload — and on a
store with a stack of apps, quite a lot does — is on the far side of that eighteen seconds. The
third-party pixels the owner is paying for fire when the visitor has already left.

And a visitor on a slow connection is not living in the owner's DOMContentLoaded. Three hundred
sequential round trips on high-latency mobile is not "a bit slower than desktop", it is a different
page.

Why every weight-based check gives it a pass

Because it is not heavy. That is the whole trap.

The advice that comes back from a weight audit — compress your images, ship smaller JavaScript,
lazy-load the hero — has nothing to bite on here. The scripts total 684 KB, which is unremarkable.
There is no 6 MB PNG. There is no 4 MB logo. Every individual thing on the page is defensible, and
there are three hundred and sixty-four of them.

Compare with a store I measured the same week, where the weight was the story: a product page at
8 293 KB across 286 requests, of which 7 011 KB was twenty-seven theme images — and the identical
7 MB showed up on the home page too, because they were photographs inside a dropdown menu that
shipped on every page in the shop. That one is a weight problem, and a weight tool finds it in
thirty seconds.

The 364-request store is the other class. Same symptom for the customer, opposite diagnosis, and
one of the two diagnoses is invisible to the tool most people reach for.

Measure it yourself, in the console, in ten seconds

Open the site in a fresh incognito window with the network panel on and "Disable cache" ticked.
Then paste this:

const nav = performance.getEntriesByType('navigation')[0];
const res = performance.getEntriesByType('resource');

console.log('requests     ', res.length);
console.log('transferred  ', (res.reduce((s, e) => s + e.transferSize, 0) / 1048576).toFixed(2), 'MB');
console.log('DOMContentLoaded', (nav.domContentLoadedEventEnd / 1000).toFixed(1), 's');
console.log('load            ', (nav.loadEventEnd / 1000).toFixed(1), 's');

Two numbers matter and most reports only show you one. If load is many times
domContentLoadedEventEnd, and the transferred total is unremarkable, you are looking at a request
count problem and no amount of image compression will move it.

To see where the requests go:

const by = {};
for (const e of performance.getEntriesByType('resource')) {
  const k = e.initiatorType || 'other';
  by[k] = by[k] || { n: 0, bytes: 0 };
  by[k].n++;
  by[k].bytes += e.transferSize;
}
console.table(by);

Sort by n, not by bytes. The row you are looking for is usually a long list of small files from
a handful of hosts — an app that ships eleven scripts instead of one, an icon set delivered as
individual SVGs, a font family loaded weight by weight, a review widget that fetches every avatar
separately.

Then the second half, which is the actual fix and which nobody can do for you from the outside:
group the third-party hosts.

const hosts = {};
for (const e of performance.getEntriesByType('resource')) {
  const h = new URL(e.name).host;
  hosts[h] = (hosts[h] || 0) + 1;
}
console.table(Object.entries(hosts).sort((a, b) => b[1] - a[1]).slice(0, 15));

Every distinct host is a fresh DNS lookup, TCP handshake and TLS negotiation before a single byte of
content moves. On a desktop with a warm connection that is noise. On a phone on a cell network it is
the majority of your eighteen seconds. If one host in that table is serving you forty files for a
feature you do not use, you have found your afternoon's work.

The check that stops you shipping a wrong number

Two of these, both bought the hard way.

Sum the parts and compare to the whole. I once produced a breakdown where CSS came out at
1 061 567 bytes on a page that transferred 1 323 722 bytes in total — CSS was eighty per cent of a
page full of photographs, which is absurd on its face. The cause: images were being pulled in with
<link rel="preload">, and my grouping used initiatorType, which reports those as link. The same
PNGs were counted once as images and once as stylesheets. If your categories add up to more than the
page, the measurement is wrong in full, not slightly off — go find the item you counted twice.

Measure twice or say nothing. A single timing run is worth close to nothing. From the same batch
of stores: one gave 20.1 s on the first run and 7.7 s on the second. Another gave 13.3 s, then 0.0 s
with load at 629 ms over 409 KB. A third gave 9.6 s, then 0.0 s. Three findings that would have
been three confident, wrong emails.

The store at the top of this article is in the article precisely because it survived: 18.7 s and
18.1 s, 364 and 343 requests, an hour apart. Numbers that repeat are findings. Numbers that appear
once are hypotheses, and the coin lands heads about half the time.

There is a third failure mode worth naming, because it looks like a finding and it is not yours:
I measured the same home page twice and got 10 510 KB / 453 requests and then 4 162 KB / 492
requests. Two visits, one page, six megabytes apart. The difference was an embedded social feed
pulling roughly 2.9 MB of images from someone else's CDN, and what it served varied per visit. The
shop's own pages were light. If you are reporting a number to a client, know whose bytes you are
counting.

What I would actually do with this store

In order, and only in this order:

Count requests per host and per feature. Not per file type — per feature. "The reviews app is 64 requests" is an actionable sentence. "Images are 210 requests" is not.
Delete before optimising. On most storefronts there is at least one app that was installed for a campaign two years ago and never removed. It costs zero engineering hours to remove and it is usually worth more than every other item on the list.
Bundle what is left. Icons into a sprite or inline SVG, fonts to the two weights you actually render, a script that ships eleven files into one.
Move what survives off the critical path so it is not holding load open — defer, or load on interaction.
Re-measure cold, twice, and compare load to the two runs above. If it did not move in both runs, it did not move.

Eighteen seconds does not become one second. It becomes three or four, and the pixels the owner is
paying for start firing while the customer is still on the page.

If your own numbers look like the table at the top — small page, long tail — the two console
snippets above will tell you which host is doing it, and that is genuinely most of the work.

I do this kind of measurement and the repair that follows, mostly for storefronts and product
sites. Portfolio: smirnov-artur.github.io/webgl ·
Telegram @smirnovarturr · paladei702@gmail.com.

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.