Seven performance checks — from script count to lazy-loaded images — that take under a minute to run on any page, no CLI or build step required.
Full performance audits can go deep — Core Web Vitals, waterfall charts, real-user-monitoring dashboards. Most of that is genuinely useful, and most of it is also overkill for a quick gut-check on a page you just shipped. These seven checks catch the common, cheap-to-fix problems without needing a CLI, a build step, or an account anywhere.
1. How many external JavaScript files does the page load?
Every external script is a network round-trip and a chunk of parse/execute time before the page is interactive. A handful of well-bundled files beats a long tail of small ones — each extra request adds latency that compounds, especially on a slower connection.
2. How many stylesheets?
Same logic as scripts: each <link rel="stylesheet"> is a render-blocking request by default. A page pulling in six or more separate stylesheets is usually a sign some of them could be combined or some of that CSS isn’t being used at all.
3. Are images lazy-loaded?
loading="lazy" on an <img> tells the browser not to fetch that image until it’s about to scroll into view — which matters a lot on image-heavy pages, since every unloaded-but-fetched image below the fold is bandwidth and time spent on something the user hasn’t scrolled to yet, and might never.
4. Do images have explicit width and height?
Without explicit dimensions, the browser doesn’t know how much space to reserve for an image before it loads — so the layout shifts once it arrives, pushing everything below it down. That’s a direct hit to Cumulative Layout Shift, and it’s also just visually janky. Set width and height (or use aspect-ratio in CSS) and the space is reserved up front.
5. Are scripts non-blocking?
A <script> tag with no async or defer stops the browser from parsing the rest of the page until that script has downloaded and executed. For anything that isn’t needed immediately — and most scripts aren’t — adding defer lets the page keep rendering while the script loads in the background.
6. Is there a responsive viewport tag?
Missing <meta name="viewport" content="width=device-width, initial-scale=1.0"> means mobile browsers render the page at a fixed desktop width and then scale it down — text ends up tiny, and the user has to pinch-zoom just to read. It’s a one-line fix with a large effect on perceived quality on a phone.
7. How big is the raw HTML document?
A bloated HTML document (inlined data, duplicated markup, excessive comments left in production) adds to the time before the browser even has something to start parsing. There’s no universal cutoff, but a document creeping past a couple hundred KB of raw HTML is usually carrying more than it needs to.
Running all seven at once
PerformanceForge runs exactly these seven checks against any URL or pasted HTML, in your browser, with no install and nothing sent anywhere except the one fetch of the page you’re checking. It won’t replace a full Lighthouse run or real-user monitoring for a production app that actually needs the deeper picture — but for a quick “did I just ship something obviously heavy” check, it’s a thirty-second answer instead of a CLI install.