why is my wordpress site slow
what an external browser sees when your wordpress homepage takes too long to render — and the four things that are almost always behind it.
wordpress is the cms most small business sites are on, and it gets slow for predictable reasons. the platform itself is not the problem — defaults are. a fresh install loads fast. by the time a site is two years old it is usually carrying three caching plugins fighting each other, a page builder that ships an entire framework per page, and a theme that loads eight font weights for one h1. a public browser check cannot tell you which plugin is at fault from outside, but it can tell you with certainty whether the slowness is render-blocking css/js, oversize images, or third-party widgets — and that narrows the fix to a couple of obvious moves.
what this looks like to a visitor
- page takes more than 4 seconds to show content on a normal connection
- first paint is fast but text only appears after a long blank flash
- mobile feels much slower than desktop
- google search console reports core web vitals failure
what a public browser check can see
we open your domain in a real headless browser, measure how long until the page is visible and interactive. no plugin needed, no admin login.
render-blocking css and javascript in the head, large hero images served without responsive variants, third-party widgets (chat, analytics, ad tags) that block the main thread.
images served as 2 mb png instead of compressed webp, fonts loaded without preconnect, css and js not minified or gzipped. these are the usual wordpress defaults.
missing cache plugin or one with default settings, page builders that bundle the full template per page, themes that load eight font weights.
we do not log into your site. we do not scrape customer data. we open your public homepage in a real browser session and report what we see. no security claims unless we can prove them from the public surface.
the deeper picture
the four common patterns: (1) caching is misconfigured. you have a cache plugin but page cache is off, or it is on but the cdn is bypassing it. (2) image weight. a single hero png at 2.4 mb will dominate first paint on mobile. wordpress media library serves the original file unless you explicitly enable a responsive image plugin or convert to webp. (3) third-party widgets. chat boxes, exit-intent popups, mailchimp embeds, an analytics tag from a tool you stopped using last year. each is a script tag, each delays interactivity. (4) the theme itself. some commercial themes load the full framework on every page even when you only use one block. the public check will surface the slow time-to-interactive but cannot tell which culprit dominates without seeing the page source — that is what the deep audit is for.
fix it yourself
install a basic cache plugin (w3 total cache, wp super cache, or litespeed cache if your host runs litespeed). enable page cache + browser cache. add a cdn (cloudflare free tier is enough for most sites). convert hero images to webp. disable any unused page builder modules and plugins. test again from a fresh incognito window.
run the audit on YOUR site — check for "why is my wordpress site slow"
we open your homepage in a real headless browser and report what we see. no login, no plugin install.
public browser check · no signup · result on the next page
or pay us once.
if you fix it yourself, you will not need us. the self-fix list below works for most sites and costs nothing. if you have tried the self-fix and the site is still slow, or if you do not want to learn what a page cache is, the $149 emergency fix is the path: we go in, fix what is actually slow, ship before/after numbers, done in two days.
frequently asked
yes, but indirectly. core web vitals are a tiebreaker — they matter when content quality is equal. fixing speed mainly helps because slow pages lose visitors before they convert.
cloudflare free tier is usually enough. it sits in front of your site and serves static assets from a location closer to the visitor. you do not need a paid cdn unless you have international traffic in the millions.
we see the response headers and ip range, so usually yes. it does not change the diagnosis — the same fixes work on any host. it does change the self-fix path because litespeed hosts pair with litespeed cache and others do not.
this is common. it usually means the original optimisation got undone by a plugin update or a new third-party widget. the deep audit ($49) tells you exactly what changed, then either you re-run the original optimisation or we do it for $149.
other fix guides
- shopify checkout feels broken — how to find out why— a public browser check of your shopify storefront can surface the visible reasons people abandon. here is what we look for.
- contact form looks fine but i'm not getting emails— this is the most common silent failure mode of small-business websites. four reasons it usually is — and how a public check can rule out the wrong ones.
- wix site not showing on google — what a public check can tell you— your wix site exists, but it does not appear in google search results. four reasons that explain almost every case.
- squarespace site loads slowly on mobile— squarespace is well-built but slow by default on phones because of the way it serves images and fonts. four moves usually fix it.
built by vøiddo — a small studio shipping ai-flavoured products, free dev tools, chrome extensions and weird browser games. legal · support@voiddo.com