WordPress powers a little over 40% of all websites on the internet. For small and medium businesses it remains the most practical platform available — affordable, flexible, and editable by a staff member rather than a developer. That accessibility is its single greatest strength.
But the way WordPress sites are built has changed dramatically over the past decade, and the resource cost of running one has changed with it. Sites that ran comfortably on a standard hosting plan five years ago now routinely exceed the limits of that same plan — not because the business grew, and not because traffic increased, but because the software underneath quietly grew heavier.
This article explains where that weight comes from, why it is accelerating, and what it means for the price of web hosting over the next few years.
1. What “Memory” Actually Means in Web Hosting
When most people hear the word memory in relation to a website, they think of storage — how many pages, images and files the site holds. That is disk space, and it is comparatively cheap.
Memory in the hosting sense means something different. It refers to RAM: the working space a server uses to actually construct a page at the moment a visitor asks for it.
Every time someone visits a WordPress page, the server does not simply retrieve a finished file and send it. It builds the page from scratch, on demand, in a matter of milliseconds. To do that it must:
- Load the WordPress core software into memory
- Load the active theme
- Load every active plugin
- Query the database for the page content
- Assemble all of it into finished HTML
- Send that HTML to the visitor’s browser
- Discard everything and release the memory
That entire cycle happens for every single page view, from every single visitor. And each of those cycles is given a fixed working allowance — a scratchpad of a defined size in which the page must be built. If the process fits within the allowance, the page loads. If it runs out of room, the request is terminated instantly and the visitor sees a blank white screen reading “There has been a critical error on this website.”
That allowance is the PHP memory limit, and for many years the industry default has been 128 MB per page load, per visitor.
2. Where the Memory Actually Goes
A bare WordPress installation with a simple theme and no plugins consumes somewhere in the region of 30 to 40 MB per page load. Against a 128 MB allowance, that leaves an enormous margin.
The margin disappears in two places.
Themes. A conventionally coded theme — HTML, CSS and a modest amount of PHP — is light. A visual page builder theme is an entirely different proposition. Products such as Divi, Elementor, WPBakery and Beaver Builder let a business owner design pages by dragging elements around a screen, with no code involved. This is genuinely valuable. But to make it work, the builder must load its complete framework into memory on every page request in order to reconstruct that visual layout from stored instructions. A page builder theme can consume three to five times the memory of an equivalent conventional theme rendering an identical page.
Plugins. Each active plugin loads its own code on every request, regardless of whether that page uses it. A contact form plugin loads on your privacy policy page. A booking system loads on your About Us page. An e-commerce platform such as WooCommerce loads on every page of the site, not merely the shop.
Individually, each plugin is small — a few megabytes at most. The problem is arithmetic. A typical small business WordPress site carries between 15 and 30 active plugins. At an average of 3 MB each, that is 45 to 90 MB consumed before the page’s actual content is assembled.
Add a page builder theme at 40 MB and a WordPress core at 35 MB, and a site can sit at 120 MB of a 128 MB allowance before rendering a single word of text. A page with a handful of extra design modules on it tips over the edge. The site does not fail consistently — simpler pages still fit — which is why these faults so often present as intermittent, and why they are so frequently misdiagnosed as a server problem.
3. Feature Creep: How Consumption Grows Without Anyone Deciding It Should
The critical point — and the one most often missed — is that plugin memory consumption increases over time on its own.
A plugin developer releases version 1.0 with a focused set of features. It is fast and lean. The plugin becomes popular. Users request additions. Competitors add features and the developer must match them. Over successive releases the plugin acquires:
- A settings dashboard with a visual interface
- Analytics and reporting
- Integrations with third-party services
- Compatibility layers for other popular plugins
- Backwards compatibility code for older versions
- Multilingual support
- A block editor interface
- Accessibility and compliance features
Every one of these is a reasonable addition. Every one of them was requested by users. And every one of them adds code that loads into memory on every page request.
The result is that the same plugin, doing the same job it did in 2020, may consume two or three times the memory in 2026. The website owner changed nothing. They simply applied the updates they were correctly advised to apply — because not updating creates a security vulnerability. The consumption increase arrived silently, bundled with patches they genuinely needed.
This is the trade-off at the heart of the modern WordPress ecosystem. Business owners receive real, tangible convenience — they can update their own content, build their own landing pages, run their own bookings and forms without engaging a developer. That convenience has enormous commercial value. But it is paid for in server resources, and the invoice for those resources does not arrive at the business owner’s desk. It arrives at the hosting provider’s.
4. The Multiplication Problem
For a single website, the fix appears trivial. The hosting provider raises the memory limit from 128 MB to 512 MB, the site works, everyone moves on.
That reasoning holds for one site. It collapses at scale.
A shared hosting server does not host one website. It hosts hundreds. And the memory limit is not a total — it is a per-request allowance. Consider what the arithmetic actually looks like:
- A server hosts 200 websites.
- Each site is allocated 128 MB per page load.
- At any given moment, perhaps 40 of those sites are serving a request simultaneously.
- Peak concurrent memory demand: 5.1 GB.
Now raise every account to 512 MB because page builder themes have made 128 MB unworkable:
- Same 200 websites.
- Each now allocated 512 MB per page load.
- Same 40 concurrent requests.
- Peak concurrent memory demand: 20.4 GB.
The same server, the same customers, the same traffic — and a fourfold increase in peak memory requirement. Nothing about the business relationship changed. The only variable was the weight of the software the customers are running.
Providers cannot simply provision for the theoretical maximum. If every account on a 200-site server simultaneously consumed its full 512 MB allowance, the requirement would be 102 GB. Hosting is deliberately oversubscribed — provisioned on the statistical reality that not every site peaks at once, in the same way a telephone exchange is not built to carry every subscriber calling simultaneously.
Raising limits across the board directly erodes the safety margin that oversubscription model depends on. When it erodes far enough, servers stop failing gracefully and start failing badly — slow response times, request queuing, and in the worst case, cascading outages affecting every site on the machine.
5. Why Memory Is the Expensive Resource
Not all server resources cost the same, and this is where the commercial pressure becomes clear.
Disk space is cheap. Storage costs have fallen continuously for decades. A provider can offer generous storage allowances at almost no marginal cost, which is precisely why hosting plans advertise storage so prominently.
Bandwidth is cheap. Data transfer costs have similarly collapsed as network capacity has expanded.
Memory is expensive — and it has not followed the same curve. Server RAM is a finite physical resource. It cannot be oversubscribed the way storage can. It cannot be compressed or deduplicated in any meaningful way for this workload. When a server exhausts its memory, adding more requires physically installing modules, or provisioning an entirely new machine.
RAM pricing has been under sustained upward pressure since 2024, driven substantially by AI infrastructure demand. Data centre operators building GPU clusters are consuming memory manufacturing capacity at unprecedented volume, and that competition for supply flows directly through to the cost of conventional server hardware. Hosting providers are therefore facing rising memory demand from their customers’ software at the same time as rising memory costs from their suppliers.
6. How Hosting Is Actually Priced
Hosting plans are not priced on what a website might use. They are priced on a modelled base load — the provider’s calculated average consumption per account — with defined limits acting as the guard rails that keep that model honest.
The commercial model looks approximately like this:
- Estimate average memory, CPU and I/O consumption per hosted site
- Calculate how many sites can safely share one server
- Divide the total cost of that server — hardware, power, cooling, licensing, backup, monitoring, staff — by that number
- Add a margin
- Publish the plan price
Every element of that calculation depends on the consumption assumption holding true. When the actual consumption per site rises by a factor of three or four, the number of sites that fit safely on a server falls proportionally. The per-site cost rises proportionally. And the published price no longer covers the cost of delivery.
Providers have three options, and only three:
- Absorb the increase and accept reduced margin
- Enforce hard limits and charge for any increase above them
- Raise prices across the entire customer base
Most of the industry is now doing some combination of the second and third. This is why hosting customers increasingly encounter automatic plan upgrades triggered by resource usage, and why the low-cost shared hosting tier has been quietly disappearing across the market.
7. The Direction of Travel: AI-Assisted Development
There is a further factor that will accelerate all of this considerably.
AI coding tools have dramatically lowered the barrier to building WordPress plugins and themes. A developer who previously needed weeks to build a feature can now produce a working version in hours. Someone with limited coding background can produce a functional plugin at all. The volume of plugins and themes entering the ecosystem is going to increase substantially, and the pace at which existing ones acquire new features will increase with it.
The implications for resource consumption cut in both directions, and it is worth being honest about that.
Working against efficiency: AI-generated code is optimised for working, not for being lean. It tends toward verbosity, loads libraries generously, and does not naturally make the trade-offs an experienced developer makes when memory is constrained. Feature development becomes cheap, which means more features get built — and every feature is more code loading into memory. Developers under less time pressure to write economically will not write economically.
Working for efficiency: the same tools can identify inefficient code, suggest optimisations, and flag memory-heavy patterns during development. A developer who chooses to use them that way can produce leaner software than they could unaided.
The determining factor is not the technology. It is whether the market rewards efficiency. At present, it broadly does not — plugins compete on features, on reviews, on marketing, and almost never on resource consumption. There is no visible metric a purchaser can compare. Until the ecosystem makes memory efficiency something buyers can see and choose, the commercial incentive points squarely toward more features and heavier code.
Our expectation is that the current trend continues and steepens. Businesses should plan on the assumption that WordPress hosting requirements — and therefore WordPress hosting prices — will continue to rise over the next several years.
8. Recommendations for Website Owners
None of this is cause for alarm, and none of it requires urgent action. It does warrant some discipline.
- Audit your plugins annually. Most sites carry plugins that are deactivated in practice, superseded by functionality now built into the theme, or duplicating one another. Removing them reduces memory consumption, improves load times, and reduces security exposure — every plugin is a potential entry point.
- Prefer one plugin doing three jobs over three plugins doing one each. Consolidated plugins load a single framework rather than three overlapping ones.
- Delete, do not merely deactivate. A deactivated plugin does not consume memory, but its files remain on the server and remain a vulnerability if they contain a known flaw.
- Question whether you still need the page builder. Page builders earn their keep during design and frequent redesign. If a site’s appearance has been settled for two years and changes are rare, a conventionally built theme delivers the same result at a fraction of the resource cost, with materially better performance.
- Keep everything updated regardless. Consumption may creep upward with updates, but running outdated code is a far greater risk than running heavy code. Update, then manage the weight separately.
- Watch for intermittent white screens. Sporadic critical error messages — present on some pages, absent on others, appearing and clearing without intervention — are the classic signature of a memory ceiling being reached. They are not random, and they will not resolve themselves.
- Talk to your hosting provider before changing limits yourself. Most control panels permit the memory limit to be adjusted directly. Doing so without notice will typically trigger an automated resource alert at the provider’s end, because the same signature is produced by a compromised site consuming resources maliciously. A brief note avoids an unnecessary investigation, and in some cases avoids an automatic plan upgrade.
9. Conclusion
The WordPress ecosystem has delivered something genuinely valuable: it has put control of a business’s own website into the hands of the business. That is worth defending, and nothing in this article argues against it.
But convenience is never free — it is simply billed somewhere the user cannot see. In this instance it is billed in server memory, and the invoice lands with hosting providers who have limited means of passing it back to the plugin and theme developers whose design decisions created it.
The result is a market where hosting prices must rise, not because providers have become greedier or servers more expensive to run, but because the software running on them has grown heavier by an order of magnitude while the price expectation set in 2015 has barely moved.
For business owners the practical response is straightforward: understand that your website has a resource footprint, keep that footprint tidy, and treat plugin discipline as part of routine maintenance rather than something to address only when the site breaks. A well-maintained site with twelve carefully chosen plugins will outperform, outlast and cost less to host than a neglected one carrying thirty-five.
Approved Systems has provided web hosting, WordPress support and website maintenance for Australian businesses since 2006. If your site is showing intermittent errors, running slowly, or has simply accumulated more plugins than anyone can now account for, we are happy to take a look.