WordPress Hosting: What You Are Actually Paying For

WordPress hosting is sold across a price range that runs from roughly £3 a month to several hundred, and the plans at both ends of it describe themselves in almost identical words. Fast. Secure. Backed up. Supported. The specification that would let a buyer tell them apart, meaning which PHP branch runs the site, which database engine sits behind it, how many caching layers exist and which of them are actually switched on, is normally absent from the page you are asked to buy from.

That absence is part of the product. “Managed” is a marketing category rather than a technical one, and no standards body defines it. Two providers using the word can differ on whether a persistent object cache is running, whether you may keep your own caching plugin, whether a backup can leave their infrastructure, and whether you can open a shell at all.

What follows is the specification those pages leave out: what WordPress requires, which parts of the stack move page speed, what managed hosting adds and quietly removes, and realistic monthly bands for each tier.

What are you actually paying for with WordPress hosting? Four things. A PHP version and database engine that meet WordPress’s own published baseline. Caching layers you would otherwise have to install and tune yourself. Operational work, meaning updates, staging, backups and a firewall. And headroom for requests that cannot be cached. A brochure site needs almost none of that fourth thing. A shop or a membership site spends most of its budget there.

WordPress Hosting Is a Category Name, Not a Specification

The price spread inside a single category is the tell. Two plans both labelled managed WordPress hosting can sit at £20 and £250 a month, and the marketing copy will not explain the gap, because the gap is made of things the copy does not mention.

At the cheap end you are buying a slice of a shared machine with a PHP-FPM pool, a page cache and a control panel. At the expensive end you are buying isolated compute, a persistent object cache, a staging environment, a managed firewall, a support team that will read your error log, and someone contractually responsible when a core update breaks a template.

Both are legitimate products. The problem is that the buyer cannot see which one is in front of them, so the decision gets made on price and on review sites that rank by affiliate commission. The result is predictable in both directions. Brochure sites end up on £150 plans they will never exhaust, and WooCommerce stores end up on £5 plans that fall over at checkout on the first busy Saturday.

The way out is to shop by four questions rather than by tier name: which PHP branch, which caching layers, how many uncacheable requests the plan absorbs, and what happens to your data when you leave.

What WordPress Actually Requires From a Server

WordPress publishes a requirements page and it is short, which is exactly why it gets skipped. Read it as a purchasing specification, because a plan that fails it is disqualified before performance is even discussed.

The PHP version

The WordPress requirements page states the recommended baseline as “PHP Version 8.3 or greater”. It also carries a warning that matters more than the recommendation: WordPress “will still run on PHP 7.4+ and MySQL 5.5.5+, but those versions have reached official End Of Life and may expose your site to security vulnerabilities.”

That is the whole trap in one sentence. WordPress will not refuse to boot on an ancient PHP branch. It runs, looks normal, and quietly sits on an interpreter that has not received a security fix in years.

The database

The same page asks for “MariaDB 10.11+ or MySQL 8.0+”. Older engines still work, which is why so many sites are on them. WordPress’s own usage statistics show roughly one install in six reporting a MySQL 5.x release, well under the stated floor, with MySQL 5.7 alone accounting for about 12 per cent of reporting sites.

The consequence is not that the site breaks. It is that you lose engine improvements which matter for exactly the workloads that are hard to cache, and you inherit a migration you will have to do eventually anyway.

HTTPS and the extensions

HTTPS is listed as “Required for every install”, not recommended. Any host still treating a certificate as a paid extra in 2026 is telling you something about the rest of the plan.

Beyond that, the WordPress Hosting Handbook names json and mysqli as required, and curl, dom, exif, fileinfo, hash, igbinary, imagick, intl, mbstring, openssl, xml and zip as highly recommended. Two are worth naming to a salesperson. Without zip, plugin and core update packages cannot be decompressed. Without imagick, media uploads fall back to a weaker image library and your images come out worse before anyone touches an optimisation plugin.

PHP Version Is the Highest Leverage Line on the Invoice

Of everything a host controls, the PHP branch has the best ratio of effect to effort. On most panels it is a dropdown. Nothing is rebuilt, nothing is migrated, and a site that was already compatible simply starts running on a faster and better supported interpreter.

The reason it stays unchanged for years is organisational rather than technical. Nobody owns it. The agency that built the site has moved on, the host will not change it unilaterally because a fatal error in an abandoned plugin would then be their fault, and the business has no reason to think about a number it has never been shown.

