How to Speed Up a WordPress Site Without Breaking the Design or the Features

You open your website on your phone while waiting for a coffee and see a white screen, a logo and a spinner. One second, two, three. Then a banner finally crawls in, and the whole page jumps half a screen down. You know the site is “fine”, because at home on your laptop it opens fast. The customer standing in the same coffee queue doesn’t know that. They just closed the tab.

For a long time, design and speed were in a tug of war. First, “beautiful” meant drawn frames, shadows, textures and custom buttons, and all of it was heavy. Then smartphones arrived with slow mobile internet, and the pendulum swung the other way: minimalism, white space, standard fonts, identical rectangular blocks. Sites got lighter, but they also started to look alike, like houses on the same new estate.

Today a business doesn’t have to pick one. A website has to earn trust, show the product and the brand’s character, and still not make people wait. Design and speed work like the two handles of one tap: you have to turn both, and that is the job of whoever builds the site.

When most people were on dial-up, websites were simple HTML pages with a few images. Today we have fast internet, powerful phones and servers, and a WordPress site can be an online shop with filters, a customer account, bookings, maps, calculators, CRM widgets, a chat and a dozen ad pixels.

What changed in twenty years

The problem isn’t that the site is complex. A complex site can be fast. The problem is how that complexity is put together: whether a person stares at an empty screen while the browser pulls in scripts this page doesn’t even need.

When you order a website, you aren’t buying a set of pages, plugins and Figma mockups. You’re buying a tool that should bring in leads and sales. So “the site opens” doesn’t yet mean “the site is ready”.

If the homepage takes eight seconds to load and the developer says “everything works, the form submits and the menu opens”, that’s roughly like selling a car without a gearbox: well, the engine starts.

A finished site shows the important things quickly, doesn’t fall apart on a phone, and passes leads and analytics through correctly. If a visitor leaves before the first screen appears, the site has failed at its one job. That’s why speed should be part of development quality from day one, not a paid “optimisation” after launch.

It’s a familiar story on the market. A company orders a new site from a well-known studio, expects “premium” and gets beautiful mockups that take ten seconds to open on a real phone. First they try to “tune” it with plugins, then again, and in the end the site is rebuilt from scratch. The money for the first version, months of work and a lot of nerves, all written off.

To stay out of this story, test the site before acceptance in real conditions:

• with real content, not three paragraphs of placeholder text;
• on an ordinary mid-range phone, not on the designer’s laptop;
• over mobile internet;
• with analytics, pixels, chat and every integration already connected.

That’s the configuration the site will actually live in. If speed was tested without the pixels and the chat, you tested a completely different site. What else you should get from the developer before acceptance, so you don’t depend on them later, we covered in our guide on what a business should retain if a contractor disappears.

The cheapest time to speed up a site is before it exists. Most problems are easier not to build in than to dig out of a finished project later.

1. Hosting. A provider and plan sized for the real load, not “the cheapest one for a year”.
2. Theme. A lightweight base without a hundred templates nobody will ever use.
3. Features. Only the plugins and integrations that each have a clear role.
4. Content. Rules for photos, fonts and video before anyone starts filling the site.

Everything affects speed: hosting, theme, page structure, the feature set, how the design is implemented, third-party services and how content is handled afterwards. So when choosing a developer, a nice portfolio isn’t enough. Ask them to open a couple of their live sites on your phone.

Hosting is one of the main factors in WordPress speed. That doesn’t mean you have to buy the most expensive server straight away. First look for a provider with stable server response times, and only then pick a plan from them that fits your site. In practice, owners switch providers more often because of instability and slowdowns at certain hours than because a plan lacks features.

This is a guideline, not a law. A badly built five-page site can eat more resources than a tidy shop with hundreds of products. Start with a plan that covers you with room to spare, and scale up as traffic grows.

And budget for more than development. A cheap site on a weak foundation often turns out to be the most expensive one, because you end up paying for it again. What drives the price of a website in general is shown on our website and online shop development service page.

