The most honest test of a diagnostic tool is whether you use it on yourself. We do. Stackra runs on Replit's infrastructure, served by an Express backend with a React frontend. The same categories of issues we flag for scanned sites -- uncompressed assets, oversized images, slow LCP, unnecessary font weight -- can appear on any site including ours. Over the past few months we have found and fixed several of them. Here is the full list with actual numbers.

The scan that flagged uncompressed JS

One scan in particular drove the most direct fix. Running stackra.app through Stackra surfaced a 0.62MB uncompressed JavaScript payload. Compression was not enabled at the server level. Every visitor downloading the JS bundle was receiving it uncompressed -- a straightforward problem to fix but easy to overlook when nothing is actively telling you about it. The fix was a single middleware addition: the Express compression package registered as the first middleware before all routes and static file serving. With it in place, all responses including API JSON, HTML, JS bundles, CSS, and SVG files are now gzip compressed. The 0.62MB payload now transfers as 186 KB.

The JavaScript bundle was also too large

Even before compression, the initial JS bundle was larger than it needed to be. The entry point was 1,769 KB, loading every page's code upfront regardless of which page a visitor was on. Heavy pages like the dashboard (301 KB) and admin metrics (390 KB) were included in the bundle that landed on the homepage. We split the codebase into 17 lazy-loaded chunks using React's built-in code splitting. Each page now loads its own code on demand. The entry bundle dropped from 1,769 KB to 611 KB, a 65% reduction, before compression even applies. With gzip on top, the transfer size for the entry bundle is 186 KB.

  • Google PageSpeed Insights ↗

    Check your own JS payload size under Opportunities. "Reduce unused JavaScript" flags bundles that ship more code than a page needs.

Mobile LCP was 6-7 seconds despite fast servers

Server response time was 72ms, which is good. But mobile LCP was measuring 6 to 7 seconds. The gap points to something blocking the browser from painting the main content, not a slow server. The cause was a scroll animation applied to the first visible section below the URL input. The animation set opacity: 0 at CSS parse time and only revealed the element after JavaScript loaded, React hydrated, and an IntersectionObserver fired. The heading, which was the LCP element, was invisible until all of that completed. Removing the scroll reveal from that section dropped LCP from 6-7 seconds to well under a second on mobile.

A 419KB favicon on every page

After the logo fix, we checked every image asset the homepage requested. The favicon was a 1024x1024 PNG at 419KB. Browsers request the favicon on every page load. It sits in the browser tab at 16 or 32 pixels on screen, yet we were serving a file more than four times the size of the logo we had just replaced. We generated proper icon files sized to match their actual display dimensions. The browser tab favicon became a multi-size ICO file at 5.4KB. The apple-touch-icon was replaced with a correctly-sized 180x180 PNG at 8.6KB.

A monospace font loading on every page

The dashboard uses JetBrains Mono, a monospace font suited for displaying code-like output. It was declared in the global stylesheet, which meant every visitor on every route -- the homepage, blog, benchmarks, about page -- downloaded 31KB of font data they would never use. Moving the font declaration to a stylesheet imported only by the dashboard removed it from every other route. While reviewing fonts, we also narrowed the Google Fonts weight range. The inter font family was loading weights from 100 through 900 including italic variants. The site uses weights 400, 500, 600, and 700 only, with no italic text. Removing the unused weights and italics reduced the font payload further.

What this means for your own site

None of these problems required difficult fixes. Each one was a straightforward change once identified. The harder part is knowing they exist. A 419KB favicon or a missing compression header does not produce a visible error. The site appears to work normally. The only sign is a slower page, a larger transfer, or a lower performance score. Running a performance audit surfaces these issues with the specific files and estimated savings attached. The scan that flagged our uncompressed JS did not require us to know to look for it. It was just in the report.