Performance Budgets for Hundreds of Microapps on Shared Hosting

UUnknown

2026-02-06

9 min read

How to set and enforce performance budgets for hundreds of microapps on shared hosting—quotas, CDN, caching, image optimization, monitoring, SLA.

Stop slow microapps from dragging your platform down — even on shared hosting

Managing hundreds of small websites and microapps on a single shared host is common in 2026: internal tools, client microsites, no-code builds, and fleeting apps proliferate. The pain is predictable — one heavy app spikes CPU, another floods I/O with large images, and suddenly UX across the whole host degrades. This guide shows how to set and enforce performance budgets across many microapps using quotas, CDN rules, caching strategies, automated image optimization and alerting so that user experience and SLA commitments stay consistent.

Executive summary — what you’ll get

Concrete performance budget targets for hundreds of microapps
Deployment-time enforcement with CI (Lighthouse CI, gating)
Runtime controls on shared hosting (LVE, cgroups, PHP-FPM pools, I/O limits)
CDN and caching rules that scale (surrogate keys, edge logic)
Automated image optimization patterns for bandwidth reduction
Monitoring, SLO/SLA mapping, and alerting playbook

Why this matters in 2026

By late 2025 the landscape shifted: widespread adoption of HTTP/3 (QUIC), improved image codecs (AVIF and wider AVIF2 tooling), and mature edge functions from CDNs mean you can offload significant work to the edge. At the same time the number of microapps has exploded — non-developers using AI-assisted tools now publish dozens of small apps that are hosted on the same infrastructure. Without strict, automated budgets and runtime quotas, shared hosting platforms experience noisy-neighbor problems that break SLAs.

Define practical performance budgets (per app and host)

Performance budgets must be measurable and realistic. Use both user-centric metrics and resource budgets:

User-centric metrics (target per page): LCP < 2.5s, FID/INP < 100ms, TTFB < 300ms, Total page weight < 300 KB (target 150–250 KB for microapps), 3rd-party JS < 50 KB.
Resource quotas (host-facing): CPU share < X% per app, memory limit, disk quota, IOPS quota, inodes limit, bandwidth cap.

Example budgets (per microapp)

JS bundle (initial): < 75 KB gzipped / brotli
Images (total): < 150 KB per page
HTML: < 30 KB
Requests: < 30 requests initial load
TTFB SLA: < 300 ms 95th percentile

Host capacity math

Calculate host allocations up-front. If you have 500 microapps and a host provides 16 vCPU and 32 GB RAM, allocate conservative per-app shares so sporadic spikes won’t exceed capacity. Example simple approach:

Reserve 40% of CPU for system and background processes => 16 vCPU * 0.6 = 9.6 vCPU available.
Per-app CPU share = 9.6 / 500 ≈ 0.019 vCPU (~20 millicores). Increase for apps with higher needs.
Apply disk quota: 5 GB per app with inode limit of 50k files, or a lower cap for microapps.

Enforce budgets at deploy-time (CI gates)

Stop regressions before they reach production. Implement automated checks in your CI pipeline.

Key tools

Lighthouse CI or Lighthouse Budgets integration
WebPageTest scripted runs and API
Bundle analysers (esbuild/rollup/webpack plugin outputs)

Sample Lighthouse CI config (budget)

{
  "ci": {
    "collect": {"url": ["https://example.microapp.local"]},
    "assert": {
      "assertions": {
        "largest-contentful-paint": ["error", {"maxNumericValue": 2500}],
        "total-byte-weight": ["error", {"maxNumericValue": 300000}],
        "script-total-size": ["warn", {"maxNumericValue": 75000}]
      }
    }
  }
}

Fail the deployment when assertions are exceeded. For hundreds of microapps, run CI jobs in parallel on a build farm or use sampling for lower-traffic apps.

Runtime enforcement on shared hosting

Shared hosts must enforce resource quotas to avoid noisy neighbors. Here are production-grade options.

1. LVE / CloudLinux (or cgroups equivalents)

Use CloudLinux LVE or OS-level cgroups to limit CPU, memory, processes and I/O per user/site.
Set per-site CPU% and IO limits; failing apps are throttled not killed.

2. PHP-FPM pools & worker limits