A CDN such as Cloudflare keeps copies of your site’s files closer to the visitor, takes part of the load off the server and helps people in other countries.

What a CDN gives you: faster delivery of images, styles and scripts, less load on the main server, and more stable performance for distant visitors.

What a CDN won’t fix: slow database queries, a heavy theme, plugin conflicts, excess JavaScript and broken architecture. If a page weighs 10 MB, a CDN will simply deliver those 10 MB faster.

The best result comes from the combination: decent hosting, the right plan, a properly configured WordPress cache, a CDN where it actually helps, and a carefully built site.

If the team has the experience, the best option is often a clean custom theme. Even better when the designer and developer work together from day one: then the site contains only the components it really needs, without dozens of unused widgets, animations and libraries.

What a well-made theme controls

• Structure: HTML, page templates, responsiveness, the logic of how content is displayed.
• Resources: CSS, JavaScript, fonts, images and the order in which they load.
• Features: interactive elements, database queries, compatibility with the plugins you need.
• Growth: the ability to add a new feature without going to war with the architecture.

About ten years ago WordPress finally turned from a blogging engine into a platform for business sites and shops. That’s also when marketplaces of ready-made themes exploded: for any niche, with demo content, a hundred templates and a built-in page builder.

The typical trap looks like this. The theme fits the design perfectly, it already has every page you need, and only a little needs finishing. Then, once it’s filled with real content and the necessary plugins are connected, it turns out to be very heavy. Optimisation plugins raise the scores but don’t change the architecture. Sooner or later, maintaining such a site costs so much that replacing the theme is the easier option.

A good theme gives you a clean base where it’s easy to add only what you need.

Some studios, tired of WordPress’s weight, build their own simplified CMS. The first result is impressive: the sites are light and fast. The problems start when the client needs a new feature, an integration, a shop or a more complex structure. Such a system is hard to extend, and the dependence on one studio becomes almost total.

The first version of a custom CMS is only the start. After that it has to be constantly updated, tested, secured and documented, and the admin panel and integrations have to be maintained. That takes a separate permanent team. The more practical route is not to abandon WordPress but to use it selectively: take what you need and leave the rest out of the project.

You can’t ignore speed, but worshipping the number in PageSpeed Insights isn’t a good idea either. For the sake of a few points, people sometimes remove useful blocks, switch off features, strip the design down to sterility and keep “optimising” where a human can no longer feel the difference.

A fast checkout that doesn’t accept payment is of no use to anyone. Same goes for a lightweight form whose leads never arrive.

The score and real speed don’t always move together, either. When we were running a test WordPress shop, at one step the homepage weight dropped from 2.1 MB to 576 KB and the number of requests from 64 to 31, while the Lighthouse score stayed exactly where it was, at 85. A person on slow mobile internet will feel that difference. The number in the report won’t.

The goal: the fastest version of exactly the site the business needs, with all of its features.

PageSpeed Insights colours the result in three bands: 0-49 red, 50-89 orange, 90-100 green. It’s common for an owner to spend years “chasing” the green zone on a site built on a heavy framework: caching, compression and server tweaks bring a few points each, and the pages stay stuck in the middle of the orange zone. A new site designed with speed in mind reaches the green zone much more easily.

• Red zone. People feel the problem. Leads and search visibility may suffer.
• Orange zone. The site is perfectly usable, but there’s room for improvement.
• Green zone. A good benchmark, but not a guarantee of sales, good design or rankings.
• 100 points. A pleasant technical result, but not a goal in itself.

And most importantly: moving from orange to green rarely changes rankings noticeably on its own. Google states plainly that good results in the Core Web Vitals report don’t guarantee top positions, and that Search always tries to show the most relevant content, even if the page experience is weaker (Google Search Central). Speed is only part of the work. Organic traffic needs systematic SEO: structure, content, technical health and external signals.

What you can fix in Core Web Vitals without a developer, we covered separately: Core Web Vitals: what to fix without a developer.

