---
title: "I Will profile your React or Next.js app and make it faster, with numbers"
url: https://zinnhub.com/zinns/i-will-profile-your-react-or-next-js-app-and-make-it-faster-with-numbers/
description: "Your React or Next.js app got slower one release at a time. The bundle grew, images ship at full size, a third-party script blocks the first paint, a list re-renders on every keystroke. I measure which of those actually costs your users time, then fix the ones worth fixing."
published: 2026-09-29T12:28:30+00:00
modified: 2026-09-29T13:37:10+00:00
language: en-GB
---

# I Will profile your React or Next.js app and make it faster, with numbers

Order this if you think slow pages are costing you signups or search traffic and you want to keep the app you have. React and Next.js already ship most of what a fast app needs, so the gains come from using those tools well rather than switching stacks.

You get numbers, not adjectives: LCP, CLS, INP and bundle size per route, measured before and after on the same throttled connection, in one table.

Starter is the audit of one page: the runs, the findings ranked by payoff, no code changed. Standard starts from that audit and spends the rest of the time on the fixes that move those numbers. Advanced covers up to 5 routes, tunes rendering and caching, and leaves a bundle budget in CI so the next release cannot quietly undo the work.

Work happens on a branch in your repository, commit by commit, each with its reason. Nothing is deployed by me unless you ask for it.

No calls. Everything in writing, including the measurements that disagree with me.

Steps for completing your project
1. Measure what your users actually get – Lighthouse on your live pages and a React profiler session on the slow ones, on a throttled connection. LCP, CLS, INP and bundle size per route, written down before anything is touched.
2. Find what costs the most – The bundle and the network waterfall: what ships that nobody uses, what blocks the first paint, which components re-render and why. Every finding carries an estimated saving in milliseconds or kilobytes.
3. Fix it, biggest win first – Code splitting, image and font handling, render-blocking work, memoization where the profiler asks for it, data fetching moved off the critical path. One commit per change, each with its reason.
4. Measure again, side by side – The same runs on the changed build: before and after in one table, per route and per metric. If a change made something worse, the table says so and the change goes back out.
5. Handover in your repository – A branch or patch in your repo, the report, and an honest list of what I did not do and what it would be worth. Deployment stays in your hands.