So the first question to ask a prospective host is not about speed. It is which PHP branch the plan runs by default, which branches it offers, and whether you can change it yourself without opening a ticket. A host that only offers a branch WordPress no longer recommends has answered every other question at the same time.

Test on staging, never flip production. A site moving from PHP 7.4 to 8.3 usually surfaces two or three deprecation notices from unmaintained plugins, and those are the real cost. Budget half a day to a day of developer time, covered in more detail in our guide to WordPress developer rates and what to ask.

The Security Half of the PHP Argument

Performance is the reason people give for upgrading PHP. Security is the reason that actually matters, and it is measurable rather than arguable.

PHP publishes its own supported versions schedule. Each branch gets two years of active support and two further years of security fixes only. As of September 2026 that puts PHP 8.2 in security-only mode until 31 December 2026, and PHP 8.3 in security-only mode until 31 December 2027 after active support ended on 31 December 2025. PHP 8.4 stays in active support until 31 December 2026 with security fixes until 31 December 2028, and PHP 8.5 until 31 December 2027 with security fixes until 31 December 2029. Anything older is finished: PHP 8.1 ended on 31 December 2025, PHP 8.0 on 26 November 2023 and PHP 7.4 on 28 November 2022.

Set that against what WordPress sites actually run. The WordPress statistics page reports about 38.8 per cent of installs on a branch that is completely end of life, with roughly 23.2 per cent still on PHP 7.4 or older. Only about 36.4 per cent meet the PHP 8.3 baseline WordPress recommends, and a further 24.8 per cent sit on PHP 8.2, which loses security support at the end of this year.

A majority of WordPress sites therefore run an interpreter that either receives no security fixes or is months from that state, and in almost every case it is a hosting setting nobody has looked at. Correcting it costs less than a plugin licence, which is why our WordPress security hardening checklist treats it as step one.

The Caching Layers, in the Order a Request Meets Them

Almost every performance claim a host makes is a claim about caching, and almost every buyer hears it as one undifferentiated promise. There are four distinct layers, they sit in a fixed order, and each saves a different kind of work. The order below is the order a single request travels through, and a request answered by an earlier layer never reaches the later ones.

The edge or CDN cache

The first thing a request meets is a cache outside your server entirely, on a network of points of presence near the visitor. If the response is already stored there, your host never sees the request at all.

This layer saves network distance as well as compute. A visitor in Manchester hitting an edge node in London avoids a transatlantic round trip. For static assets it is close to free and always worth having. For HTML it is powerful but conditional, because the edge has to be told which responses are personal and must never be shared.

The full page cache

The second layer stores the finished HTML of a page so PHP and the database do not run again. The WordPress Hosting Handbook recommends a reverse proxy such as NGINX or Varnish, which “stores the output directly into the server memory or hard disk”, and adds the rule that decides whether the layer works at all: “it’s a good idea to exclude all logged in users from the cache because they are supposed to see personalized content.”

This is the layer that flatters cheap hosting. When it works, a visitor is served a file, and the PHP version, database engine and plugin count stop mattering for that request because none of them execute.

The object cache

The third layer caches the results of individual database queries and computed values. WordPress ships this by default but not persistently. The WP_Object_Cache documentation is explicit: “By default, the object cache is non-persistent. This means that data stored in the cache resides in memory only and only for the duration of the request.”

Making it persistent means putting Redis or Memcached behind it via a drop-in, which converts the cache from something rebuilt on every page load into something shared across requests and visitors. It is the layer that matters once pages stop being cacheable as a whole, and the one most often missing from cheap plans.

The opcode cache

The fourth layer is OPcache, which stores the compiled bytecode of your PHP files in shared memory so the interpreter does not reparse and recompile them on every request. The Hosting Handbook states that “for production WordPress environments, it’s recommended that OPcache be enabled for web requests and sized for the site or hosting platform.”

There is a deployment consequence. Because OPcache holds compiled code, a deployment has to reset it or invalidate the changed files, or the server keeps running the previous version. A host that cannot tell you how OPcache is invalidated is a host where a plugin update appears to do nothing for several minutes.

Why a Brochure Site Is Fast on Almost Any Host

Follow those four layers through and the conclusion is uncomfortable for the hosting industry. If every visitor is anonymous and every page is cacheable, the full page cache answers nearly all traffic, and the specification of the machine behind it barely registers.

That is why a five page company site on a £4 plan with a decent page cache can post a better server response time than a bloated site on a £200 plan. The cheap site is serving files. The expensive one is running PHP.

