Page Speed Optimization: Practical Fixes for Faster Pages
I once audited a WordPress site for a wedding photographer in Udaipur that took nine seconds to show anything on a phone. The fix wasn't clever. The homepage loaded forty full-resolution photos straight from the camera, each several megabytes, plus three slider plugins of which only one was in use. Compressing the images and deleting two plugins took an afternoon and cut the load time to a fraction of what it was.
Most speed problems look like that. Before reaching for advanced techniques, clear out the obvious weight.
Measure first
Pick three representative pages: the homepage, a key landing page and a typical blog post or product page. Run each through PageSpeed Insights and note:
- Time to First Byte (TTFB), which reflects your server.
- Largest Contentful Paint, which reflects how fast the main content appears.
- Total page weight and number of requests (visible in the Lighthouse details or the browser's Network tab).
Test on mobile settings. That is where most visitors are, and where weak pages fall apart. The Core Web Vitals article explains how field and lab numbers differ.
1. Hosting and server response
If TTFB is consistently above about 800 milliseconds, start here. Front-end tweaks can't make up for a server that's slow to answer.
- Cheap shared hosting often packs hundreds of sites on one machine. Moving to a decent managed host or a small VPS can cut TTFB noticeably.
- Page caching stores finished HTML so the server doesn't rebuild every page with PHP and database queries on each visit. On WordPress, a caching plugin or host-level caching does this.
- Server location matters. If your customers are in India and your server is in the US, each request crosses the world. Choose a region close to your audience, or put a CDN in front.
- Database bloat from years of revisions, spam comments and expired transients slows dynamic sites. Clean it occasionally.
2. Images
Images are the heaviest part of most pages.
- Resize to the size they're actually displayed at. A thumbnail shown at 300 pixels wide doesn't need a 3,000-pixel file.
- Compress. Modern formats like WebP and AVIF are much smaller than JPEG at similar quality, and all current browsers support WebP.
- Use
srcsetso phones get smaller files than desktops. Most CMS platforms generate these sizes automatically. - Lazy-load images below the fold with
loading="lazy", but never the main hero image. - Always set width and height to prevent layout shifts.
The image SEO guide covers the search side: file names, alt text and image sitemaps.
3. JavaScript and third-party scripts
This is the second biggest culprit, and on modern sites often the first.
- Audit every script. Open your tag manager and list each tag with the person who asked for it. Old Facebook pixels, abandoned heatmap tools and duplicate analytics tags pile up over the years.
- Defer or delay scripts that aren't needed for the first view. Chat widgets can load after the user scrolls or after a few seconds.
- Remove unused plugins. Each WordPress plugin can add its own CSS and JS to every page, even pages that don't use it.
- Question heavy page builders. Some themes load a large framework for simple layouts. If speed is a real problem, a lighter theme can do more than any optimisation plugin.
4. CSS and fonts
- Minify CSS and remove unused rules where your tooling allows. Be careful with automated "remove unused CSS" features, which sometimes strip styles needed by pop-ups or mobile menus. Test after enabling.
- Limit web fonts. Two families with two weights each is plenty for most sites. Every extra weight is another file.
- Self-host fonts or preconnect to the font provider, and use
font-display: swapso text appears immediately.
5. CDN and compression
A content delivery network caches your static files (and sometimes whole pages) on servers around the world, so a visitor in Chennai downloads from a nearby location rather than your origin. Many CDNs have free tiers that suit small sites.
Also confirm the server sends text files compressed with Gzip or Brotli. Most hosts do this by default, but it's worth checking in the response headers.
The order that gives the most gain
| Fix | Effort | Typical impact |
|---|---|---|
| Compress and resize images | Low | High |
| Enable page caching | Low | High on dynamic sites |
| Remove unused plugins and scripts | Low to medium | Medium to high |
| Move to better hosting or add a CDN | Medium | High if TTFB is poor |
| Defer JavaScript, optimise fonts | Medium | Medium |
| Rebuild on a lighter theme | High | High, but only if the theme is the problem |
What not to obsess over
A perfect 100 in Lighthouse is a vanity target. I've seen teams spend weeks shaving milliseconds off a page that already loaded quickly while their product pages had no unique content. Page speed is one part of page experience, and page experience is one of many signals. Once your pages load fast on a mid-range phone and pass Core Web Vitals, other work will usually move rankings more.
Also be careful with "all-in-one" optimisation plugins that enable dozens of settings at once. Turn options on one at a time and check the site after each, especially checkout and forms.
Run your heaviest page through PageSpeed Insights now, open the "Diagnostics" section, and look at the largest files being loaded. If the top entries are images, compress them today; it's the cheapest speed win you'll get.