Skip to content
Logo MandaMANDA.

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.

Diagnosis

Isolated patchOne score or visible symptom
Audit + optimizationLogs, network, functions, SQL and egress tied back to code

Performance

Isolated patchOne-off compression or removal
Audit + optimizationRendering, caching and data optimized together

Cloud costs

Isolated patchReduction is difficult to explain
Audit + optimizationFewer calls, less compute and less transfer, all measured

Fresh data

Isolated patchCaching disabled as a precaution
Audit + optimizationCache lifetime chosen around the business requirement

Regression risk

Isolated patchLimited manual checks
Audit + optimizationFunctional tests and before-and-after measurements

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
Website Performance Optimization Service | Manda