Skip to content
Logo MandaMANDA.
Web AppsWeb PerformanceNext.jsCore Web VitalsTailwind CSSVercel

manda-ia.com performance optimization

Lighthouse audit, Next.js architecture and cloud costs

Technical case study of an existing production Next.js portfolio. The audit connects Lighthouse measurements, the critical rendering path, JavaScript, generated Tailwind CSS, Supabase reads, dynamic rendering and Vercel functions to the responsible code paths. Public pages were moved to pre-rendered content, Payload became optional, shared caching was introduced and the visitor dashboard stayed fresh without querying the database on every visit. August 26, 2026 snapshot: 99/100 desktop, 0.5 s LCP and zero CLS; the 80/100 mobile profile still identifies JavaScript work to reduce.

Production performance audit

Connecting PageSpeed, CSS architecture and cloud costs in one diagnosis

manda-ia.com was already working and gaining traffic, but Vercel and Supabase quotas exposed an expensive architecture. I audited the complete request path from browser to database, then separated three problems that are often mixed together: visible loading speed, client-side JavaScript and CSS work, and repeated server reads. The result is a more static foundation, shared caching and a dated Lighthouse proof that also states the next mobile improvement honestly.

Desktop Lighthouse
99/100, 0.5 s LCP, 30 ms TBT
Mobile Lighthouse
80/100, 2.4 s LCP, 680 ms TBT
Visual stability
CLS 0 on both profiles
Snapshot
August 26, 2026, 58 requests, about 653 KiB

Start with a reproducible baseline

A score alone is not an audit. The Lighthouse snapshot records the URL, date, mobile or desktop profile and the metrics composing the result. Lab data reproduces a controlled scenario; it remains distinct from field Core Web Vitals collected from real visitors.

Desktop reaches 99/100 with a 0.5-second LCP and 30-millisecond TBT. Mobile remains at 80/100 with 680-millisecond TBT. This gap prevents an artificial conclusion: initial rendering is strong, while the main thread still runs too much JavaScript under simulated mobile conditions.

Audit Tailwind by its output, not its reputation

The CSS audit inspects what actually reaches the browser: transferred size, unused rules, stylesheet order, fonts, critical styles and the team's ability to maintain components. Tailwind can ship compact CSS when compiled correctly, but it does not remove the need to inspect dependencies, variants and accumulating conventions.

Benchmarking another CSS approach only makes sense with the same screens, content and test conditions. I compare weight, render blocking, rule repetition and migration cost before recommending Tailwind, CSS Modules, modern native CSS or a targeted combination.

The server problem hidden behind a fast page

The Supabase database held about 25 MB, yet the organization exceeded 5.5 GB of egress. Stored volume did not explain the transfer. Public pages were dynamically rendered and re-read the CMS, fallbacks and some data on every request, including crawler visits.

Public content was pre-rendered, Payload became optional in production and frequent reads were replaced with shared caching. The visitor dashboard keeps a maximum freshness delay of 30 seconds while returning a lightweight response without a direct Supabase read for every browser.

Fix the existing product without breaking it

The order of changes matters as much as their nature. I begin with high-impact, low-risk corrections: static rendering for editorial content, appropriate caching, removal of duplicated calls, deferred third-party scripts and correctly sized images. Deeper changes only follow when measurements justify them.

Each correction is checked against real journeys, network failures, localized pages and mobile behaviour. This method improves an existing production site without turning the audit into a forced rebuild.

Apply the same discipline to business websites

Business websites use this method from the design stage: render statically where possible, load media for the actual viewport, minimize client components and measure the deployed build. Performance becomes an architecture constraint rather than a cosmetic task before delivery.

For hotels, restaurants, travel agencies or rental companies, that speed directly protects mobile conversion. The page must remain light when a visitor compares an offer, reads a menu, checks availability or completes an enquiry.

Why is the mobile score lower than desktop?

The mobile Lighthouse profile simulates a constrained device and network. The 680 ms TBT mainly signals JavaScript work on the main thread; it becomes the next measurable target instead of being hidden behind the desktop score.

Does a Lighthouse score prove Core Web Vitals?

No. Lighthouse provides a reproducible lab measurement. Field Core Web Vitals come from real users and must be monitored separately through CrUX, Search Console or a RUM solution.

Should Tailwind be removed to improve performance?

Not automatically. The generated CSS, critical rendering path and maintainability must be measured. Changing frameworks without a comparable benchmark can cost more than it returns.

Can an existing website be audited without rebuilding it?

Yes. The diagnosis prioritizes high-impact, low-risk changes. A rebuild is recommended only when the existing architecture genuinely blocks the required corrections.