I spent a morning connecting a session-recording tool to OneFindMe, the AliExpress product search engine I run in twelve languages, expecting to learn something about user behaviour. Instead it handed me a list of JavaScript errors, and every single one turned out to be a bug that had been in production for weeks while every check I had was green.
That is the part worth writing down. Not the bugs — bugs are ordinary. The fact that my entire measurement apparatus was structurally incapable of seeing them.
That escaping is correct — for an HTML attribute. It is wrong for a JavaScript string, and the attribute is both.
The HTML parser decodes ' back into a bare apostrophe before the browser compiles the attribute as JavaScript. So for a product titled Women's Vacation Dress, what the engine actually tries to compile is:
HTML entity escaping does not protect a JavaScript string literal in an inline handler. Entities are decoded first.
Then I counted how often it mattered: 9 of 24 products on one search, 14 of 42 on another. Roughly a third of every result page.
The damage is worth being precise about, because the obvious guess is wrong. The ` was untouched, so no sale was lost — shoppers still reached the retailer. What broke was everything the handler did: the favourite button and the share button silently did nothing on those products, and the click never reached my analytics.
Which means every click-through rate I had measured, for months, was an undercount — and I had been making product decisions on those numbers.
The fix is the one you already know: get the data out of the JavaScript entirely.
.deals-btn did not exist anywhere on the page. It had been renamed at some point and this function never updated. It threw on line three, before the line that actually did the work — so the two visible buttons that called it were completely inert.
Then I opened the session recording attached to that error, and it stopped being an abstraction:
Five clicks in 26 seconds, inside a seven-minute session where the same person also hit "load more" nine times. That is not a confused user. That is someone who wanted to buy something, pressing a button that did nothing, until they gave up.
A handler that throws leaves no trace on the server. No 500, no slow query, no error log. The only signature it leaves is a human being clicking the same thing over and over — and you can only see that if something is recording the page.
The product rows had no CSS at all. The page carried its own inline styles and had stopped loading the shared stylesheet; nobody noticed that the rules for one component never came with it. Cards rendered as full-width inline elements with uncapped images — one product per phone screen. The check that found it is one line:
Then the cards collapsed to one pixel. The message list is a column flexbox that overflows, and flex-shrink defaults to 1, so every child gets squeezed to make the container fit. The images were fully downloaded and completely invisible:
And loading="lazy" never fired inside that scroll container. Nine cards sat in the viewport with zero decoded images, while the exact same URL loaded instantly when fetched directly:
Forcing eager on one loaded it immediately. Lazy loading is the wrong default for a handful of thumbnails the user explicitly asked to see; I removed it.
The common thread is not carelessness. It is that my assertions were about the wrong layer. I was checking that the server returned the right JSON quickly, and it always did. The bugs all lived between the JSON and the pixels.