Why your SaaS WordPress site is slow (and the 5 fixes that matter)

Almost every slow WordPress site I am asked to look at is slow for one of five reasons. Not fifty. Five. The reason it feels like fifty is that most performance advice is a checklist of everything that can theoretically matter, sorted by nothing in particular.

Here is the shorter version, in the order I actually check.

First, stop trusting the feeling

"The site feels slow" almost never points at the thing costing you signups. It usually means the page took a long time to become useful, which is a different measurement from the one most tools lead with.

Open Chrome DevTools, go to the Network tab, and reload with the cache disabled. Two numbers matter before anything else:

• Time to first byte. How long the server took to start answering. Anything past 600ms is a server problem, not a front end one.
• Total transferred. How many kilobytes the page pulled to render what you see.

If TTFB is bad, skip to fix five. Everything else on this list is wasted effort until the server stops being the bottleneck.

Fix 1: your page builder is shipping a framework to render a heading

This is the big one, and it is uncomfortable because the page builder is usually the reason the marketing team can ship a page at all.

Open the page source and look at a single section heading. On a builder-heavy page you will typically find it wrapped in four or five nested div elements, each carrying generated class names, plus a stylesheet and a JavaScript bundle loaded to support widgets that page may not even use.

The cost shows up in three places: more CSS to parse before anything paints, more DOM nodes for the browser to lay out, and JavaScript that competes with everything else for the main thread.

How to confirm it: disable the builder's assets on one page and compare. If the page loses 400kb and a second of load time, you have your answer.

What to do: you do not have to rip the builder out on Monday. Rebuild the templates that matter first, which is almost always the homepage, the pricing page and whichever landing page your ads point at. Leave the long tail alone.

Fix 2: every plugin loads on every page

WordPress plugins enqueue their CSS and JavaScript globally by default, because a plugin author cannot know which page you will use their shortcode on. So a contact form plugin used on one page loads its assets on all two hundred.

How to confirm it: load your homepage and count the stylesheets and scripts in the Network tab. Then ask, for each one, whether that feature appears on this page. Most sites I audit are loading assets for a slider that is not on the page, a form that is not on the page, and a gallery that is not on the page.

What to do: dequeue per page. The blunt version is a plugin that manages this for you by URL rule. The precise version is a few lines in your theme that call wp_dequeue_style and wp_dequeue_script on the pages where a given feature is absent. Be careful, test, and keep a list of what you turned off and where.

Fix 3: nobody resized the images

WordPress generates several sizes on upload, and then a theme or a builder serves the original anyway. A 4000px hero photo scaled down by CSS to 1200px still downloads at 4000px.

How to confirm it: in DevTools, hover any image in the Network tab. Compare its intrinsic size to the size it is displayed at. If intrinsic is more than twice the displayed size, that image is wasting bandwidth.

What to do, in order of impact:

1. Serve WebP or AVIF. The saving over JPEG is large and the browser support question was settled years ago.
2. Export at the dimensions you actually display, at most 2x for high density screens.
3. Let the below-the-fold images lazy load, and make sure the one above the fold does not.

That last point matters more than it sounds. Lazy loading your hero image delays the exact element the browser is measuring your load time against.

Fix 4: the fonts block the first paint

A custom font loaded from a third party domain costs you a DNS lookup, a TLS handshake, and a file, all before the browser will paint text in that font. Meanwhile your page sits blank or flashes.

What to do:

• Self host the font files. Put them on your own domain and the extra connection disappears.
• Preload the one or two weights you use above the fold, and only those. Preloading six weights is the same problem wearing a different hat.
• Set font-display: swap so text renders immediately in a fallback and swaps when the real font arrives.
• Subset the file. If your site is English only, you are probably shipping Cyrillic and Greek glyph ranges for nothing.

Fix 5: the server

Everything above is free to fix and you control it. This one usually costs money.

Shared hosting means your site shares CPU and memory with a large number of other sites, and you find out at exactly the wrong moment. If TTFB is consistently over 600ms with a page cache warm, the problem is underneath you.

How to confirm it is the server and not your code: load a nearly empty page, one with no builder sections and almost no content. If that page also has a slow TTFB, the server is the constraint.

What to do: move to hosting that gives you dedicated resources, put a full page cache in front of WordPress, and put a CDN in front of that. In that order. A CDN in front of a slow origin makes your static assets fast and your pages exactly as slow as before.

Which one is yours

Run it as a decision, not a checklist:

1. Is TTFB over 600ms on a nearly empty page? Fix the server first. Nothing else will show up until you do.
2. Is the page over about 2MB? Look at images, then the builder.
3. Is the page small but still slow to become interactive? Look at scripts, so plugins and third party embeds.
4. Does text flash or arrive late? Look at fonts.

Most sites need two of the five. Almost none need all of them, and working through all five in order is how a week disappears into work that moved nothing.