Web & Backend Performance Optimisation

Core Web Vitals are Google's metrics for user experience: Largest Contentful Paint (LCP - how fast the main content loads), Interaction to Next Paint (INP - how quickly the page responds to input), and Cumulative Layout Shift (CLS - how much content shifts unexpectedly). Google uses them as a ranking signal, and they are strongly correlated with conversion rates. A 1-second LCP improvement increases conversions by up to 8% on e-commerce sites.

We measure against real user data (RUM) using the web-vitals library or a tool like Datadog RUM, not just synthetic Lighthouse scores. Synthetic scores are useful for direction but do not reflect what real users on real devices and connections experience. We set baseline metrics by percentile (p50, p75, p95) for each Core Web Vital and API endpoint before changing anything.

The most common LCP culprits are large unoptimised hero images, render-blocking JavaScript or CSS, slow server response times (TTFB), and missing preload hints for the LCP resource. We identify the actual LCP element in production using Chrome DevTools and RUM traces, then target the specific issue rather than applying generic optimisations.

We use webpack-bundle-analyzer or Next.js Bundle Analyzer to find the largest contributors to bundle size. Common fixes include replacing heavy libraries with lighter alternatives (e.g. date-fns instead of moment.js), converting route-level components to dynamic imports, tree-shaking icon and component libraries by switching from barrel exports to direct imports, and moving server-only code out of the client bundle.

We enable slow query logging (queries over 100ms) and run EXPLAIN ANALYSE on the heaviest queries to understand the query plan. We look for sequential scans on large tables, missing indexes, inefficient join orders, and N+1 patterns from the ORM. We then add targeted indexes, rewrite inefficient queries, and verify the improvement with before/after EXPLAIN ANALYSE output and production query logs.

We apply caching at multiple layers: HTTP cache headers (Cache-Control, ETag) for browser and CDN caching of static assets and API responses; Redis for server-side caching of expensive database queries and computed results; CDN edge caching for HTML pages using stale-while-revalidate; and in-memory caches for frequently accessed configuration that does not change per request. The correct layer depends on the data's staleness tolerance.

We convert images to WebP and AVIF (typically 30-60% smaller than JPEG at the same quality), add explicit width and height to eliminate CLS, implement lazy loading for below-fold images, and add resource hints (preload) for the LCP image. For dynamic images we use Cloudinary or imgix to serve correctly sized images based on the requesting viewport. We also audit for images served at 2x the display size.

Yes. For Next.js applications we review the rendering strategy per page - static generation, ISR, or server-side rendering - and ensure the right approach is used based on data freshness requirements. We also optimise server response time by reducing middleware overhead, moving expensive computations to build time, and implementing streaming with React Suspense to allow above-fold content to render before data-dependent sections.

We use k6 to write load test scripts that simulate realistic user behaviour - not just GET requests to the homepage. Scenarios include login, browsing, and checkout flows. We run tests at increasing concurrency levels (1x, 5x, 10x current peak) and measure latency percentiles, throughput, and error rates. We identify the breaking point and the specific resource (CPU, database connections, memory) that saturates first.

Performance and load work is a module in our estimate at 50-110 hours, which is where a focused audit and the first round of fixes land. A full engagement - load testing, caching architecture, image pipeline and database tuning - takes 4-8 weeks depending on the size of the application. We sequence the work so the first measurable improvement lands in the first week, not at the end.

Results vary by starting point, but common outcomes include: LCP improving from 4s to under 2.5s (passing Core Web Vitals), API p95 latency dropping 40-70% after query optimisation, JavaScript bundle size reducing 30-50% through code splitting and dependency trimming, and cloud costs dropping 20-30% after right-sizing and caching reduce compute demand. We set specific targets before starting and measure against them.

Yes. We configure real user monitoring with alerts for Core Web Vital regressions, API latency spikes, and error rate increases. We also set up a performance budget in CI that fails the build if a new dependency would push the JavaScript bundle over an agreed size limit. For clients on retainers we include a monthly performance review covering trends and emerging bottlenecks.