The number to watch is time to first byte, which is not itself a Core Web Vital. Google’s Web Vitals overview files it among the supporting metrics, useful for “diagnosing issues with LCP” caused by slow server response times. That is the exact slice of page speed a host controls.

WordPress agrees closely enough to have written it into core. The Site Health full page cache test added in WordPress 6.1 checks “whether the site is using a full page cache solution and if the response time is acceptable”, with a default threshold of 600 milliseconds. If your site is above that with a page cache supposedly enabled, the cache is not working, and extra CPU will not disguise it.

So for a brochure site, a hosting upgrade is usually the wrong purchase. What makes it slow is more often an oversized hero image, a page builder shipping hundreds of kilobytes of CSS, or six font weights, which is the argument set out in our comparison of Elementor and a custom theme.

Logged In Traffic and WooCommerce Break the Model

Everything above assumes the page cache can answer. The moment visitors log in, that assumption collapses and the economics of hosting invert.

WooCommerce documents this directly. Its caching guidance instructs you to exclude Cart, My Account and Checkout from page caching because those pages “need to stay dynamic since they display information specific to the current customer and their cart.” It also lists cookies that must bypass the cache, including woocommerce_cart_hash, woocommerce_items_in_cart and wp_woocommerce_session_, and advises excluding _wc_session_ from database caching.

Read that as a hosting specification and it says something blunt. On a shop, the pages that generate revenue are precisely the pages the page cache cannot touch. Catalogue and product pages can be cached for anonymous browsers. Cart and checkout cannot, ever, for anyone.

The same holds for membership sites, learning platforms, forums and any site with a customer portal. Once a session cookie is set, most caching plugins stop serving cached HTML to that visitor entirely, so every click executes PHP and hits the database. This is where the object cache stops being an optimisation and becomes load bearing, and where a cheap plan hurts in a way no synthetic homepage test reveals, as covered in why your WooCommerce store is slow.

What Managed WordPress Hosting Actually Includes

Strip away the adjectives and managed hosting resolves into a fairly consistent bundle of operational work. It is worth pricing that work honestly, because for a business with no technical staff it is often cheaper bought than done.

Updates

Managed plans usually apply core updates automatically, sometimes plugin updates too, occasionally with a visual regression check either side. The useful thing to know is how much WordPress already does free.

WordPress has auto-updated minor core releases and translation files by default for years, and since 5.6 new installations have automatic updates enabled for both minor and major core releases unless a version control checkout is detected, while existing installations keep the older behaviour. So the paid part is not core minor updates. It is plugin updates, the rollback when one breaks, and someone noticing that it broke.

Staging and backups

A one click staging environment is genuinely valuable and genuinely annoying to build yourself. Judge it on two details rather than its existence: whether pushing staging back to production overwrites the live database, which would discard orders and comments taken since the copy, and whether the staging site is blocked from search engines and from sending email.

Firewall and malware scanning

Most managed plans include a web application firewall at the edge and some form of malware scanning. The firewall is real value, because virtual patching at the network layer buys time between a plugin vulnerability being disclosed and you updating.

Scanning is weaker than it sounds. It usually detects known malicious file signatures, which means it catches commodity infections and misses targeted ones. Treat it as a smoke alarm rather than a lock, and keep the hardening work on your side of the line.

What Managed Hosting Takes Away

The restrictions are the half nobody reads, and they are usually more consequential than the features. They exist for defensible reasons, but the reasons are the provider’s rather than yours.

The clearest published example is WP Engine’s disallowed plugins list, which bans whole categories rather than individual bad actors. Caching plugins are banned because they “can conflict with our platform’s built-in caching structure”. Backup plugins are banned on the grounds that they “needlessly bloat your site”. Related posts plugins are banned as “extremely database intensive”. Plugins with documented vulnerabilities are banned outright, as are plugins duplicating platform functionality.

Every one of those is a reasonable engineering decision. Collectively they mean your site is not portable in the way you assumed. If your build depends on a specific caching plugin’s configuration, that configuration does not move with you.

Shell access is the other common omission. Plenty of managed plans provide no SSH at all, or a restricted shell without WP-CLI, which turns routine work such as a bulk search and replace after a domain change into a support ticket. Two more catch people out: long running processes are frequently capped, so an import of 50,000 products has to be chunked, and outbound mail is often blocked or rate limited on the assumption that a compromised site will be used for spam.

The Performance Claims That Do Not Survive Testing

Hosting marketing runs on a small set of claims that fall apart the moment you ask what was measured.