The site is handed over, everything is green. Three months later a manager uploads phone photos to the blog “as is”, and the homepage is crawling again. So if you plan to fill the site yourself, the first question to ask yourself or your team is: who knows how to prepare photos for the web?

A modern phone shoots photos 4000 pixels wide or more. Great for print, too much for a website. On our test stand, six such photos inserted on the homepage at “full size” weighed 8.3 MB, which is 82% of the whole page weight. The page itself weighed almost 10 MB with them, and the largest element (LCP) appeared on mobile after 44.7 s. When we chose “Large” (1024 pixels) in the same blocks, the homepage weight dropped to 2.3 MB and LCP to 5.1 s. Without a single plugin.

What’s worth knowing:

• Since version 5.3, WordPress automatically scales down oversized photos to 2560 pixels on the longer side and saves a version with the -scaled suffix (WordPress Developer Blog). But that’s still too much for an image in the body text.
• The Image block in the editor has a “Resolution” setting. For photos in the text, “Large” is almost always enough. “Full Size” is for rare cases.
• WordPress itself adds loading="lazy" to photos below the first screen and fetchpriority="high" to the main banner, as long as you insert them with standard blocks rather than hand-written code.
• Converting to WebP helps, but not always. On the stand, the converter plugin simply skipped some photos, because the WebP version came out heavier than an already well-compressed JPEG. The main gain comes from the right size, not the format.

What to explain to the people who fill the site: the recommended photo width, a rough maximum file size (for photos in the text, a sensible limit is up to 200-300 KB), the format and a short preparation routine.

What automation won’t solve: a plugin compresses files, but it doesn’t excuse the habit of uploading camera originals.

That’s why speed has to be maintained for as long as the site lives, not just on launch day.

WordPress has dozens of plugins for caching, CSS and JavaScript minification, image compression, database cleanup and CDN integration. Hence the temptation to install several at once: each of them speeds something up, right?

In practice, it often works the other way round. The hosting already has its own server cache. The site runs through Cloudflare. One plugin minifies CSS, another combines files, the server caches the result, and the CDN processes it all over again. The outcome: duplicated work, stale pages and bugs that are hard to reproduce.

Traces of old solutions get in the way too. On the test stand, as soon as we replaced one cache plugin with another, the new one refused to switch on: the previous one had left behind its advanced-cache.php system file, and WP Super Cache warned outright that it couldn’t work while that file was in place. On a live site, these “ghosts” can haunt you for years.

Another finding from the stand concerns the plugins themselves. Eight plugins from a typical set (a page builder, its add-ons, a slider, two forms, share buttons, WooCommerce) together added about 130 KB to the homepage, roughly sixty times less than the photos. But the styles of the page builder and its add-ons were blocking the rendering of a page that didn’t contain a single block from that builder. After switching off five plugins that had no job on the site, the homepage score rose from 60 to 85, and the layout “jumping” (CLS) disappeared. So the question isn’t how many plugins you have, but what each one loads and where.

A good optimisation setup is short: every tool has one clear role.

WP Rocket. A paid plugin that works on ordinary Apache and Nginx servers. It’s often chosen when the hosting doesn’t provide its own optimisation suite: page cache, deferred scripts and lazy loading in one place.

LiteSpeed Cache. Free. Its CSS and JavaScript minification and image optimisation can be used on any server, but its main feature, page caching, only works on a LiteSpeed server or through the QUIC.cloud CDN (plugin page). We checked this on Apache: the “Enable Cache” toggle sits in the ON position, and above it there’s a warning that caching is unavailable without a LiteSpeed server. In other words, “enabled” in the settings doesn’t yet mean “working”. Ask your host which server your site runs on before you count on this plugin as your cache.

Choose based on your server environment and overall architecture, not on the number of checkboxes in the settings or on popularity. If your hosting doesn’t provide free plugins, there are simple free options for Apache such as WP Super Cache. On the stand, it cut the homepage server response time from 150-250 milliseconds to 10-30.

