We measured one of our own sites ahead of a rebuild we are planning, and found a bug that had been live for who knows how long. What makes it worth writing about is not the bug itself, but that it was impossible to see from the inside.
Some context first: alongside building sites at Prime Stack, we run a second service called site4rent, where we rent websites to businesses on a monthly fee instead of selling them. It lives on its own site, site4rent.co.il, and this story is about that one.
The measurement
On 29 July 2026 we ran the site through Google tool. The desktop score came back at 67. Not terrible, not good, and mostly not interesting.
What was interesting was a different metric entirely:
CLS: 0.354
CLS measures how much content moves while a page loads. Google treats 0.1 as the upper bound. We were three and a half times above it.
In plain terms: the page jumps under your finger. It is the familiar feeling of tapping a button and hitting something else, because something loaded and pushed everything down half a second before your finger landed.
The hunt
A text effect runs in the site top banner, the kind that scrambles letters and reassembles them into a new sentence. A nice effect, written sensibly, running there for months.
We measured it directly in the browser over six seconds:
| Measured | Result |
|---|---|
| Length of displayed text | 26 to 194 characters |
| Heights the element took | 27, 54, 81, 108, 135, 162 pixels |
| Height swing | 135 pixels |
The sentences on the site are 24 characters long. So where did 194 come from?
What was actually happening
The code as written held the sentences as plain Hebrew:
const phrases = [
'בלי לבנות אתר לבד ולהתקע',
'מוכן תוך 7 ימי עסקים',
];But what the server served to visitors was something else entirely:
const phrases = [
'בלי לבנות...',
];The CMS had converted every Hebrew letter into an encoded form. Those 24 characters became 144.
The effect, knowing nothing about this, started scrambling the encoded string character by character. Instead of cycling 24 characters it cycled 144, the text broke onto six lines, then collapsed back to one. On every sentence change, over and over, everything below it was pushed 135 pixels and back.
You could even see it with the naked eye, if you knew to look. Mid-animation, sequences like ] and #1%06] appeared on screen. They looked like part of the effect, but the character set the effect draws from contains no digits at all. Those were fragments of the code itself, showing through the animation.
And why nobody saw it
Because in the editor everything looked fine.
The editor shows what was typed: Hebrew, 24 characters. The conversion to the encoded form happens only on the way out, to the live site. So every check done from the inside showed an effect working exactly as intended.
The bug existed for visitors and for nobody else.
That also answers when it broke. Nobody touched the code. Someone opened and saved the component, the CMS encoded the Hebrew on the way through, and the effect had never been built to cope with that.
The fix and the result
The fix was small: decode the text before scrambling it, and build the elements in code rather than as a text string, so the CMS has nothing to rewrite on the way out.
The result, as a median of five runs before and after:
| Before | After | |
|---|---|---|
| Performance, desktop | 67 | 93 |
| Performance, mobile | 54 | 59 |
| CLS, mobile | 0.354 | 0.001 |
| Blocking time, desktop | 373ms | 93ms |
| Actual height swing | 135px | 0px |
No hosting change. No plugin removed. Nothing rebuilt.
Three things worth taking from this
A site can look fine to you and be broken for the people using it. The only difference is that somebody bothered to measure from the outside instead of only looking from the inside.
A single measurement is worthless. On the same page in the same minute we got scores ranging from 63 to 85 on desktop. Every number here is a median of five runs, which is also why we never promise a specific score in advance.
And the metric that screamed was not the score. The score was 67, a middling number nobody would get excited about. The real problem sat in an entirely different metric, and seeing it meant looking past the big number everyone looks at.
What is still open
Mobile only moved from 54 to 59. The shifting is gone, but there the problem is not a single defect, it is the sheer amount of code loaded on every page. That is no longer something you fix in one line, which is why that site is about to move to a completely different architecture. We will write about that next time, with numbers from both sides.
Want to know what is sitting on your site that you cannot see? That is exactly what our digital health report does: real measurement, ordered findings, and a list of what is worth fixing first.
Order a digital health report for your site