Why is my WordPress site still slow?

Most WordPress speed problems are hardly caused by one plugin or image. Here’s what actually slows sites down and how better build decisions and optimization fix it.

Picture this. Most site owners, brands, agencies are already doing the obvious things: they choose decent hosting, compress their images, keep the layout reasonably clean, maybe install a caching plugin. But the site still feels slow – or it’s inconsistent. A well-known scenario: fast one month, sluggish the next, green in PageSpeed Insights but still the subject of complaints from users on mobile.

This usually isn’t a hosting problem or a single bad plugin. What NitroPack discovered, based on an analysis of over 100 WordPress websites across different builders, hosting environments, and industries, is that performance problems almost never trace back to a single mistake. More often than not, they’re the result of dozens of small decisions that accumulate across the entire site stack: the foundation, how pages are built, the assets loaded, third-party scripts and how everything is cached and delivered.

That points to performance being addressed in two layers: how a site is built and how it’s optimized and delivered after launch. This was exactly the topic of the joint webinar we held recently that you can watch at your own pace down on YouTube:

Still, if you’re more open to the written word, here are the main points and takeaways to consider with your next build.

Three website performance myths worth retiring

“Page builders are slow.” They’re not, inherently. What’s slow is bad usage: excessive nesting, unnecessary elements, unoptimized assets. Builder-based sites can and do outperform custom-coded ones when they’re structured with intent.

“You need custom development for good performance.” Not necessarily. The largest performance gains typically come from smart decisions and automation, not from rebuilding a site from scratch.

“A 90+ PageSpeed score means the site is fast.” Not always. PageSpeed Insights is lab data – a controlled test environment. Core Web Vitals reported through CrUX (the Chrome User Experience Report) is field data – how real visitors actually experience the site. The two correlate, but they aren’t the same thing, and a strong lab score can still sit alongside a rougher real-world experience.

Where the build phase goes wrong

WPBakery currently powers a bit over 6 million websites and patterns across those builds point to two recurring pitfalls.

The first is usage patterns: a powerful builder makes it easy to add every content element, effect, and feature available, whether or not the page actually needs it.

The second is structural overcomplication: more wrappers, sections, rows and containers than the layout requires – compounded by custom CSS that accumulates as small adjustments stack on top of each other over time. Add unoptimized media on top of that (image galleries with dozens of multi-megabyte files are a common offender – something Georgi from NitroPack sees more than he’s willing to admit) and a site that started fast gets heavier with every update.

Underneath both is a planning gap. Sites are often built around a template with little to no deeper thought given to how the site needs to scale over the next year or two, or whether existing assets and layouts can be reused instead of rebuilt each time.

And the fix is pretty simple (just not that easy, fyi). Plan for growth before building, use reusable templates – something we at WPBakery are known for with our Template Library, let a layout be updated from one place instead of page by page – and put a standard process in place for regular content cleanup so unused elements don’t sit there adding weight indefinitely. Minimalism earns its keep here too: a deliberately simpler design tends to outperform a heavier one, both technically and in conversions. And if you’re building with WPBakery, you’d want to consider these tips for speeding up your site.

Why a clean build still isn’t the finish line

Still, even a well-planned, well-built site tends to run into limits that build-stage discipline alone can’t solve: render-blocking CSS, JavaScript execution order, mobile performance fluctuations, traffic spikes and caching or CDN configuration that most teams don’t have the time or specialized knowledge to maintain themselves. None of this means the build was done wrong, but that the manual optimization becomes harder to sustain as a site – or a portfolio of client sites – grows. Which is where a dedicated tool like NitroPack comes in handy, to improve overall website performance as well as Core Web Vitals. And all that without setting up custom code – much like WPBakery’s Page Builder (just sayin’).

Final tips on building a fast website in 2026 and beyond

Whether you’re a single site or an agency managing several: build with structure and reuse in mind, using global templates and built-in elements rather than stacking custom components.

• Audit the experience – not just the score, on both desktop and mobile.
• Add an automated optimization layer once the build is solid, ideally as early as possible rather than after problems have already accumulated.
• Keep monitoring because performance standards, browser capabilities and the site itself keep changing – a site that hasn’t been revisited in a year or two will show room for improvement even if nothing on it changed, simply because the bar has moved.

Conclusion

One thing that only confirmed our judgment is that website performance has become one of those topics where everyone is looking for a shortcut: a faster server, another plugin, a better score, one setting that fixes everything. In reality – there is no such thing. Fast websites are usually the result of dozens of sensible decisions made consistently throughout the lifetime of a project. Some happen while you’re building. Others happen months or years later, as the site grows, content changes and technology move on.

That’s also why performance shouldn’t be treated as a one-time optimization task or a launch-day checklist, but as part of maintaining a healthy website, just like security, updates or backups. The earlier it becomes part of your workflow, the less likely you are to spend time chasing performance problems later. Share your thoughts and conclusions about this topic down in our Community or look us up on X and let’s chat some more!