Several caching systems at once are only installed when you know exactly which one caches what.

Experiments are normal, that’s how people learn. Comparing plugins, switching themes, turning script deferral on and off is useful. But do it on a local copy, a test server or a staging version of the site. A live site that brings in leads is not a testing ground.

Why it matters: a misconfigured cache can show old prices. Aggressive JavaScript deferral breaks forms and checkout. A botched database “cleanup” deletes data you need. And all of this can go unnoticed for a week, because an administrator logged into WordPress often sees the uncached version, while customers see the cached one.

If the speed problem is on a live site and you don’t have much experience, it’s better to hand it to a WordPress specialist than to learn on real leads.

Don’t draw conclusions from a single homepage test. Problems often live in individual templates: the homepage flies while the product page crawls.

What to test

• Information pages: homepage, service page, blog article.
• Catalogue: category, search, filters, sorting.
• Commercial pages: product, cart, checkout, enquiry form.
• Real interaction: menus, buttons, forms, layout stability, behaviour on a phone.

And run each test several times. On our stand, the same article page scored 74, 48 and 74 in three consecutive runs. The homepage fluctuated between 33 and 58 across different series. One run is noise, the median of three already tells you something.

Tell lab data apart from real data. Lighthouse and the diagnostics in PageSpeed Insights simulate a single page load. The real user data block at the top of PageSpeed Insights and the Core Web Vitals report in Search Console show the experience of actual visitors over the last 28 days, if there’s enough traffic (PageSpeed Insights). Look not only at the score but also at when the main content appears, whether a button can be tapped right away, whether the page jumps and whether the forms work.

Take a separate look at analytics, ad pixels, live chats, video, maps, CRM widgets and review services. You usually can’t remove them, because the business needs them. The task is to load them so they don’t block the main content. On the stand, embedded YouTube and Google Maps together pulled in about 1.5 MB before the visitor had even scrolled to them. A plain loading="lazy" didn’t help: the page is short, and the browser loaded them in advance anyway. What helped was a simple swap: a video cover image linking to YouTube, and an “Open in Maps” button instead of the embedded map.

1. Make sure there is a problem. Test several page types on a phone and a computer, three runs each.
2. Find the main bottleneck. Server, theme, photos, database, JavaScript or a third-party service. In the Lighthouse report, look at what exactly weighs the most.
3. Remove the biggest problem. One big fix does more than twenty small tweaks.
4. Check that everything works. Forms, menus, filters, cart, payment, customer account. Only then measure again.

Here’s how this routine played out on a test WordPress shop with the Astra theme, WooCommerce and a typical set of plugins. Median of three Lighthouse runs, mobile profile:

Four things were done: the right photo sizes, switching off plugins with no role, replacing the embedded videos and map with lightweight links, and page caching. The product page barely changed, because its weight is the WooCommerce gallery and its scripts. That’s a job for a developer, not for an owner with a settings panel. The stand is local, so the absolute numbers on your hosting will be different. What’s worth comparing is the direction and scale of the changes.

Once the technical side is done, the site still needs promoting. A good place to start is our guide on how to check symptoms yourself and accept an SEO audit.

A fast WordPress site is almost never the merit of a single plugin. Speed is made of decisions at every stage: hosting, theme, how the design is implemented, the feature set and how content is handled afterwards.

And speed can’t be the only measure of a good website. A primitive design, cut-down features or broken forms won’t get any better from 100 points in PageSpeed.

A beautiful, functional site isn’t finished if people are left waiting for it to load. A fast site isn’t successful if people don’t trust it and it doesn’t bring in leads.

So ask yourself: what is the fastest version of the site that keeps the design, the features you need and the value for the business?

If your site is slow and it’s not clear where to start, write to us. We’ll look at what’s slowing it down and tell you what can realistically be fixed with settings and what already needs development. You can see how this works in practice in the case study LMakeup: speeding up a site built on a website builder, where we had no access to the code at all.