The 30-Minute Website Speed Checklist for Small Businesses

A faster site converts more of the visitors you already have and ranks higher for the ones you don’t yet — Core Web Vitals are a confirmed Google ranking signal, and every additional second of load time visibly increases the share of people who give up before your page finishes arriving. Speed is the rare investment that pays on both sides of the funnel at once, which is why it is the first thing we audit on any store or site that comes to us.

This checklist is designed for a specific situation: you run a small business site — WordPress or Shopify, most likely — you have thirty minutes, and you want the fixes ranked by payoff rather than a lecture on rendering pipelines. Work through it top to bottom; the items are ordered so the biggest wins come first.

Minute 0–5: get a truthful baseline

Run PageSpeed Insights against your homepage, your most-visited product or service page, and one blog post — the three templates that carry most of your traffic. Record the mobile scores, not the desktop ones; your customers are on phones and Google’s evaluation is mobile-first. Pay attention to two sections: the field data at the top (what real Chrome users experienced over the last 28 days — this is what actually affects ranking) and the three Core Web Vitals: LCP (how fast the main content appears — good is under 2.5 seconds), INP (how quickly the page responds when tapped — under 200 milliseconds), and CLS (how much the layout jumps around while loading — under 0.1).

Do not chase the score itself — a 100 is a vanity project. Chase the three vitals into their green zones on your money pages, then stop and go run your business.

Minutes 5–15: images, the usual suspect

Open your worst-scoring page and look at what PageSpeed lists under “properly size images” and “serve images in next-gen formats”. On small-business sites this is where the seconds live, and the fixes are mechanical:

• Resize to display size. A 4000-pixel photo squeezed into a 400-pixel card ships ten times the bytes anyone can see. Export images at roughly the largest size they will display, and let responsive srcset handle the rest — WordPress generates the sizes automatically if the original is sane.
• Convert to WebP. Same visual quality, dramatically smaller files than JPEG or PNG. On WordPress a caching or image plugin converts your library in one pass; Shopify serves WebP automatically — but only if the files you uploaded were not already bloated beyond help.
• Lazy-load below the fold. Images the visitor has not scrolled to should not compete for bandwidth with the ones they are looking at. Modern themes and WordPress core do this by default — verify it is actually happening rather than assuming.
• Never lazy-load the hero. The one image that must arrive instantly is the LCP element itself — lazy-loading it is the single most common self-inflicted LCP wound. Mark it high-priority instead.
• Set width and height attributes on every image so the browser reserves the space before the file arrives — this alone fixes most CLS problems, because the page stops reflowing every time a picture lands.

Fifteen minutes of image discipline routinely takes a mobile LCP from four-plus seconds into the mid-twos. Nothing else on this list has that ratio of effort to result.

Minutes 15–22: the plugin and app purge

Every plugin, app and third-party embed is JavaScript your visitors download whether or not it does anything on that page. Walk your list with three questions: what does this do, does anything else already do it, and have I opened its settings in ninety days? Deactivate ruthlessly. The repeat offenders we find on client sites: two analytics tools measuring the same thing, a slider plugin powering one banner that could be a static image, social feed widgets loading an entire third-party application to show three photos, and “free” plugins whose business model is loading their marketing scripts on your pages.

On Shopify the same logic applies to apps — with the extra step that uninstalled apps often leave script tags in the theme. If an app was removed but its code lingers, the weight lingers too; our Shopify CRO checklist covers the app audit in detail.

Minutes 22–27: caching and delivery

With the payload slimmed, make sure it is delivered intelligently. On WordPress, one good caching plugin (page cache on, CSS/JS minification on, browser caching headers on) does more than any hosting upgrade at this scale — configure it once, then resist the urge to stack a second optimisation plugin on top; they fight, and the fights are slower than either alone. If your host offers server-level caching (LiteSpeed, Varnish), prefer it and let the plugin fill the gaps. Put the site behind a CDN if your customers are geographically spread — static assets served from a node near the visitor shave real time off every request.

Two smaller delivery wins while you are here: preconnect to the third-party origins you genuinely need (fonts, analytics) so their connections are warm before they are used, and self-host your fonts if your privacy posture allows — one fewer external dependency in the critical path.

Minutes 27–30: stability and the retest

Reload your key pages on a phone and watch for movement: banners pushing content down as they arrive, buttons that dodge your thumb, embeds appearing late and shoving everything sideways. Each jump is CLS — and each has the same fix: reserve the space in advance (dimensions on images and embeds, a fixed-height slot for anything injected). Then re-run PageSpeed on the same three pages and compare against your baseline. In our experience of running exactly this sprint on client sites, the before/after on mobile LCP is usually the difference between “visitors notice the wait” and “visitors don’t think about it at all” — which is the entire point.

Beyond the sprint: the fixes that need a developer

The thirty-minute pass above clears the problems that cause most slow sites. If your vitals are still amber afterwards, the remaining causes are structural, and worth knowing about even if you hand them to someone else:

Render-blocking CSS and JavaScript

