Why Charging Drupal Hosting by Page Views Isn’t Fair
For years, Drupal hosting has been priced using metrics like page views or unique visitors. On paper, it sounds reasonable: more traffic means more cost.
In reality, this model is often unfair, inaccurate, and expensive for clients, especially for organizations managing multiple Drupal sites.
Let’s break down why and what a better alternative looks like.
The Problem with Page Views–Based Pricing
Page views are an outcome, not a resource.
They don’t tell you:
- How efficiently the site is built
- Whether traffic is cached or uncached
- How much CPU, memory, or database capacity is actually being used
- If traffic comes in spikes or steady flows
Two Drupal sites with the same number of page views can have completely different infrastructure costs.
Example: Two Sites, Same Traffic — Very Different Costs
- Site A
- Well-cached
- Optimized images
- Minimal custom logic
- Efficient database queries
- Site B
- Poor caching
- Heavy authenticated traffic
- Complex views and queries
- Inefficient cron jobs
Both get 500,000 page views/month.
Traditional hosting charges them the same.
But Site B might consume 5–10× more resources than Site A.
That’s not fair pricing, it’s guessing.
The Bigger Problem: Organizations with Multiple Drupal Sites
Now let’s look at a more realistic scenario.
The Organization Use Case
An organization runs:
- A main corporate website
- A marketing campaign site
- A documentation site
- Several microsites for events or regions
Most of these sites:
- Are low-traffic most of the time
- Have traffic spikes only during campaigns
- Sit idle for long periods
What Page View Pricing Does
With page-view-based plans:
- Each site needs its own traffic buffer “just in case”
- Traffic spikes on one site push the whole account into overage fees
- Teams pay for capacity they don’t use
The result?
Organizations spend more time managing limits than improving their sites.
Why Well Managed Cloud Infrastructure Changed the Rules
Modern cloud infrastructure doesn’t work like traditional servers.
Resources can now:
- Scale up only when needed
- Scale down to zero when idle
- Be isolated per site
- Be shared efficiently at the organization level
But many hosting providers kept old pricing models on top of new infrastructure.
FlexSite does the opposite.
A Better Model: Pricing Based on Optimized Resources
Instead of charging for traffic, FlexSite focuses on what actually costs money in the cloud:
- CPU usage
- Memory consumption
- Storage
- Database resources
What This Means in Practice
For a Single Site
- A fast, well-optimized site costs less
- Traffic spikes don’t automatically mean higher bills
- Caching and performance improvements are rewarded
For Organizations with Multiple Sites
- Busy sites get the resources they need without affecting others
- Costs reflect real usage, not estimates
- Infrastructure becomes predictable and transparent
You pay for what you use, not what you might use.
Why This Is Fairer for Clients
A resource-based model:
- Encourages good engineering practices
- Aligns cost with actual infrastructure usage
- Avoids surprise overage fees
- Scales naturally as organizations grow
Most importantly, it treats Drupal sites as what they really are:
Applications running on cloud infrastructure—not traffic counters.
The FlexSite Approach
FlexSite is built specifically for Drupal and modern cloud environments:
- Each site runs in isolated, optimized infrastructure
- Resources can be assigned based on real demand when needed
- Organizations manage multiple sites without penalty
- Non-technical teams don’t have to think about DevOps limits
No traffic caps.
No page view anxiety.
Just efficient Drupal hosting.