“Twenty times faster” almost never names a baseline. Faster than what, on which page, with which plugins, under what concurrency? Without those four, the number is a ratio between two unnamed quantities.

“Unlimited bandwidth” sits next to a monthly visits allowance in the same table. Bandwidth is rarely the constraint on a WordPress site anyway. The constraint is concurrent PHP execution, which the plan usually does not mention at all.

“Ninety-nine point nine per cent uptime” sounds absolute and is not. Over a thirty day month it permits about 43 minutes of downtime. Three nines is a normal shared hosting figure, four nines allows about four minutes a month, and the difference is the difference between an inconvenience and an outage nobody notices. Read what the credit actually pays when it is missed, a subject we treated separately in uptime SLAs that mean something.

The last claim is the most common and the most misleading: a screenshot of a speed test on a cached homepage. That measures the page cache, not the host, and the page cache is the one component roughly equivalent everywhere.

How to Test a Host Properly

Testing hosting is not difficult, but it has to be done on the path that actually exercises the server. Five steps, in order.

First, test an uncached path. Append a unique query string to defeat the page cache, or request a page that is never cached, such as a cart or an account page. If you cannot make a request that runs PHP, you are testing a file server.

Second, repeat it. A single request tells you nothing about variance, and variance is where cheap hosting shows itself. Take at least twenty samples and read the 75th percentile, which is the statistic Google uses for field data.

Third, test from where your visitors are. A response measured from a data centre next door to the server is not the response your customers in Leeds receive.

Fourth, test under concurrency. Run ten or twenty simultaneous uncacheable requests. This is the only test that reveals PHP worker exhaustion, and worker exhaustion is what takes a store down during a promotion.

Fifth, compare like for like: same PHP branch, same plugin set, same theme, same content volume. A migration that changes the plugin stack at the same time as the host has proved nothing about either. If you want this run against a real site rather than a candidate host, that is what a WordPress performance audit does.

Which Core Web Vitals Hosting Actually Moves

Core Web Vitals is where hosting claims and search rankings get conflated, so it is worth being precise about which metric a server can influence.

There are three, assessed at the 75th percentile of page loads and segmented across mobile and desktop. Largest Contentful Paint measures loading and is good at 2.5 seconds or less, needs improvement between 2.5 and 4.0 seconds, and is poor beyond 4.0. Interaction to Next Paint measures responsiveness and is good at 200 milliseconds or less, needs improvement up to 500 milliseconds, and is poor above that. Cumulative Layout Shift measures visual stability and is good at 0.1 or less, needs improvement up to 0.25, and poor above it. First Input Delay was retired and replaced by INP, which became a stable Core Web Vital in 2024.

Hosting moves exactly one of those directly. Server response time is part of LCP, so a host that shaves 400 milliseconds off it takes 400 milliseconds off LCP for every visitor. On a slow host that can be the difference between passing and failing.

It does almost nothing for CLS, which comes from images without dimensions and late loading fonts, and very little for INP, which is dominated by JavaScript on the main thread. The rule is that if LCP is poor and your uncached server response sits above the 600 millisecond mark WordPress flags, hosting is part of the problem. If the response is comfortable and LCP is still poor, the fault is in the page, and our guide to passing Core Web Vitals in 2026 is the better place to spend the budget.

Backups, and the Part Nobody Checks

Every plan above the cheapest advertises backups. Almost nobody buying one asks the questions that decide whether the backup is worth anything.

Whether anyone has ever restored one

The NCSC puts it plainly in its small organisation guidance: once you have made a backup, “it’s important you know how to restore it, and to check that it contains all your important data.” An untested backup is a belief, not a control.

Ask the provider how a restore is initiated, how long it takes for a site your size, and whether restoring the database also restores the uploads directory. Then do it once on staging before you need it. The failure mode to look for is a restore that returns files but not the database, or one that succeeds and quietly loses everything created since the copy.

Retention and frequency

Daily backups with seven day retention sound generous until you consider how a WordPress site actually fails. A defaced site is noticed in hours. A compromise that quietly injects spam links into old posts is noticed in weeks, and by then every retained copy contains the injection.

Thirty days is a more useful floor for anything commercial, and a separate monthly copy is cheap insurance. A store also needs a database backup interval measured against order volume, because losing four hours of orders is not the same class of problem as losing four hours of blog edits.

Where the copy lives, and in what format

The NCSC’s other point is that a backup which stays attached to the live system is not separate: a device holding backups “should not stay connected to your device when not in use”, because whatever compromises the source can reach it. Applied to hosting, a backup stored on the same account and restorable only through the same panel shares its fate with the thing it protects.

