How to Speed Up Your Website: 15 Fixes That Actually Work

Slow pages lose visitors. People abandon pages that take too long to load, and speed affects conversions, engagement and Core Web Vitals. The good news: most sites can get dramatically faster with a handful of changes.

This list is ordered roughly by impact for a typical site. Measure before and after each change so you know what worked.

1. Use good hosting

Everything starts with the server. If your Time to First Byte is consistently above about 800 ms, no amount of front-end tuning will fully compensate. Overcrowded budget shared hosting is a common bottleneck. Look for hosts with modern hardware (NVMe storage), current PHP or Node versions, HTTP/2 or HTTP/3 and data centres near your audience.

2. Turn on page caching

Generating a page from scratch – running code and database queries – on every visit is slow. Page caching stores the finished HTML and serves it instantly.

• WordPress: use a caching plugin (WP Rocket, LiteSpeed Cache on LiteSpeed servers, W3 Total Cache, WP Super Cache) or host-level caching
• cPanel: many hosts offer LiteSpeed Cache or similar built-in options
• Custom apps: cache rendered pages or expensive queries in memory

3. Put a CDN in front of the site

A Content Delivery Network serves files from servers close to each visitor and absorbs traffic spikes. Cloudflare’s free plan is a quick start; most CDNs can also cache full HTML pages, which can cut response times dramatically for global audiences.

4. Optimise images

Images are usually the heaviest part of a page.

• Resize to the displayed size
• Convert to WebP or AVIF
• Compress (quality around 75–85%)
• Use srcset so phones get smaller files
• Set width and height to prevent layout shift

5. Lazy-load below-the-fold media

Add loading="lazy" to images and iframes that are not visible on first load – but not to the main hero image, which should load as early as possible.

6. Enable compression

Text files (HTML, CSS, JavaScript, SVG, JSON) shrink by 70–80% with Gzip and a little more with Brotli. It is often a single server setting – on cPanel, look for “Optimize Website”.

7. Set long browser cache lifetimes for static files

Returning visitors should not re-download your logo, CSS and JavaScript on every page. Set Cache-Control: max-age=31536000, immutable for versioned static files (files with a version or hash in the name), so a new version gets a new URL.

8. Remove unused JavaScript

JavaScript is the most expensive resource byte for byte: it must be downloaded, parsed, compiled and executed, often on slow phone processors. Review what each script does. Old analytics tags, unused sliders, abandoned A/B tests and libraries loaded on every page for one feature add up quickly.

9. Defer non-critical scripts

Scripts in the <head> without async or defer block the page from rendering until they download and run. Add defer to scripts that are not needed for the first paint, or move them to the end of the body.

<script src="/js/app.js" defer></script>

10. Be ruthless with third-party scripts

Chat widgets, social embeds, heatmaps, tag managers full of marketing pixels and ad scripts can easily account for most of a page’s JavaScript. For each one, ask whether it earns its cost. Load non-essential widgets only after user interaction (for example, load the chat widget when someone clicks the chat button).

11. Optimise web fonts

• Use fewer font families and weights
• Serve WOFF2 files, ideally self-hosted
• Preload the one or two most important font files
• Use font-display: swap so text is visible immediately
• Consider a system font stack for body text

12. Minify CSS and JavaScript

Minification strips whitespace and comments. Build tools, caching plugins and CDNs can do it automatically.

13. Inline critical CSS

The CSS needed to render the first screen can be placed directly in the <head>, with the rest loaded without blocking. Many caching plugins can generate critical CSS for you.

14. Reduce redirects

Each redirect adds a full round trip before the page even starts loading. Link directly to final URLs, and make sure your preferred version (https, www or not) is reached in one hop.

15. Keep the database and platform lean

On WordPress, deactivate and delete plugins you do not need, clean up post revisions and expired transients, and keep PHP, WordPress and plugins up to date. Every plugin adds code that may run on every request.

Where to start

If you only do three things, do these:

1. Fix server response with caching, a CDN or better hosting
2. Optimise images and serve modern formats
3. Cut and defer JavaScript, especially third-party scripts

These three usually account for the bulk of the improvement on most sites.

Measure the right things

Use lab tools (Lighthouse, PageSpeed Insights) to diagnose and test changes, and field data (Search Console’s Core Web Vitals report, the Chrome UX Report) to see what real visitors experience. Test on mobile – that is where most performance problems show.

Speeding up a site on cPanel shared hosting

Many sites run on cPanel shared hosting. Useful options are often already there:

• PHP version (MultiPHP Manager or Select PHP Version): run a current, supported PHP version – newer versions are significantly faster
• Optimize Website: enable compression for text files
• LiteSpeed Cache: if your host uses LiteSpeed, its cache plugin for WordPress is very effective
• Cloudflare: many cPanel hosts offer one-click Cloudflare integration
• Resource usage: if your account regularly hits CPU or memory limits, the server will slow down under load – consider a larger plan or a VPS

A 30-minute speed audit

If you have half an hour, this routine finds most of the big problems:

1. Run a mobile speed test on your homepage and your most visited landing page
2. Note the Time to First Byte. Over 800 ms? Start with caching and hosting.
3. Identify the LCP element. Is it an image? Check its size, format and whether it is lazy-loaded.
4. Look at the list of third-party scripts. Remove anything you do not actively use.
5. Check total page weight and the five largest files.
6. Test the same page again after each fix.

Performance budgets

Once your site is fast, keep it fast by setting a performance budget – limits your team agrees not to exceed, for example:

• Total page weight under 1.5 MB on key templates
• JavaScript under 300 KB compressed
• LCP under 2.5 seconds on a mid-range phone
• No more than five third-party scripts

Check new features and marketing tags against the budget before they go live. It is much easier to keep a site fast than to make a slow site fast again.

When to call in a developer

Some problems need code changes: render-blocking scripts in the theme, very large JavaScript bundles, layout shifts caused by dynamic content, and slow database queries. If you are working with a developer, share the specific metrics, the affected templates and the diagnostic details from your speed test – it saves a lot of time.

Key takeaways

• Fix server response time first with good hosting, page caching and a CDN.
• Optimised images – resized, compressed and in modern formats – are usually the biggest front-end win.
• Remove and defer JavaScript, and question every third-party script.
• Enable compression and long browser cache lifetimes for static files.
• Test on mobile, measure before and after each change, and set a performance budget.
• On cPanel, check your PHP version, compression settings and caching options first.

Frequently asked questions

What is a good page load time?

Aim for the main content to appear within 2.5 seconds (good Largest Contentful Paint) for most real visitors, and for the page to respond to taps within 200 ms.

Will a faster site rank higher?

Speed is one of many ranking signals and rarely the deciding one, but it can help between similar pages – and it reliably improves user experience and conversions.

Do I need a developer to speed up my site?

Many improvements – caching, a CDN, image optimisation, removing plugins – can be done without code. JavaScript and template changes may need a developer.

Is AMP still necessary?

No. Google no longer requires AMP for Top Stories, and a well-optimised normal page delivers the same benefits.