Per-app PHP-FPM pools with pm.max_children and memory_limit tuned.

Example php-fpm pool settings for a microapp:

[microapp]
user = microapp
pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
php_admin_value[memory_limit] = 128M

3. Filesystem quotas

Set disk and inode quotas per account; enforce automatic cleanup policies for tmp files and user uploads.

4. Network and bandwidth caps

Apply per-site egress caps and rate limiting for abusive patterns. Use tc or host-level bandwidth shaping where available.

5. Edge protections and circuit breakers

Use CDN edge logic (Cloudflare Workers, Fastly Compute@Edge) to enforce connection and payload size limits and to return lightweight fallback when origin is overwhelmed.

CDN and caching rules that scale

Smart CDN rules are the most effective way to protect origin resources and keep UX consistent.

Edge cache strategy

Cache HTML at edge for low-traffic microapps where content is semi-static. Set short TTLs (e.g., 60s–5m) and use surrogate keys for selective invalidation.
Static assets (CSS/JS/images) should be cacheable for long TTLs (30d) with cache busting via content hash.

Surrogate keys and purge API

Group assets by microapp using surrogate keys so you can purge a single microapp's cache without flushing the global cache.

Surrogate-Key: app-12345
Cache-Control: public, max-age=2592000, s-maxage=2592000

Edge rules and transformations

Implement edge rules to rewrite Accept headers for automatic image format negotiation (AVIF/WEBP), and to strip heavy query parameters from cache keys.
Use edge functions to limit request body size and to serve compressed placeholders when origin is degraded.

Sample Cloudflare Page Rule / Worker logic

// Pseudocode: Normalize cache key
addEventListener('fetch', event => {
  const url = new URL(event.request.url);
  url.search = ''; // drop tracking params
  const cacheKey = `${url.origin}${url.pathname}`;
  event.respondWith(handle(cacheKey, event.request));
});

Image optimization at scale

Images are the biggest bandwidth offender. In 2026, automated image pipelines are table stakes.

Use an image CDN or on-the-fly transforms

Offload image conversion and resizing to an image CDN or dedicated service (imgproxy, Thumbor, Cloudflare Images, Fastly Image Optimizer).
Serve AVIF where supported, fallback to WebP or optimized JPEG/PNG. Let the edge pick the best format via Accept negotiation.

Responsive images and client hints

Generate srcset and use width descriptors, and use Client Hints or CSS container queries to reduce over-fetching.

Automation recipes

Example Node.js conversion task using libvips (sharp/libvips preferred for production speed):

// convert-and-optimize.js (pseudo)
const sharp = require('sharp');
async function optimize(file){
  await sharp(file)
    .resize({ width: 1200 })
    .avif({ quality: 75 })
    .toFile(file.replace(/\.jpg$/, '.avif'));
}

Run this as a post-upload hook or integrate into CI so all uploaded images are stored in optimized variants behind the image CDN. The example uses sharp / libvips for speed in production pipelines.

Caching strategy: combining local & edge caches

Design a layered cache that keeps origin load minimal:

Browser cache: long TTLs for static assets; use cache-control and immutable where appropriate.
Edge cache: cache HTML where possible; use short TTLs for dynamic pages and surrogate keys for targeted purge.
Origin cache: Nginx/varnish/fastcgi cache to absorb sudden bursts; set conservative size limits and eviction policies.

Example Nginx fastcgi cache snippet

fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=microapp_cache:100m inactive=10m max_size=2g;
server {
  location ~ \.php$ {
    fastcgi_cache microapp_cache;
    fastcgi_cache_key $scheme$host$request_uri;
    add_header X-Fastly-Cache $upstream_cache_status;
  }
}

Monitoring, alerting and SLA integration

Automated enforcement requires observability that maps to your SLOs and SLA.

Essential signals

RUM: track LCP, INP/FID, TTFB per app (e.g., Boomerang, New Relic RUM, OpenTelemetry RUM)
Synthetic tests: scheduled Lighthouse/WebPageTest runs
Infrastructure metrics: CPU, memory, I/O, network per account (Prometheus exporters)
Edge cache hit ratio and origin request rate

Alerting strategy

