Start with an audit, not a rewrite

PWA techniques can bring a lot to a site, but they won't fix a weak foundation. If your pages are weighed down by render-blocking JavaScript or oversized images, no amount of manifest files, service workers, or install prompts will save the user experience. The right first move is a site audit: an objective look at what's working and what's dragging you down.

An audit gives you a concrete starting point. You get a baseline you can measure future changes against, evidence for why certain work matters, and a prioritized list of quick wins that don't require heavy sign-off. It makes development data-driven: you're not guessing whether a change helped, you're comparing before-and-after numbers.

A 5-minute starting point

If you only have a few minutes, run Lighthouse on your homepage and save the report data. That single report gives you a quantified baseline and a to-do list spanning performance, accessibility, security, and SEO.

A 30-minute sweep

With half an hour, keep Lighthouse as your anchor but add these checks:

  • Chrome DevTools Security panel: verify HTTPS usage on all assets.
  • Chrome DevTools Network requests panel: review load timings, resource sizes, and request counts for HTML, CSS, JavaScript, images, and fonts.
  • Chrome Task Manager: if your site consistently eats significant CPU or memory, investigate potential leaks or heavy background tasks.
  • WebPagetest: check caching behavior, time to first byte, and CDN usage.
  • PageSpeed Insights: get load performance, data cost, and real-world performance stats from Chrome User Experience report data.

Whatever tools you use, mimic a first-time visitor. Open the site in an incognito window or disable caching and clear storage so no asset comes from local cache. Then go further and test on real devices and connections that reflect your actual users. Record your subjective experience alongside the numbers.

If the tooling is overwhelming

Refer to our guide How To Think About Speed Tools. At minimum, use Lighthouse to flag the usual suspects:

  • Assets served over plain HTTP instead of HTTPS.
  • Server or CDN settings that skip compression, don't use HTTP/2, or omit headers that enable browser caching.
  • Script tags that could move to the end of the <body> or get an async or defer attribute.
  • JavaScript and libraries you can remove entirely, plus unused CSS or JS code shipped to users.
  • Images that are larger than needed in pixel dimensions, or stored in a format (like PNG) that could be swapped for something more compact (like JPG) without a quality hit.

Context beats a generic checklist

An audit is only useful if it reflects your situation. Start with the basics: who visits, why, and on what device or network? What's your performance budget? Next, consider your stakeholders—they'll influence how you structure and present your findings. If auditing the entire site is unrealistic, check page analytics to spot problem areas: high bounce rates, low time-on-page, and exits from unexpected pages are strong clues. Add business metrics that matter, like hosting costs, ad clicks, or conversions, and ask stakeholders what data they care about.

Establish a baseline before you change anything

Record your site's state before touching a line of code. That baseline is what will later prove your improvements (or expose regressions), and it gives you hard evidence to justify the effort you're asking for. For multi-page sites, sample several page types. For single-page apps, don't just test the first load—exercise the components, routes, and user flows that matter.