Site loading like it’s 2003? Visitors bouncing before your hero image even shows? A slow site speed kills conversions, SEO rankings, and visitor patience — but here’s the good news: most slow site speed problems aren’t your hosting. They’re things you can fix in an afternoon. This guide is a deep dive into every non-hosting cause of slow website speed, with concrete fixes for both WordPress and static HTML sites on PBN LTD.
We’ll cover heavy images, JavaScript bloat, render-blocking CSS, slow plugins, page-builder overhead, fonts, video embeds, caching, database bloat, redirect chains, third-party scripts, and the diagnostic tools that tell you exactly what’s slow and why. Whether you’re staring at a Google PageSpeed Insights score of 23 or just wondering why your site “feels” sluggish, you’ll find your fix below.
💡 Heads-up: this guide focuses on non-hosting causes of slow site speed — the stuff you can fix yourself without touching servers. PBN LTD already gives your site fast NVMe storage, a global CDN, and modern protocols out of the box, so hosting itself is rarely the bottleneck.
📁 Quick vocab (don’t skip this — these terms come up everywhere):
- TTFB (Time To First Byte) — how long the server takes to start responding. Anything under 600ms is fine.
- LCP (Largest Contentful Paint) — when the biggest thing on the page finishes loading. Aim for under 2.5 seconds.
- CLS (Cumulative Layout Shift) — how much the page jumps around as it loads. Aim for under 0.1.
- INP (Interaction to Next Paint) — how quickly the page responds when you click. Aim for under 200ms.
- Render-blocking — a CSS or JS file the browser has to download and run before it can show anything. Big slowdown factor.
- Lazy load — only loading an image/iframe when the visitor scrolls near it, instead of all upfront.
- Defer / Async — telling the browser “this script isn’t urgent, load it after the page is visible.”
- Minify — strip whitespace, comments and unused chars from CSS/JS files to make them smaller.
- WebP / AVIF — modern image formats that are 25–50% smaller than JPG/PNG at the same quality.
- CDN (Content Delivery Network) — a network of edge servers that caches your site at locations worldwide for faster delivery. Every PBN LTD site is on a CDN by default.
- Page cache — saving a fully-rendered HTML copy of a page so WordPress doesn’t have to rebuild it from PHP+MySQL on every request.
- Core Web Vitals — Google’s official speed/UX metrics: LCP, CLS, INP. Affect your SEO rankings.
📑 What’s in this guide
- 🧰 Step 1 — Measure your slow site speed (don’t guess)
- ⚡ 60-second slow site speed quick-win checklist
- 🖼️ Heavy or unoptimised images (biggest win for most sites)
- 🎨 CSS bloat & render-blocking stylesheets
- ⚙️ JavaScript bloat & third-party scripts
- 🔌 Too many (or slow) WordPress plugins
- 🎭 Heavy WordPress theme
- 🧱 Page builder overhead (Elementor, Divi, etc.)
- 🎬 Video & YouTube embeds
- 🔤 Web fonts (especially Google Fonts)
- 📦 Caching — the single biggest WordPress speed win
- 🗄️ Database bloat (WordPress)
- 🔁 Redirect chains
- ❌ 404s and missing files
- 📱 Mobile-specific slowness
- 🛠️ Tools for diagnosing slow site speed
- ❓ FAQs
- ✅ Quick summary
🧰 Step 1 — Measure your slow site speed (don’t guess)
Before changing anything, measure. You can’t fix what you can’t see, and “it feels slow” isn’t data. Three free tools will tell you exactly what’s slow and why:
| Tool | Strengths | When to use |
|---|---|---|
| PageSpeed Insights | Free, official Google, Core Web Vitals data | Always — this is the one Google ranks you on |
| GTmetrix | Free + paid tiers, video playback, regions | Detailed waterfall + real visual playback |
| WebPageTest | Free, advanced, multi-location, throttling | When you need deep diagnostic detail |
How to read your speed report
All three tools give you a score out of 100, plus a breakdown of what’s slow and what’s slowing it. Don’t obsess over the score — focus on the opportunities and diagnostics sections. That’s where the real fixes are.
💡 What the metrics actually mean: Google cares about LCP, CLS and INP (the Core Web Vitals). PSI grades you on those directly. GTmetrix gives you LCP/CLS plus its own Performance and Structure scores. WebPageTest gives you a waterfall chart that visually shows every file load — incredibly useful for spotting render-blocking and slow third-party scripts.
Test methodology that won’t lie to you
- Test in incognito. Browser extensions can wildly distort your scores (ad-blockers especially).
- Run each test 3 times and use the median. First runs are cold-cache and look much worse than reality.
- Test both mobile and desktop. Google ranks on mobile speed primarily.
- Test multiple pages — homepage, blog post, product page. Each loads different assets.
- Test from your actual audience’s region in GTmetrix (settings → location).
⚡ 60-second slow site speed quick-win checklist
Before diving deep, run through these quick wins. They fix 80% of slow site speed problems in under an hour:
- Open your homepage in PageSpeed Insights. Note your LCP and biggest “opportunities”.
- Is your biggest image over 500 KB? Compress it (huge win, see Images section).
- Are you using WordPress with no page-cache plugin? Install one (massive win, see Caching section).
- Do you have more than 30 active plugins? Audit and trim.
- Is your homepage hero a YouTube embed or auto-playing video? Replace with a poster image + click-to-play.
- Is your theme a heavy multipurpose theme (Avada, BeTheme, X, The7)? Test against a lightweight one.
- Have you purged the CDN cache after your last change?
- Are you loading Google Fonts directly from Google instead of self-hosting?
🖼️ Heavy or unoptimised images (biggest win for most sites)
If your site is slow, images are almost certainly the biggest culprit. On the average website, images make up 50–70% of total page weight. A single uncompressed iPhone photo can be 8 MB. Drop 12 of those on a page and you’ve got a 96 MB site — guaranteed to feel slow even on great hosting.
The classic image mistakes (we see these every week)
| What you uploaded | Why it kills speed | What to do instead |
|---|---|---|
| A 4032×3024 iPhone photo | Displayed at 600×400 — wasting 95% of pixels | Resize to 1200×800 max before upload |
| 8 MB JPG hero image | Single biggest file on the page | Compress to under 200 KB, convert to WebP |
| PNG of a photo | PNG is for graphics; photos balloon to 5–10× JPG size | Use JPG or WebP for photographic content |
| Logo as 2000×2000 PNG | Logos should be vector (SVG) | Export as SVG — tiny file, sharp at any size |
| 25 product images, none lazy-loaded | All load even if visitor never scrolls down | Use loading="lazy" on below-the-fold images |
The image optimisation checklist
- Resize before upload. If it displays at 800px wide, don’t upload it at 4000px. Use any image editor or a free site like Squoosh.
- Compress. Use TinyPNG or Squoosh to drop file size 60–80% with no visible quality loss.
- Use the right format. Photos → WebP or JPG. Logos / line art → SVG or PNG. Modern WebP is 25–35% smaller than JPG.
- Lazy load below-the-fold images. WordPress does this automatically since 5.5. Static HTML: add
loading="lazy"to your<img>tags. - Don’t lazy-load your hero image. It’s above the fold — it needs to load immediately. Add
fetchpriority="high"to your LCP image. - Add width and height attributes to every image. Prevents layout shift (CLS).
- Use srcset so phones download a small version and desktops download a big version of the same image.
WordPress image plugins (set and forget)
Don’t want to compress images one-by-one before upload? Install one of these and they’ll do it automatically as you upload — and even convert existing images to WebP:
- ShortPixel — excellent free tier, converts to WebP/AVIF, our top pick.
- Imagify — by the WP Rocket team, simple UI, great results.
- Smush — popular, free for basic compression.
- EWWW Image Optimizer — runs locally on your server, no external API.
⚠️ Warning: some image plugins offer “bulk compress” that processes every image on your site. Always take a backup first via Site Functions → Create backup. Compression is lossy and can’t be undone, so backup means you can always revert.
🎨 CSS bloat & render-blocking stylesheets
Every CSS file the browser sees is render-blocking by default — it has to download and parse them all before it can show anything on the screen. If your site loads 18 CSS files totaling 800 KB before the first pixel paints, your slow site speed is solved here.
What slows you down
- Multiple stylesheets. Each plugin and theme loading its own CSS adds an HTTP request and parse time.
- Unused CSS. Most themes ship with rules for components you never use. Often 70%+ of your CSS is unused on any given page.
- Unminified CSS. Indentation, comments, and whitespace make the file 30–50% bigger than it needs to be.
- External CSS (Google Fonts, Font Awesome from a CDN) — adds DNS lookup, TLS handshake, and external dependency.
How to fix CSS bloat (WordPress)
- Install a caching/optimisation plugin like WP Rocket, LiteSpeed Cache, Autoptimize, or FlyingPress.
- Turn on “Minify CSS” and “Combine CSS” (test carefully — combine can break some themes).
- Turn on “Remove Unused CSS” — usually the single biggest CSS win. WP Rocket and Perfmatters do this brilliantly.
- Test each setting one at a time. If something breaks visually, turn that setting off and move on.
- Clear the page cache and re-test in PageSpeed Insights.
How to fix CSS bloat (static HTML)
- Minify your CSS with a tool like CSS Minifier before uploading.
- Combine multiple stylesheets into one file where it makes sense.
- Inline critical CSS (the styles for above-the-fold content) directly in the
<head>and load the rest asynchronously. - Use the
mediaattribute to defer non-critical CSS — e.g.<link rel="stylesheet" href="print.css" media="print">will only load for printing.
💡 How to find render-blocking CSS: in PageSpeed Insights, look for the “Eliminate render-blocking resources” opportunity. It lists every file blocking your render and how much time you’d save.
⚙️ JavaScript bloat & third-party scripts
JavaScript is the #2 cause of slow site speed after images. Every script the browser has to download, parse, compile and execute steals time from rendering. Third-party scripts (analytics, chat widgets, ad tags, A/B testing tools) are particularly nasty because you don’t control them — they can slow down on the third party’s end and there’s nothing you can do.
The worst third-party-script offenders
| Script type | Typical weight | Mitigation |
|---|---|---|
| Google Analytics / GA4 / GTM | 50–100 KB + ongoing CPU | Defer; consider lighter alternative (Plausible, Fathom) |
| Facebook Pixel | 60–100 KB | Defer; only load on conversion pages if possible |
| Chat widgets (Intercom, Drift, Tawk) | 200–500 KB + multiple iframes | Lazy-load on first interaction or below-the-fold |
| Ad networks (AdSense, Taboola) | 300 KB–1 MB+ per script | Limit to high-value pages; lazy-load below fold |
| A/B testing (Optimizely, VWO) | 50–200 KB + render-blocking | Use server-side variants where possible |
| Social embeds (Twitter, Instagram) | 100–300 KB each | Replace with screenshots + links |
How to fix JavaScript slowness
- Audit ruthlessly. List every third-party script on your site. Do you actually use it? If not — remove it.
- Defer non-critical JS. Use a plugin (WP Rocket, Perfmatters, FlyingPress) or add
deferattribute manually. This tells the browser “load this after the page is visible.” - Delay execution until interaction. Tools like WP Rocket and Perfmatters can hold non-essential scripts until the user moves their mouse or scrolls. Massive PageSpeed boost.
- Lazy-load embeds. Chat widgets, social feeds, and YouTube embeds can wait until they’re scrolled into view.
- Self-host where possible. Analytics scripts and fonts loaded from your own domain are faster than external ones (no extra DNS lookup or TLS handshake).
- Consider lighter alternatives. Plausible or Fathom instead of GA4. Plain <mailto:> link instead of a chat widget on low-traffic pages.
💡 The “delay JS until interaction” trick is the single biggest PageSpeed boost most WordPress sites can get. It can take a mobile score from 40 to 95+ without breaking anything. WP Rocket calls it “Delay JavaScript Execution”; Perfmatters calls it “Script Delay”. Worth installing one of those just for this feature.
🔌 Too many (or slow) WordPress plugins
The plugin count itself isn’t the issue — it’s the type of plugin. 40 well-coded plugins are fine. 5 badly-coded plugins can wreck your slow site speed. The classic offenders: page builders, slider plugins, social-share widgets, security plugins, contact forms loading on every page, and anything that adds a database query to every page load.
How to find which plugins are slowing your site
- Install the free Query Monitor plugin.
- Visit a slow page on your site while logged in as admin.
- In the admin bar, click the Query Monitor entry → Queries by Component.
- You’ll see exactly which plugins are running queries and how long each takes.
- The slow ones are your suspects. Try deactivating them one at a time and re-running PageSpeed Insights.
For systematic conflict-finding (when a plugin is breaking your site, not just slowing it), see our WordPress plugin and theme conflict guide and Health Check plugin guide.
The plugin audit (do this quarterly)
- Open Plugins → Installed Plugins in WP-Admin.
- For each plugin, ask: “do I actually use this? When did I last benefit from it?”
- Deactivate and delete anything you can’t justify. Deactivated-but-installed plugins still exist on disk and can be a security risk.
- Look for plugin overlaps — e.g. two SEO plugins, three image optimisers, multiple caching plugins (which actively fight each other).
- Check the WordPress.org plugin page for each. Last update over 2 years ago? Consider replacing.
Known-slow plugin categories
| Plugin category | Why they hurt | Lighter alternative |
|---|---|---|
| Page builders | Extra CSS/JS on every page | Use native Gutenberg blocks where possible |
| Slider plugins (Revolution, Slider Pro) | Heavy JS, often render-blocking | Static hero image or single CSS slide |
| Social share buttons | Load scripts from every platform | Lightweight: Grow.me, Scriptless Social Sharing |
| Security plugins (Wordfence, iThemes) | Run on every request | Built-in CDN WAF on PBN LTD + a lean plugin |
| Related posts plugins | Expensive DB queries on every post | Cache-friendly alternatives like Contextual Related Posts |
| Contact form plugins loading globally | CSS/JS on every page | Forms with conditional asset loading (Fluent Forms, WPForms) |
| Stats plugins (Jetpack Stats, etc) | Pings to external server on every load | Use analytics in a tag manager, deferred |
⚠️ Always back up before bulk deactivating. Site Functions → Create backup in your PBN LTD dashboard. Some plugins store data that disappears if uninstalled — back up first so you can restore in seconds if needed.
🎭 Heavy WordPress theme
Some themes ship with the kitchen sink: 12 sliders, 30 page-builder blocks, 5 megamenus, animation libraries, icon fonts you’ll never use. Each loads CSS and JS on every page whether you use it or not. Result: slow site speed even on a near-empty homepage.
Notoriously heavy themes
These multipurpose themes are popular but heavy: Avada, BeTheme, X / Pro, The7, Bridge, Newspaper, Total, Enfold, Salient. They can be tuned, but it’s an uphill battle. Worth testing against a lightweight theme.
Lightweight alternatives
- GeneratePress — modular, fast, page-builder friendly.
- Kadence — modern, fast, great free version.
- Astra — popular, well-optimised, works with most builders.
- Blocksy — newer, very fast, lots of features.
- Twenty Twenty-Four / Five — WordPress’s own default themes are now genuinely good and incredibly fast.
The theme speed test
- Back up first via Site Functions → Create backup.
- Take a baseline PageSpeed Insights score with your current theme.
- Temporarily switch to Twenty Twenty-Five (Appearance → Themes).
- Re-run PageSpeed Insights. Big jump? Your theme is the bottleneck.
- Switch back to your original theme afterwards — the test is purely for diagnostic purposes.
🧱 Page builder overhead (Elementor, Divi, etc.)
Page builders like Elementor, Divi, WPBakery and Beaver Builder are amazing for non-coders, but they all add overhead — extra CSS, JS, DOM nesting, and inline styles. A page built with the native Gutenberg block editor will almost always be faster than the same page in Elementor. That doesn’t mean don’t use a builder — it means know the tradeoff and tune it.
Page builder speed tips
- Turn off unused features in the builder’s performance settings. Elementor has “Experiments” → enable Optimized DOM Output, Improved Asset Loading, Improved CSS Loading.
- Disable Font Awesome / icon libraries you don’t use.
- Disable Google Fonts in the builder and self-host them.
- Avoid stacking page-builder addon plugins (Premium Addons, Ultimate Addons, etc) — each adds its own CSS/JS.
- For mostly-static pages (landing pages, blog posts), consider rebuilding in the native block editor and free up the builder’s overhead.
- Pair with WP Rocket or FlyingPress — they have specific Elementor / Divi optimisations.
🎬 Video & YouTube embeds
A single embedded YouTube video can add 500 KB+ and 8 extra requests to your page — before the visitor even hits play. Multiple embeds on the same page can absolutely tank your slow site speed and Core Web Vitals.
The fix: lazy-load embeds
- Replace YouTube embeds with a poster image + click-to-play. The video only loads when the visitor actually wants to watch it.
- WordPress: plugins like WP YouTube Lyte, Lazy Load for Videos, or built-in features in WP Rocket / Perfmatters.
- Static HTML: use the lite-youtube-embed custom element — same look, fraction of the weight.
- Never auto-play hero videos. They’re the #1 LCP killer. Use a static hero image instead.
- Video isn’t optimised for video streaming. Use a dedicated video host like YouTube or Vimeo and embed the player on your page.
🔤 Web fonts (especially Google Fonts)
Fonts seem innocent but they’re a sneaky cause of slow site speed. Each custom font weight is a separate file download. Each request to fonts.googleapis.com is an extra DNS lookup, TLS handshake, and HTTP request. And fonts are render-blocking — the browser delays showing text until they’re ready (the dreaded FOIT — Flash Of Invisible Text).
Font speed checklist
- Use no more than 2 font families across your whole site. One for headings, one for body. More than that and you’re loading bloat.
- Use no more than 3 weights per family. Regular, bold, maybe italic. Skip light-300 and black-900 unless you really need them.
- Self-host fonts instead of loading from Google. WP Rocket, OMGF, and Perfmatters do this automatically. Static HTML: download the woff2 files and host them on your site.
- Use
font-display: swapin your CSS. Means text shows in a fallback font immediately, then swaps when the custom font is ready. No more invisible text. - Preload your main font with
<link rel="preload" as="font" type="font/woff2" crossorigin>so the browser fetches it earlier. - Use woff2 format only. It’s smaller than woff and supported by every modern browser.
💡 GDPR bonus: self-hosting Google Fonts also dodges a GDPR issue. German courts have ruled that loading Google Fonts directly leaks visitor IPs to Google without consent. Self-hosting fixes both speed and compliance.
📦 Caching — the single biggest WordPress speed win
Without caching, WordPress runs PHP and queries MySQL on every single page load, for every visitor. That’s wasteful and slow. With page caching, WordPress builds the page once, saves the HTML, and serves that static HTML to subsequent visitors — often 10× faster.
If your WordPress slow site speed has one root cause, it’s usually “no page cache installed”. Fixing this alone can take a 6-second load time to under 1 second.
Types of caching (you need most of these)
| Cache type | What it does | Where it lives |
|---|---|---|
| Page cache | Stores fully-rendered HTML so PHP/MySQL is skipped | WordPress (via caching plugin) |
| Object cache | Stores DB query results in memory | WordPress (Redis / Memcached) |
| Browser cache | Visitor’s browser keeps assets locally | Visitor’s computer |
| CDN cache | Static assets cached at edge locations worldwide | CDN (automatic on PBN LTD) |
| OPcache | Caches compiled PHP bytecode | Server (already enabled on PBN LTD) |
Recommended caching plugins
- WP Rocket (paid) — best all-rounder. Page cache + minify + lazy-load + delay JS + remove unused CSS, all in one. Set-and-forget for non-techies.
- FlyingPress (paid) — newer, very fast, focuses on Core Web Vitals.
- LiteSpeed Cache (free) — excellent free option; some features need LiteSpeed server (not used at PBN LTD), but page caching works anywhere.
- W3 Total Cache (free) — powerful, configurable, but steep learning curve.
- WP Super Cache (free) — simple page caching from Automattic. Good if you want minimal config.
- Cache Enabler (free) — lightweight, works well alongside Autoptimize.
⚠️ Never install two page-caching plugins. They fight each other, cause cache poisoning, and can break your site. One caching plugin only.
Cache-busting after changes
Made a change but it’s not showing? You’ve got three layers of cache to clear:
- WordPress page cache — your caching plugin has a “Clear Cache” button in the admin bar.
- CDN cache — in your PBN LTD dashboard: Site Functions → Purge CDN cache.
- Your browser cache — test in an incognito window to bypass it entirely.
🗄️ Database bloat (WordPress)
Over months and years, WordPress databases accumulate junk: thousands of post revisions, expired transients, spam comments, orphaned options, draft auto-saves. A bloated database means slower queries, which means a slower page generation, which means slow site speed.
The big database offenders
- Post revisions — every time you save a draft, WordPress keeps the old version. Years of edits = hundreds of revisions per post.
- Auto-drafts and trashed posts — still sitting in
wp_posts. - Expired transients — temporary cached data that’s gone stale.
- Autoloaded options — settings loaded on every page request. Some plugins dump huge data here.
- Spam and trashed comments — can be tens of thousands of rows on older sites.
- Orphaned post meta — leftover data from deleted posts or uninstalled plugins.
How to clean up safely
- Take a backup first. Site Functions → Create backup. Non-negotiable.
- Install WP-Optimize or Advanced Database Cleaner.
- Run the cleanup with the default safe options first (revisions, transients, spam, trash).
- Don’t touch “orphaned post meta” or “drop tables” unless you really know what you’re doing.
- Limit future revisions in WP-Optimize → Settings (set a maximum number of revisions to keep, e.g. 5). Much safer than editing files.
⚠️ Warning: database cleanup is irreversible. If WP-Optimize deletes something you needed, only your backup can save you. Always backup first. Use the dashboard backup, not the WP-Optimize backup — dashboard backups are full-server snapshots.
🔁 Redirect chains
Each redirect adds a round-trip to your TTFB. One redirect is fine. Two is okay. Five is a chain and your slow site speed is partly caused by it. Worst case: an infinite loop = browser error. See Error: Too Many Redirects for that.
Common redirect-chain patterns
http://yoursite.com→https://yoursite.com→https://www.yoursite.com→https://www.yoursite.com/(trailing slash) → final page. 4 redirects.- Old URL → new URL → another new URL → newer URL. Layers of historical redirects in a single hop.
- Redirect plugin and
.htaccessredirects both firing for the same URL.
How to find them
- Use httpstatus.io — paste your URL, see every redirect hop.
- Chrome DevTools → Network tab → look for 301/302/307/308 status codes.
- Screaming Frog (free for under 500 URLs) — crawls your whole site, flags redirect chains.
For how to set up clean single-hop redirects properly, see How to 301 Redirect (WordPress & Static HTML).
❌ 404s and missing files
Every missing file the browser requests still costs time — DNS lookup, TCP handshake, HTTP request, server response (just to return a 404). Multiply by a few dozen broken assets and you’ve got a measurable contribution to slow site speed.
How to find broken assets
- Open your page → right-click → Inspect → Network tab.
- Reload the page. Any rows in red with status 404 are missing.
- Common causes: deactivated plugin left orphan references, theme uninstalled but template files still loading, image filename changed but HTML not updated.
For full 404 troubleshooting on static HTML, see Fixing 404 Errors on Inner Pages. For broader static HTML troubleshooting, see Static HTML Troubleshooting.
📱 Mobile-specific slowness
Your site might score 95 on desktop and 38 on mobile. That’s normal — but the mobile score is the one Google ranks you on. Mobile is harder because phones have weaker CPUs, slower networks, and smaller viewports.
Mobile-only speed fixes
- Serve smaller images on mobile via
srcsetandsizesattributes. A phone shouldn’t download a 2000px desktop image. - Skip animations on mobile. Heavy CSS animations and parallax effects are CPU-killers on phones.
- Don’t show desktop megamenus on mobile. Use a simple hamburger that hides DOM until tapped.
- Lazy-load aggressively on mobile. Most below-the-fold content can wait.
- Test on a real mid-range Android, not your flagship iPhone. Real-world performance varies wildly.
🛠️ Tools for diagnosing slow site speed
| Tool | What it tells you | Cost |
|---|---|---|
| PageSpeed Insights | Core Web Vitals + opportunities | Free |
| GTmetrix | Waterfall + performance grades | Free + paid |
| WebPageTest | Advanced multi-location, network throttling | Free |
| Chrome DevTools (Lighthouse) | Same audit as PSI, run locally on any page | Free, built-in |
| Query Monitor (WordPress plugin) | Slow queries, plugin-by-plugin profiling | Free |
| New Relic / Blackfire | Server-side PHP profiling | Paid, advanced |
❓ Slow site speed FAQs
What’s a “good” PageSpeed Insights score?
90+ is excellent, 50–89 is “needs improvement”, below 50 is poor. But the score itself is less important than your Core Web Vitals (LCP, CLS, INP) — those are what Google actually ranks on. Aim for green on all three rather than chasing a perfect 100.
My site is slow but PBN LTD’s status shows OK. Is it the hosting?
Almost certainly not. PBN LTD uses fast NVMe storage and a global CDN — TTFB is typically under 300ms. If your overall page load is 6 seconds, the other 5.7s is on the page itself. Work through this guide — images, JS, plugins — before suspecting the server.
How many plugins is “too many”?
It’s the quality not the count. 50 lightweight, well-coded plugins can be fine. 5 page-builder addons can wreck your site. Audit by what each plugin does on every page load — see the Plugin section above for using Query Monitor.
Should I use a caching plugin on a static HTML site?
Static HTML is already cached at the server and CDN level — there’s no PHP rendering to cache. So no, you don’t need a “caching plugin”. After file changes, just purge the CDN cache from your PBN LTD dashboard (Site Functions → Purge CDN cache) and test in incognito.
Does upgrading from PHP 7.4 to PHP 8.x make my site faster?
Yes — PHP 8 is roughly 2× faster than PHP 7.4. PBN LTD sites run modern PHP by default, so you’re already on the fast end. If you’re on an older PHP version for compatibility reasons, plan to upgrade your plugins/theme so you can move forward.
My LCP image is huge. How do I fix it?
(LCP = Largest Contentful Paint, usually your hero image.) Three things: compress it (TinyPNG or Squoosh), resize it to the actual displayed size, and add fetchpriority="high" to the <img> tag. Don’t lazy-load it. These changes alone often take LCP from 4s+ to under 2s.
Why is CLS so bad on my site?
CLS (Cumulative Layout Shift) is when stuff jumps around as the page loads. Main culprits: images without width and height attributes, late-loading web fonts, ads or embeds resizing after load. Always specify image dimensions, use font-display: swap, and reserve space for dynamic content.
Do I really need a paid caching plugin like WP Rocket?
No — free plugins like LiteSpeed Cache, W3 Total Cache, and WP Super Cache can get you most of the way. WP Rocket and FlyingPress are popular because they bundle everything (page cache + minify + delay JS + remove unused CSS + lazy load) in one click. If your time is worth more than the licence cost, they’re worth it. Otherwise, free options are excellent.
My site is fast for me but visitors say it’s slow. Why?
Three likely reasons: (1) your browser cache is making it feel fast for you, (2) you’re geographically closer to the CDN edge than they are, (3) you’re testing on better hardware and faster internet. Test in incognito, on a mobile network (3G throttling in Chrome DevTools), and from a different location (use webpagetest.org).
✅ Quick summary
- Measure first. Use PageSpeed Insights, GTmetrix or WebPageTest. Don’t guess.
- Images first. Compress, resize, modern format, lazy-load. Biggest win for most sites.
- Install a caching plugin on WordPress. Single biggest WP speed win.
- Defer or delay JavaScript — especially third-party scripts.
- Audit plugins. Remove what you don’t use. Replace heavy with light.
- Replace heavy themes with lightweight alternatives (GeneratePress, Kadence, Astra).
- Self-host fonts, limit weights, use
font-display: swap. - Lazy-load YouTube embeds. Never auto-play hero videos.
- Clean your database quarterly with WP-Optimize.
- Fix redirect chains — every hop adds latency.
- Purge CDN cache after every change. Test in incognito.