Slow WordPress site fixed: patients on a phone see the page in 4.9 seconds, not 104

What changes for the clinic

• Before: a patient taps the clinic's link on mobile data and stares at a blank screen. In the filmed test the page took 142.7 seconds to finish loading. Many people give up long before that.
• After: same phone, same slow connection: the page is done in about 10 seconds, and the "Book an appointment" button is there to tap.
• Also: Google counts page speed when ranking sites, and its Lighthouse score for this page went from 55 to 78.
• For you as the owner: no redesign, no new paid tools, nothing to learn. The site you know, just faster. The fix script ran in under 3 minutes and can be run again.

What I'd do on your site

1. Backup first: a full copy of your files and database, kept off the server, before anything changes.
2. Staging copy: I work on a copy of your site (your host's staging or a private copy), not the live one.
3. Measure: Lighthouse on your key pages, median of 3 runs, plus Google's real-visitor data where your site has it.
4. Fix, one step at a time: photos, unused plugins, caching, fonts, scripts, database, checking the pages after each step.
5. Re-measure with the same method, so the before and after are fair.
6. Report: a one-page before/after like the one above, what I changed and why. Changes go live only when you approve.

What you get: the backup, the before/after report, a list of every change, and if you want ongoing care, a monthly routine to keep it fast: plugin and theme updates on staging first, removing plugins you no longer use, a database cleanup and a fresh speed check.

I haven't done this on a paying client's site yet; this demo is how I'd work on yours.

Nothing visibly changed

Before

After

The fix is checked, not eyeballed: every heading from the old page must still be on the new page (17 of 17, at desktop and phone width), and full-page screenshots before and after differ by less than 0.1% of pixels, which is the photos being re-compressed.

Results

The problem: a site that looks fine on office Wi-Fi

The site looked fine on a fast connection, so nobody noticed. Underneath:

• 12 photos straight from a camera, 3200 px wide and up to 3 MB each, 24 MB in total, shown at full size.
• Plugins nobody used still loading their files on every page: a slider, a second form builder, an icon pack, an Instagram feed with no feed.
• No page cache and no compression, so every visit rebuilt and resent the whole page.
• Three Google Font families in every weight, fetched from Google's servers.
• 13 scripts blocking the page while they loaded.
• Database clutter: 362 old revisions, 603 expired temporary entries, 250 spam comments.

The fix: one script, six steps

Everything is done with WP-CLI (WordPress's command line) and free tools, in one script that can be run again safely:

1. Plugins. Removed the 3 unused ones (active plugins 7 → 4). The form and Instagram files now load only on pages that use them.
2. Photos. Resized to at most 1920 px and converted to WebP: 24,286 KB → 1,246 KB. Real smaller sizes for phones, lazy-loading for photos further down, and the main picture loaded first.
3. Caching. Page cache with Cache Enabler (free), gzip compression and browser-cache headers. The page's HTML went from 148,928 bytes to 24,945 bytes over the wire.
4. Fonts. Elementor's fonts served from the site itself with font-display: swap, so text shows right away (requests to Google Fonts 3 → 1). Emoji script off.
5. Scripts. Deferred with WordPress's own loading strategy: render-blocking scripts 13 → 0, and the slideshow still works.
6. Database. Revisions, expired entries and spam cleared (362, 603 and 250 → 0), then the tables optimised.

Desktop, before and after

Before

After

Tools used

• WordPress with Astra and Elementor, in Docker; WP-CLI for every change.
• ImageMagick + cwebp for the photos; Cache Enabler (free) for page caching; Apache gzip and Expires rules.
• Google Lighthouse 13.5.0 to measure; Playwright to screenshot and check that nothing visible changed.

View the code on GitHub → (slow-site setup, fix.sh, measure and check scripts, MIT licence)

FAQ

Will speeding up my site break it or change how it looks?

I work on a backup and a staging copy first, never straight on the live site. In this demo the fix is checked automatically: every heading from before must still be on the page after, at desktop and phone width, and full-page screenshots before and after differed by less than 0.1% of pixels (from re-compressing the photos). If a step breaks something on your site, it is rolled back before anything goes live.

Do I need to buy a premium plugin?

Not for this fix. It used WP-CLI, ImageMagick and cwebp for the photos, and Cache Enabler, a free plugin from WordPress.org, for page caching. If your site already has a paid speed plugin, I would work with it rather than add another.

Will my site score 78 too?

I cannot promise a number. Every site, theme and host is different, and Lighthouse scores move a few points between runs. What I can promise is a measured before and after on your own site, with the same method, so you see exactly what changed.

Why not 100?

On this demo the main picture is part of an Elementor slideshow that needs JavaScript, and the theme and builder load many small stylesheets. Getting closer to 100 would mean rebuilding the design, which is a different job. The big win for visitors, a page 96% lighter whose main picture shows in seconds, needed no redesign.

Is this a real client site?

No. Bayview Dental is a demo clinic I built on WordPress the way real client sites often end up slow: big camera photos, plugins nobody uses, no caching. The measurements are real, taken on my machine with Lighthouse. There is no paying client here.