Website performance audit & cloud cost optimization
Your website already works, but pages are slowing down, infrastructure usage is rising or Vercel and Supabase quotas are disappearing too quickly. I audit the full request path, from browser to database, then fix the structural causes across rendering, caching, CMS, APIs, images and polling. The goal is not just a better score: it is a faster, more reliable and less expensive product to operate.
Last updated:
Measured audit
Logs, metrics, network and real requests.
Web performance
Rendering, caching, images and Core Web Vitals.
Controlled costs
Egress, functions, APIs and databases.
Efficient queries
Fewer redundant reads and duplicate calls.
Reliable architecture
ISR, CDN and targeted invalidation.
Verified results
Before-and-after tests and guardrails.
Audited and measured case study
A 25 MB database was generating 5.5 GB of egress
Data volume was not the problem. The architecture fetched the same content again on every page and crawler request.
Initial alert
5.5 GB
Egress quota reached while the database itself held only about 25 MB.
12,206
global content reads
18,261
project queries by slug
23,658
visitor feed reads
Before: invisible cost
Dynamic rendering on every route
CMS and fallbacks fetched on every visit
Browser polling reaching the database directly
After: controlled architecture
Pre-rendered pages with targeted revalidation
Remote CMS content enabled only when needed
Shared CDN cache and on-demand GA loading
696 B
per visitor response
10 -> 1
HTTP calls to SQL query
30 s
maximum dashboard freshness
Measurements from the manda-ia.com audit. Exact gains depend on traffic, hosting and the audited site's architecture.
What is this service called?
This is technical optimization for an existing website, also known as a website performance audit or cloud architecture optimization. It goes beyond a PageSpeed report: I investigate why the product consumes CPU, egress, serverless functions or database reads, then fix the system creating those costs.
It is useful when the product already works but pages are slowing down, free-tier quotas disappear unexpectedly, crawlers trigger expensive processing or every visit reloads the same data.
What I actually audit
I start from verifiable symptoms: response times, network waterfalls, Core Web Vitals, Vercel logs, Supabase metrics, egress volume, function frequency, response size and SQL queries. I then connect every cost to the code path that triggers it.
The analysis covers Next.js rendering modes (static, dynamic and ISR), browser and CDN caching, calls to Payload or another CMS, data fallbacks, polling, images, server-side libraries and cache invalidation after publishing.
The manda-ia.com case: data volume was not the problem
The database held about 25 MB, yet the organization had exceeded 5.5 GB of egress. The audit showed that public pages were dynamically rendered and fetched several remote sources on every request. Crawlers, visitors and refreshes repeatedly triggered the same work.
I replaced those reads with pre-rendered pages and revalidation, made the remote CMS opt-in in production, added shared caches, limited visitor dashboard polling to visible tabs and moved its cache to the Vercel edge. The dashboard stays less than 30 seconds behind without querying Supabase for every visitor.
My four-step optimization method
1. Measure a baseline before changing anything. 2. Locate the routes, requests and components responsible for usage. 3. Fix the rendering mode, remove redundant reads, shrink responses and cache at the right layer. 4. Verify the metrics, data freshness and user journeys to catch regressions.
I document both changes and trade-offs. Your team knows what was fixed, why it mattered and which metrics to keep watching.
Deliverables, timeline and rate
You receive a prioritized diagnosis, a map of technical cost drivers, the agreed code changes, before-and-after measurements and guardrails to prevent the issue returning. A focused audit can take a few days; a full optimization depends on the number of routes, providers and data flows.
My standard rate is EUR 350/day, with scope and quote agreed before work starts. The engagement can stand alone or become part of continuous product improvement.
Quick patch or structural optimization?
Both can improve a score in the short term, but only end-to-end analysis reduces infrastructure usage and risk sustainably.
| Criterion | Isolated patch | Audit + optimization |
|---|---|---|
| Diagnosis | One score or visible symptom | Logs, network, functions, SQL and egress tied back to code |
| Performance | One-off compression or removal | Rendering, caching and data optimized together |
| Cloud costs | Reduction is difficult to explain | Fewer calls, less compute and less transfer, all measured |
| Fresh data | Caching disabled as a precaution | Cache lifetime chosen around the business requirement |
| Regression risk | Limited manual checks | Functional tests and before-and-after measurements |
Diagnosis
Performance
Cloud costs
Fresh data
Regression risk
The goal is not to cache everything. It is to recompute only what truly needs to change, when doing so creates value for the user.
Frequently asked questions
How is this different from a PageSpeed audit?
PageSpeed mainly evaluates loading experience in the browser. My audit also connects that experience to server costs: Next.js rendering, API calls, Vercel functions, Supabase egress, SQL queries, CMS reads and caching strategy.
Can you optimize a live website without rebuilding it?
Yes. I start with high-impact, low-risk changes and expand only when the architecture requires it. The purpose is to improve the existing product, not force an unnecessary rebuild.
Do you only work with Vercel and Supabase?
No. This case uses Vercel, Supabase, Next.js and Payload, but the method applies to other hosts, databases, CMS platforms and APIs. Tools vary; measurement, caching and request-reduction principles remain the same.
Can caching show stale data?
A well-designed cache has an appropriate lifetime and invalidation strategy. Editorial pages can revalidate after publishing; a near-real-time dashboard can use a shared 30-second cache. Freshness is selected according to the business requirement.
What results should I expect?
Results depend on traffic and architecture. The measurable targets are fewer requests and transfers, lighter responses, faster loading and more headroom before quotas. I provide before-and-after values instead of a generic promise.
Ready to start your project?
Let's discuss your needs in a free 30-minute discovery call.
Start a Project