Format is the subtler version of the same problem. If the only way to read a backup is the provider’s own restore button, you have a convenience feature rather than a portable copy. The test is whether you can download today a plain SQL dump and a file archive that a competent developer could stand up anywhere else. If not, migration stops being a technical decision and becomes a negotiation.

Where the Data Sits, and Why It Matters to UK Buyers

Hosting decisions are data protection decisions, and for a UK business the question is not where the company is registered but where personal data rests and who can reach it.

The ICO’s guide to international transfers sets a three step test. If UK GDPR applies to your processing, you are the one initiating the transfer, and the receiving organisation is a separate legal entity, you are making a restricted transfer. The ICO is explicit that the rules “apply to all restricted transfers, even small, infrequent ones” and cover every organisation handling personal data, “including sole traders and self-employed individuals.”

Note what counts as a transfer. The ICO includes both sending personal data and “making it accessible” to an organisation outside the UK. A support team abroad with access to your admin, or an off-site backup replicated to another region, can each meet that definition.

Every restricted transfer must be covered by one of three things: UK adequacy regulations for the destination, appropriate safeguards such as the International Data Transfer Agreement, the Addendum or binding corporate rules, or an exception. Where you rely on safeguards the ICO also expects a transfer risk assessment showing protection is not materially lower afterwards. None of that makes an overseas host unusable. It makes it a decision that needs documenting, and documenting is far cheaper before you migrate than during a subject access request.

What a Processor Agreement Should Say

Your host is a processor and you are the controller, so a written contract is not optional. The ICO lists what that contract must contain, and four of its terms read directly as hosting questions.

Sub-processors come first. Under Article 28(3)(d) the processor must not engage another processor without your authorisation, must tell you about intended changes so you can object, and must impose equivalent obligations down the chain. In hosting terms that is the CDN, the backup destination, the mail relay and the underlying cloud provider. Ask for the list.

Security is second. Article 28(3)(c) requires measures meeting Article 32, and the ICO spells out what those include: encryption and pseudonymisation, resilience of processing systems, “the ability to restore access to personal data in the event of an incident”, and “processes for regularly testing and assessing the effectiveness of the measures.” That is restore testing written into law rather than into a best practice article.

Third is the exit. Under Article 28(3)(g) the processor must, at your choice, delete or return all personal data at the end of the contract and delete existing copies. A provider whose backups cannot leave their platform has a contractual problem as well as a practical one. Fourth is audit, which under Article 28(3)(h) entitles you to the information needed to demonstrate compliance and to their certifications and reports.

The Tiers, and What They Cost in the UK

Four tiers cover almost every WordPress site, and the boundaries between them are set by uncacheable load rather than by traffic. The bands below are what UK buyers typically pay per month. They are category bands rather than any single vendor’s price list, so treat them as a sanity check on a quote rather than as a quote.

Shared hosting, £3 to £15 a month

Perfectly adequate for a cacheable brochure site, and genuinely poor value if anyone logs in. You share PHP capacity with neighbours you cannot see, so variance under load bites rather than the average. Check the PHP branch first, because this tier is where end of life interpreters concentrate.

Managed WordPress, £20 to £400 a month

The right default for content sites and small shops. You are buying updates, staging, a firewall, a persistent object cache and a support team, and paying for it with the restrictions above. The £20 to £100 range covers a single site of moderate traffic. Beyond that you are usually paying for more sites, more visits, or more PHP workers.

VPS or cloud with your own stack, £15 to £120 plus management

A modest cloud instance costs £15 to £120 a month, but the machine is the cheap part. Somebody has to patch the operating system, tune the reverse proxy, run the object cache and handle backups, and buying that in costs a further £150 to £600 a month. Worth it when uncacheable load is real, or when your stack has requirements a managed platform forbids.

Bespoke infrastructure, £400 a month and up

Multi region deployments, high concurrency events, strict data residency, or an architecture where WordPress is one component among several. Hosting stops being a product decision and becomes part of the build, which is how we approach it inside a website development engagement.

Sizing by Uncacheable Requests, Not Pageviews

Hosting plans are sold in monthly visits because that is a number buyers recognise. It is close to useless for capacity planning, because a hundred thousand cached anonymous pageviews cost almost nothing and ten thousand logged in ones can saturate a small server.

