July 12, 2026
Scroll me maybe, crash me softly
Are you telling me a readonly property is wrecking my performance?
Turns out one tiny ‘read-only’ trick was secretly making the app crawl
TLDR: The slowdown wasn’t caused by some huge coding mistake but by repeatedly asking the browser how tall the page was before scrolling. Commenters turned it into a cautionary tale, arguing that “read-only” doesn’t mean cheap and swapping war stories about tiny lines of code causing massive slowdowns.
A developer went hunting for some big, obvious slowdown in their chat app and instead stumbled into a classic tech plot twist: the innocent-looking line that keeps the screen pinned to the newest message was the real villain. Reading a so-called read-only value to figure out how far to scroll wasn’t cheap at all, and every new message made the browser stop and recalculate the page. The fix? Skip the perfect number and just shove the scroll way down with a giant value. Messy, but effective — and the comments absolutely ate this up.
The crowd’s strongest reaction was basically: welcome to the browser pain club. One commenter warned that anything tied to page layout can be a secret wallet-drainer for performance, while another called out the ultimate nightmare move: changing a page and measuring it again in the same loop, over and over, like pressing the elevator button 50 times and wondering why it’s slow. But the thread also had a mini philosophy fight. Some people insisted “read-only” never meant “fast,” just “you can’t set it,” while others zoomed out into a bigger debate about how neat, safe abstractions can fall apart when real-world speed matters. And yes, there was some delightfully chaotic side chatter too, including a drive-by hot take claiming even JavaScript’s let and const can be suspiciously costly. In other words: one small property read became a full-blown comments-section therapy session.
Key Points
- •The author investigated a performance slowdown in Letta Desktop that worsened as the application was used more heavily.
- •The slowdown was traced to repeated auto-scrolling logic using `el.scrollTop = el.scrollHeight;` when new messages arrived.
- •The author had assumed `scrollHeight` would be inexpensive to read because it is a readonly property, but found that assumption was wrong.
- •A Chromium implementation snippet shows that reading `scrollHeight` can trigger style and layout updates through `UpdateStyleAndLayoutForNode(this)`.
- •The article's workaround was to set `scrollTop` to a very large number and let the browser clamp the value instead of computing the exact `scrollHeight` repeatedly.