Website performance audit & cloud cost optimization

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.

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 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. The intervention is documented in the complete case study.

The audit does not stop at the backend. I measure the CSS actually transferred, unused styles, component dependencies, fonts, the LCP image and stylesheets blocking render. With Tailwind, the goal is not to defend the framework: it is to inspect what compilation produces, whether classes remain maintainable and whether another CSS strategy would create a measurable gain.

I then connect the critical rendering path to JavaScript running before interaction: client components, hydration, third-party scripts, global listeners and libraries loaded too early. On the August 26, 2026 Lighthouse snapshot, manda-ia.com reaches 99/100 on desktop, with a 0.5 s LCP and zero CLS. The 80/100 mobile score and 680 ms TBT identify the next clear target: reducing main-thread JavaScript work.

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.

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.