The latest articles on DEV Community by 360Presence (@360presence). https://dev.to/360presence https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3723864%2Fe5d19694-8adf-47b0-a6bd-f0c29b83c9fe.png https://dev.to/360presence en 360Presence Wed, 21 Jan 2026 13:43:31 +0000 https://dev.to/360presence/why-most-fast-websites-are-still-slow-in-production-35ng https://dev.to/360presence/why-most-fast-websites-are-still-slow-in-production-35ng <p>We shipped a website that scored 95+ on Lighthouse.</p> <p>It still felt slow in production.</p> <p>Not “a bit off.”<br> Not “edge cases.”<br> Slow enough that users noticed.</p> <p>This is a teardown of where it actually broke.</p> <h2> What Looked Fast (Before Production) </h2> <ul> <li>Lighthouse score: green</li> <li>Images optimized</li> <li>Code split</li> <li>CDN enabled</li> <li>Pages loaded in under a second on dev machines</li> </ul> <p>Everything checked out.</p> <h2> What Production Exposed Immediately </h2> <p><strong>1. The Site Loaded Fast. It Didn’t Become Usable Fast.</strong></p> <p>HTML showed up quickly.<br> Then the UI froze.</p> <p>Scrolling lagged.<br> Clicks didn’t register.<br> Buttons waited.</p> <p>The issue wasn’t load time.<br> It was main-thread blocking.</p> <p>JS was doing too much after load.</p> <p><strong>2. Third-Party Scripts Didn’t Show Up in Testing</strong></p> <p>In production we had:</p> <ul> <li>Analytics</li> <li>Heatmaps</li> <li>Chat widget</li> <li>CRM tracker</li> <li>A/B testing script</li> </ul> <p>Each one “small.”<br> Together? A mess.</p> <p>They competed for the main thread and delayed interaction.<br> None of this showed up in local tests.</p> <p><strong>3. Mobile Was a Different Website</strong></p> <p>Desktop felt okay.<br> Mobile felt broken.</p> <p>Low-end Android devices:</p> <ul> <li>JS execution was slow</li> <li>Animations dropped frames</li> <li>Hydration took forever</li> </ul> <p>We optimized for screens we don’t actually ship to.</p> <p><strong>4. Lighthouse Didn’t Catch the Real Pain</strong></p> <p>Lighthouse said:</p> <ul> <li>Good LCP</li> <li>Acceptable CLS</li> <li>Decent FCP</li> </ul> <p>Users said:</p> <ul> <li>“Scrolling feels stuck”</li> <li>“Buttons don’t respond”</li> <li>“It loads but doesn’t work”</li> </ul> <p>Perceived performance ≠ metrics.</p> <h2> 5. Infrastructure Wasn’t the Bottleneck (We Assumed It Was) </h2> <p>We first blamed:</p> <ul> <li>CDN</li> <li>Hosting</li> <li>Cache config</li> </ul> <p>None of it fixed the problem.</p> <p>The real issue was how much JS shipped up front<br> and what ran immediately after load.</p> <h2> What We Changed (After Production Reality) </h2> <ul> <li>Killed non-essential third-party scripts</li> <li>Deferred everything that wasn’t critical</li> <li>Removed animations on first paint</li> <li>Reduced client-side work aggressively</li> <li>Tested only on low-end devices</li> <li>Started measuring real user interaction delay, not just load time</li> </ul> <p>The site didn’t just score well anymore.<br> It felt fast.</p> <h2> The Actual Lesson </h2> <p>Most websites aren’t slow because teams are careless.</p> <p><strong>They’re slow because:</strong></p> <ul> <li>Performance is optimized in isolation</li> <li>Production complexity is underestimated</li> <li>Nobody owns performance after launch</li> </ul> <p>Speed doesn’t die in development.<br> It dies in production.</p> <p>Written from production lessons at <a href="https://360p.co/" rel="noopener noreferrer">360presence</a>, where performance only counts when real users feel it.</p> javascript frontend performance webdev