Define SLOs that tie to budgets: e.g., LCP < 2.5s 95% — alert at 90%
Per-app alerts for budget violations (automated email/Slack/PagerDuty)
Host-level alerts for noisy neighbor behaviour (sustained CPU > threshold from single account)

Sample Grafana alert rules

// Pseudocode
ALERT HighAppCPU
IF sum by(app)(cpu_usage_seconds_total{job='node_exporter'}) / sum by(app)(cpu_quota) > 0.8
FOR 5m
LABELS {severity='warning'}
ANNOTATIONS {summary='App {{ $labels.app }} at 80% CPU quota'}

Operational playbook — how to respond

Auto-throttle: when an app crosses CPU or I/O threshold, reduce PHP-FPM workers and serve cached versions or error-first fallbacks from the edge.
Notify owner: send automated diagnostics with links to RUM traces, synthetic run details, and a suggested remediation list.
Temporary quarantine: when abuse is suspected (e.g., bulk image uploads or crawler loops), automatically suspend heavy operations and switch to read-only mode.
Escalate: if SLA impacts are detected, notify platform ops and the account owner; apply temporary rate limits until remediation.

Case study: 350 microapps on a shared cluster (example)

Summary: In late 2025 we migrated 350 internal microapps from unmanaged shared hosting into a constrained shared cluster with LVE + edge CDN rules. Before: average LCP 2.9s, median bandwidth per page 540 KB, origin CPU spikes 3–4x causing degraded performance across the host. After enforcing budgets and automations:

Average LCP improved to 1.5s (47% reduction)
Median page weight fell from 540 KB to 220 KB (59% reduction)
Edge cache hit ratio rose to 87%, origin requests dropped 70%
CPU and I/O incidents fell by 82%, meeting SLA uptime targets

Key levers: CI gating (Lighthouse), automatic image conversion to AVIF at upload, per-app LVE quotas, and edge worker rules for cache-key normalization and lightweight fallbacks.

Checklist for implementation

Set per-app user-centric budgets (LCP, TTFB, page weight)
Add Lighthouse CI or WebPageTest checks to CI pipeline
Implement OS-level quotas (CloudLinux/cgroups) and tune PHP-FPM pools
Deploy an image CDN or image transformation pipeline and enable AVIF/WebP delivery
Establish edge cache rules with surrogate keys and purge APIs
Instrument RUM, synthetic, and infrastructure metrics; map to SLOs
Create alerting playbook and automated remediation steps

Future-proofing: predictions for 2026 and beyond

Expect continued edge compute growth: more logic will move to CDN edge functions (per-request caching logic, small transforms, A/B gating). Image codecs will continue to improve and hardware accelerated AVIF transforms will be common. That makes it easier to keep heavy work off your origin — but it also raises the bar for automation and enforcement: more microapps will be created, and platforms that lack CI gating, strict quotas and smart CDNs will face larger noisy-neighbor problems.

"Enforcement is not just a cost-control tool — it's an experience guarantee."

Final takeaways

Budgets are both UX targets and resource caps. Define them in user terms (LCP, TTFB, weight) and in infrastructure terms (CPU, I/O, disk).
Automate enforcement at deploy time (CI) and at runtime (quotas, edge rules, circuit breakers).
Offload to the edge — image transforms, cache logic and fallbacks drastically reduce origin pressure.
Monitor proactively and tie alerts to SLOs so you maintain SLAs across hundreds of microapps.

Call to action

Ready to protect your shared hosting platform and ensure consistent UX across hundreds of microapps? Start with a performance budget pilot: pick 10 representative microapps, add Lighthouse CI checks, enable an image CDN, and apply per-app quotas for a two-week trial. If you'd like a checklist or a runnable GitHub Actions + Lighthouse CI starter, request the template from our engineering team and we’ll share the exact configs used in the case study above.

Unknown

Contributor

Senior editor and content strategist. Writing about technology, design, and the future of digital media. Follow along for deep dives into the industry's moving parts.

Up Next

How to Architect Batch AI Processing Pipelines for SaaS in 2026

•10 min read

From Photos to Search: How AI Personalization is Revolutionizing User Experience

•9 min read

Buyer’s Guide: Choosing a Cloud‑Ready Streaming Mic & Rig for Creators (2026)

2026-02-15T10:15:15.668Z