The number that matters is concurrent uncacheable requests, and the arithmetic is simple. One PHP worker handles one uncacheable request at a time. Workers needed is roughly peak uncacheable requests per second multiplied by average PHP response time in seconds. Twenty uncacheable requests a second at 400 milliseconds each needs about eight workers to keep pace, and you want at least half as many again as headroom.

So ask two questions no plan page answers: how many PHP workers does this plan run, and what is the per process memory limit? Both numbers exist and neither is usually published. Support will normally tell you if you ask directly, and the answer says more about the plan than every benchmark on the page.

Then estimate your own side honestly. Count the proportion of sessions that are logged in, the checkout and account traffic at your busiest hour rather than your average one, and any admin-ajax or REST traffic your plugins generate in the background, which is invisible in analytics and very visible in a server log.

Plugin Count and Editorial Volume Are Hosting Decisions

Two things inside the site determine how much hosting it needs, and both are usually treated as content decisions made by people who never see the invoice.

The first is the plugin stack. Every active plugin adds autoloaded options that load on every request, scheduled events that fire on visitor requests because WordPress cron is not a real cron, and queries per page build. Thirty plugins on a cached brochure site is survivable. Thirty plugins on a shop where nothing caches means thirty plugins executing on every checkout step. WordPress core has a rough view of when this starts to bite: the persistent object cache Site Health check suggests object caching once a site passes thresholds such as 2,000 posts, 2,000 users or 600 autoloaded options.

The second is editorial volume. Revisions accumulate without limit by default, media libraries grow into tens of thousands of files with several generated sizes each, and both inflate the database and the backup window. A site publishing daily for five years is a materially different hosting problem from the same design publishing monthly, and nothing on the plan page reflects that. Auditing the build, not the plan, is what a WordPress developer should do before quoting a migration.

Choosing, in Order

Work through it in this sequence and the decision usually makes itself. Establish what proportion of your traffic is uncacheable, because that single number picks your tier. Confirm the PHP branch and database version meet the published baseline, because a plan that fails there is disqualified regardless of price. Establish which caching layers are included and which you must supply. Ask where backups live, in what format, and whether you can download one today. Then read the processor terms for sub-processors, data location and end of contract deletion. Only after all of that does price mean anything, because until then you are comparing products that are not the same product.

Mecanik does this as a fixed piece of work before any migration, usually alongside a website development engagement, and takes it on as ongoing support through our WordPress developer for hire service. If you are weighing up where the platform itself is heading, our write-up of WordPress 7.0 and the AI client in core is a reasonable companion to this one.

Frequently Asked Questions

How much should WordPress hosting cost in the UK? It depends almost entirely on how much of your traffic can be cached. A brochure site with anonymous visitors is well served at £3 to £15 a month on shared hosting. A content site or small shop usually belongs on managed WordPress hosting at £20 to £100 a month, rising to £100 to £400 for busy or multi site plans. A store or membership site with heavy logged in traffic typically needs a VPS or cloud stack at £15 to £120 for the machine plus £150 to £600 a month if somebody else manages it.

Is managed WordPress hosting worth the extra money? It is if you have no operations person, because you are buying updates, staging, backups, a firewall and a persistent object cache that you would otherwise configure yourself. The trade is real restrictions. Providers routinely ban caching plugins, backup plugins and database intensive plugins, often withhold shell access, cap long running processes and block outbound mail. Check those limits against your build before you commit, not after.

What PHP version does WordPress need in 2026? WordPress recommends PHP 8.3 or greater. It still runs on PHP 7.4 and above, but those branches are end of life and receive no security fixes. PHP 8.1 ended on 31 December 2025, PHP 8.0 on 26 November 2023 and PHP 7.4 on 28 November 2022, while PHP 8.2 is in security only mode until 31 December 2026. About 38.8 per cent of WordPress installs still report a fully end of life branch.

Does better hosting improve Core Web Vitals? Only one of the three, and only indirectly. Server response time is part of Largest Contentful Paint, so a faster host lowers LCP for every visitor. It does almost nothing for Cumulative Layout Shift, which comes from images without dimensions and late loading fonts, and very little for Interaction to Next Paint, which is dominated by JavaScript on the main thread. If your server response is already comfortable, the remaining problem is in the page.

Why is my WooCommerce store slow on a plan that says it is fast? Because the pages that matter cannot be cached. WooCommerce requires Cart, My Account and Checkout to stay dynamic, and sets session cookies that bypass the page cache for logged in shoppers. The speed test on your homepage is measuring a cached file, while checkout is executing PHP and hitting the database on every request. Capacity for uncacheable requests, not the cached homepage figure, is what a store is actually buying.