Browsers pause rendering while they download and parse stylesheets and synchronous scripts referenced in the head. Themes accumulate these for years — five stylesheets where one would do, a jQuery plugin loaded globally for a widget used on one page. The fixes — critical CSS inlined, the rest deferred, scripts loaded async or moved out of the critical path, unused rules purged — are developer work, but they are bounded, one-time work: a day or two that permanently removes half a second from every page view.

Theme bloat and the rebuild question

Some themes cannot be optimised into health — multipurpose templates carrying sliders, page builders, icon packs and three animation libraries on every request. The tell: PageSpeed’s “reduce unused JavaScript” shows hundreds of kilobytes from files the page never calls. At that point the honest comparison is optimisation-forever versus a rebuild on a lean foundation with a speed budget — the arithmetic we run with clients in the first week of every website engagement, because sometimes the rebuild is genuinely cheaper than the maintenance.

Hosting that matches your traffic

Shared hosting is fine until it is not: TTFB (time to first byte) consistently above ~600 milliseconds on a cached page is the server itself being slow, and no front-end work can compensate. Moving from oversold shared hosting to a modest managed or VPS plan is usually a small monthly difference for a large latency one. Measure TTFB before blaming your theme.

Third-party scripts you cannot delete

Chat widgets, analytics, ad pixels — the scripts the business insists on. The mitigation pattern: load them after the page is interactive (delayed or on first interaction), host what can be hosted locally, and give each one a quarterly justification review. A chat widget that generates leads earns its milliseconds; one that answered four questions last quarter does not.

Platform notes: WordPress vs Shopify specifics

WordPress gives you total control and total responsibility: your speed is your theme, your plugins and your host, in that order. The leverage list: a lean theme, one caching plugin configured well, image optimisation automated at upload, plugins audited quarterly, PHP kept on a current version (each major PHP release is measurably faster, and hosts often leave sites on old versions unless asked).

Shopify handles hosting, CDN and image formats for you — which moves the entire battleground to two fronts: app weight (each app injects scripts you cannot see in a theme editor) and theme quality. You cannot fix Shopify’s infrastructure, and you do not need to; you can absolutely fix the fourteen apps injecting fourteen scripts into a theme that was quick before they arrived.

Making it stick: the quarterly half-hour

Speed is not a project with an end date — every new plugin, image upload and campaign pixel spends the budget again. The maintenance habit that keeps the wins: a calendar reminder every quarter to re-run PageSpeed on the same three pages, compare against your recorded baseline, and walk the plugin/app list with the three questions. Thirty minutes, four times a year. Sites that do this stay fast for years; sites that do not are usually back where they started within eighteen months — we know because they become our clients then.

What thirty minutes on a real site looks like

To show the checklist is not theoretical, here is the shape of a recent pass on a typical client site — a WordPress services business with a portfolio and a blog, the same profile as most sites reading this.

The baseline: mobile LCP at 4.6 seconds on the homepage, 5.1 on the services page. Field data amber across the board. CLS at 0.24 — the page visibly assembled itself in stages while loading, with the hero image landing last and shoving the headline down as it arrived.

Minutes five to fifteen: the hero was a 3.4-megabyte PNG exported straight from a design tool; every portfolio thumbnail was the full-resolution original scaled down by CSS. Bulk-converted the library to WebP, regenerated sensible sizes, marked the hero as high-priority instead of lazy, and added missing dimensions. That alone brought homepage LCP to 2.9 seconds and CLS to 0.06.

Minutes fifteen to twenty-two: nineteen active plugins. Two page builders (one unused), two contact form plugins (one powering a form deleted a year ago), a slider plugin for a static banner, a social feed widget loading a third-party app on every page, and an “analytics enhancer” nobody could explain. Deactivated seven, replaced the slider with a static image. Total JavaScript dropped by roughly a third.

Minutes twenty-two to thirty: configured the caching plugin the host had installed but never enabled — page cache, minification, browser caching — and preconnected the fonts origin. Retest: homepage LCP 2.2 seconds mobile, services page 2.4, CLS 0.02, INP already fine. All three vitals green, from a standing start, inside the half hour — and nothing about the visual design changed at all.

The honest caveat: this site had the classic problems, which is exactly why the sprint works so often. A site already past the easy fixes graduates to the developer list above — and if that is you, the audit at least proved it, which is worth the thirty minutes by itself.

The five-tool kit

Everything in this article uses free tooling: PageSpeed Insights for scores and field data; your browser’s DevTools network tab (sorted by size) to spot the heaviest assets in seconds; Search Console’s Core Web Vitals report for how Google sees the whole site rather than one page; a bulk image converter (plugin on WordPress, built-in on Shopify); and a caching plugin configured once. No subscriptions, no dashboards — the constraint is attention, not budget, which is the most optimistic fact in web performance.

The bottom line

Most slow small-business sites are slow for boring reasons: oversized images, accumulated plugins, unreserved layout space and a cache nobody configured. Thirty focused minutes fixes the majority of it; a quarterly half-hour keeps it fixed. Measure first, fix in payoff order, retest — and spend the seconds you save on visitors who now stay long enough to become customers.