Actual load time and perceived load time aren't the same measurement, and most performance audits only check the first one. These seven free tools cover both sides: raw timing metrics and the interface-level signals, layout shift, loading indicators, motion, that shape how fast a page actually feels to a real person.
None of these require a paid subscription or an enterprise monitoring contract to get useful, actionable results. A small team can run through this entire list in an afternoon and walk away with a clear picture of where a product's perceived performance actually breaks down, rather than a single aggregate score with no obvious next step attached to it.
Lighthouse
Built into Chrome DevTools and available as a standalone CLI, Lighthouse audits a page for performance, accessibility, and best practices in one pass. Its Cumulative Layout Shift and Largest Contentful Paint scores are the closest built-in proxy for perceived speed, and the accessibility audit catches missing aria-busy or aria-live attributes on loading regions, which most performance-only tools skip entirely.
Run it in incognito mode with extensions disabled for the most reliable score, since browser extensions can noticeably skew both the performance and accessibility numbers without it being obvious from the report alone.
PageSpeed Insights
PageSpeed Insights runs Lighthouse against a live URL and layers on real-world field data from the Chrome User Experience Report, so you get both a lab score and actual data from Chrome users who've visited the page. The field data is particularly useful for catching cases where a page tests fast in a lab environment but feels slow to real visitors on slower connections or older devices.
The field data requires enough real traffic to populate, so a low-traffic page may show lab data only. That's still useful, but treat it as a starting estimate rather than confirmation of how real users actually experience the page.
WebPageTest
WebPageTest goes deeper than most free tools, letting you test from specific geographic locations, connection speeds, and device profiles, and it produces a filmstrip view showing exactly what the page looked like at each moment during load. That filmstrip is one of the more useful ways to actually see a skeleton or loading state in action frame by frame, rather than inferring its behavior from a single aggregate score.
It's also one of the few free tools that lets you compare two URLs side by side, which is genuinely useful when testing a skeleton-screen version of a page against a spinner-only version, watching both filmstrips play in sync to see which one actually resolves the perceived wait faster.
GTmetrix
GTmetrix combines Lighthouse-style scoring with a waterfall view of every network request, which is useful for tracking down exactly which asset is delaying the point where your skeleton state can resolve into real content. Its free tier includes video capture of the page loading, similar to WebPageTest's filmstrip.
The waterfall view specifically is worth studying closely if your skeleton state seems to linger longer than expected, since it's common to discover a single slow third-party script or an unoptimized image is the actual bottleneck, not the API call your team assumed was the culprit.
Chrome DevTools Network Throttling
Built directly into Chrome, the DevTools network panel lets you throttle to preset or custom connection profiles and watch your loading states behave under realistic conditions, rather than the fast office wifi most development happens on. This is the fastest way to catch a skeleton that flickers too quickly or lingers too long before you ship it.
Custom throttling profiles are worth setting up if your actual user base skews toward a specific connection type the presets don't capture well, a mostly-mobile audience in a region with slower average mobile speeds, for instance, rather than relying only on the generic "Fast 3G" and "Slow 3G" defaults.
axe DevTools
Performance tools rarely check accessibility, and accessibility tools rarely check performance, which is exactly the gap axe DevTools fills for loading states specifically. It flags missing aria-busy regions, unlabeled loading spinners, and other accessibility gaps that a pure performance audit like Lighthouse won't catch on its own.
It runs as a browser extension directly against your live page, so there's no separate setup step beyond installing it, which makes it easy to run alongside a normal manual QA pass rather than treating accessibility auditing as a separate, occasional exercise.
WAVE
WAVE is a free, browser-based accessibility evaluation tool that visually overlays issues directly on the page, including missing labels on interactive and loading elements. It's a useful complement to axe DevTools since the two tools occasionally catch different issues, and running both takes only a few extra minutes.
WAVE's visual overlay approach makes it particularly easy to hand results to someone without an accessibility background, since the icons appear directly on the page next to the element they're flagging, rather than in a separate report that requires cross-referencing against the live page.
Putting These Together Into an Actual Workflow
No single tool on this list covers both perceived performance and accessibility completely. A reasonable workflow: run Lighthouse or PageSpeed Insights for the baseline score, use WebPageTest or GTmetrix's filmstrip to actually watch your loading states in motion, throttle in Chrome DevTools to test realistic conditions, and finish with axe DevTools or WAVE to catch accessibility gaps the performance tools miss entirely.
Repeat this workflow periodically rather than once, ideally after any significant change to a loading state or the components it wraps, since a regression in perceived performance is just as easy to accidentally introduce as a regression in raw load time, and far easier to miss without a repeatable checklist.
Where the Design Side of This Fits
Tooling only measures the problem, it doesn't fix it. This guide on designing skeleton loading states covers the actual design decisions, layout matching, timing, motion, and accessibility markup, that these tools are checking for in the first place.
A Final Note on Free vs Paid
All seven tools above have free tiers usable for a small to mid-size site's audit needs. 137Foundry's web development team typically reaches for this exact combination, Lighthouse for the baseline, WebPageTest for the filmstrip, and axe for accessibility, before recommending any paid monitoring service, since most perceived-performance issues are visible with free tooling alone once you know what to look for.
Paid monitoring tools earn their cost once a product has enough traffic and enough moving pieces that continuous, automated tracking beats a periodic manual audit. Below that threshold, an occasional pass through this list, done consistently after major changes, catches the vast majority of perceived-performance regressions before real users ever notice them.
A Note on Prioritizing What You Find
Not every issue these tools surface deserves equal attention. A missing aria-busy attribute on a rarely-used loading state matters less than the same gap on your product's primary dashboard or landing page. Triage findings by how often real users hit the affected surface, not by the raw count of issues a tool reports, since a long list of low-traffic warnings can crowd out the smaller number of fixes that would actually move the needle for most users.
A simple triage pass: sort every flagged issue by the page's traffic, fix the top handful on your busiest surfaces first, then schedule the rest as ongoing cleanup rather than a single blocking task. This keeps the audit actionable instead of turning into a backlog nobody works through.
Top comments (0)