Next.js 16 Performance Audit: Is Your Tool Site Loading Under 1 Second?

Performance on the web has always mattered. But 2026 is the year it stopped being a best practice and became a ranking signal with teeth. Google's updated Core Web Vitals thresholds — stricter LCP, the full switch from FID to INP, tighter CLS requirements — mean that sites that were "passing" in 2024 may now be in the "needs improvement" zone without a single line of code changing.

For tool sites specifically — calculators, converters, generators, formatters — the stakes are higher than average. These sites get traffic from users who need a fast answer. They open a tab, type something, get a result, close the tab. The entire value proposition is speed and simplicity. A tool site that takes three seconds to load has already failed before the user has typed a single character.

This is the full audit I ran on a production multi-tool site. Not a hypothetical checklist. A real codebase, real Lighthouse scores, real decisions about what to fix and in what order. The target was sub-1-second FCP on desktop, sub-1.5-second LCP on mobile, INP under 100ms, and CLS at zero. Here's how it went.

---

Why the 2026 Core Web Vitals Update Actually Matters This Time

Google has updated Core Web Vitals thresholds before and the industry mostly shrugged. The 2026 update is different for two reasons.

First, INP (Interaction to Next Paint) is now fully replacing FID (First Input Delay) as the interactivity metric, and the two measure fundamentally different things. FID measured the delay before the browser started processing an interaction — a metric that could be gamed by deferring JavaScript. INP measures the full duration from user interaction to the next frame painted, including processing and rendering time. A site that passed FID comfortably can fail INP significantly with the exact same JavaScript.

Second, the LCP threshold for "good" has tightened from 2.5 seconds (the old passing threshold) to an effective target of 2.0 seconds if you want to rank competitively, with 2.5 seconds as the outer boundary of the "good" band. This is not a paper change — field data from the Chrome User Experience Report shows that the distribution of real-world LCP scores means the difference between 2.0s and 2.5s is meaningful at the 75th percentile.

The sites most exposed by these changes are ones built with:

- Heavy client-side rendering that blocks INP with long tasks

- Unoptimized hero images that drive LCP scores above 2.5s

- Third-party scripts loaded synchronously in the document head

- Layout shifts caused by late-loading fonts or dynamic content injections

If your Next.js site uses any of these patterns — and most do, to some degree — the audit below is where to start.

---

What Are Core Web Vitals and What Are the 2026 Benchmarks?

Core Web Vitals are a set of real-user metrics that Google uses to measure the quality of the experience on a web page. They are not synthetic benchmarks — they are collected from real Chrome users visiting real pages and aggregated in the Chrome User Experience Report (CrUX). Your score reflects what actual visitors are experiencing, not what a lab test measures on a clean machine.

The three active metrics in 2026:

Largest Contentful Paint (LCP) — measures loading performance. LCP marks the point at which the largest content element in the viewport (usually a hero image, a large heading, or an above-the-fold block) has finished rendering. It is the best proxy for "when does the page feel loaded" because it captures the moment the user sees the main content.

Interaction to Next Paint (INP) — measures interactivity. INP observes all interactions a user makes with the page (clicks, taps, key presses) and reports the worst-case interaction latency at the 75th percentile. It replaced First Input Delay in March 2024 and became a ranking signal in the 2026 update.

Cumulative Layout Shift (CLS) — measures visual stability. CLS scores how much the layout shifts unexpectedly during the page's lifetime. A score of 0.1 means no meaningful shift; a score of 0.5 means elements are jumping around enough to cause the user to click the wrong thing.

The practical target in a competitive ranking environment is tighter than the "good" band: LCP under 2.0s, INP under 100ms, CLS at or near zero. The "good" threshold is the floor, not the goal.

---

What's a Good Website Speed Score in 2026?

Lighthouse scores are the most common reference point, but they measure a synthetic load in a controlled environment — not field data. Treat them as a diagnostic tool, not a ranking predictor. That said, Lighthouse scores correlate well with Core Web Vitals in field data when measured consistently.

Mobile scores are structurally lower than desktop because Lighthouse simulates a mid-tier Android device on a throttled 4G connection. A score of 75+ on mobile is genuinely excellent and requires deliberate architectural choices. Most content sites landing in the 60–74 range are doing well. Tool sites — which should be minimal by nature — should be targeting 80+ on mobile and 95+ on desktop.

One more nuance: Lighthouse scores compress at the top end. Going from 70 to 80 is relatively achievable with standard optimizations. Going from 85 to 95 requires fixing things that are easy to miss — render-blocking resources, main thread contention, unused CSS in the critical path.

---

Next.js 16 Performance Audit Checklist: Where to Start

The audit has two phases. Phase one is structural — review the rendering strategy, data fetching, caching, and dependency footprint. These decisions determine the performance ceiling. Phase two is diagnostic — measure the actual metrics and trace the specific causes of each bottleneck. Starting with phase two without phase one means you are fixing symptoms instead of causes.

Site Structure and Next.js Core Review

Before running a single Lighthouse test, answer these four questions about your codebase:

Are you on Next.js 15 or 16 with the App Router? The App Router (introduced in Next.js 13, stabilized in 14, and significantly optimized in 15 and 16) is the prerequisite for most of the performance patterns discussed below. If you are still on the Pages Router, the upgrade path is clear — but the architectural differences are real. Server Components, streaming, and partial prerendering are only available in the App Router.

What is your JavaScript bundle size? Run `next build` and check the output. Pay attention to the `First Load JS` column. Any route with a First Load JS above 150 KB has room to improve. Routes above 300 KB likely have an import problem — something heavyweight is being bundled client-side when it could be server-side or code-split.

Are you using Turbopack? Next.js 16 ships with Turbopack as the default bundler (it was opt-in in earlier versions). If you are running `next dev --turbo` and seeing significantly faster HMR times, you're on it. If your dev server still feels sluggish, verify with `next info` that Turbopack is active. For production builds, Turbopack in Next.js 16 provides measurably smaller bundles through better tree-shaking than the legacy Webpack config.

What is your Node.js version? Next.js 16 requires Node.js 20+. Running on Node.js 18 with Next.js 16 works but you lose several V8 engine optimizations that are significant for server-side rendering throughput.

Rendering Strategy: SSR, SSG, ISR, or Server Components?

The rendering strategy is the most consequential architectural decision for a tool site, and it gets conflated in discussions that treat SSR and Server Components as the same thing. They are not.

Static Site Generation (SSG) pre-renders pages at build time. The HTML is fully formed before any user request. This produces the best TTFB (Time to First Byte) because the CDN serves pre-built HTML. The limitation is that you cannot serve user-specific or real-time content. For pages that never change — landing pages, documentation, about pages — SSG is always the right answer.

Incremental Static Regeneration (ISR) combines SSG with periodic revalidation. Pages are pre-rendered but can be regenerated on a schedule (or on-demand). For a tool site where tool pages rarely change but might need occasional updates, ISR with a long revalidation window (24 hours or more) gives you the TTFB of SSG without the stale-forever risk.

React Server Components (RSC) — the App Router's default — run on the server and stream HTML to the client without sending JavaScript to the browser. This is distinct from SSR: RSC components contribute zero JavaScript to the client bundle. They can fetch data, render complex markup, and pass serialized props to Client Components — all without increasing the JS payload.

The correct default for a tool site built on Next.js 16:

\`\`\`

- Layout.tsx → Server Component (no JS to client)

- Navigation.tsx → Server Component with Client Component island for mobile menu

- ToolPage.tsx → Server Component shell, imports Client Component for interactive tool

- ToolLogic.tsx → Client Component (marked 'use client') — only this ships JS

- Footer.tsx → Server Component

\`\`\`

This architecture means a user visiting a tool page downloads HTML for the shell and layout server-side, with JavaScript hydration limited to the interactive calculator or converter widget only. The navigation, heading, SEO metadata, and footer produce zero client-side JavaScript.

Data Fetching Layer Review

In Next.js 16 with the App Router, data fetching happens in Server Components using async/await with `fetch`. The fetch API in Next.js is extended with caching semantics:

\`\`\`typescript

// Cached indefinitely (SSG behavior)

const data = await fetch('/api/tool-config', { cache: 'force-cache' });

// Revalidate every hour (ISR behavior)

const data = await fetch('/api/tool-config', {

next: { revalidate: 3600 }

});

// Never cache (SSR behavior — fresh on every request)

const data = await fetch('/api/tool-config', { cache: 'no-store' });

\`\`\`

The most common mistake in tool sites is fetching data that could be static (`force-cache`) with `no-store`, forcing a database or API roundtrip on every page request. For a unit converter that displays the same conversion factors every time, `force-cache` is the correct choice. The data fetched at build time is all the data you need.

The second common mistake is sequential waterfall fetches — one fetch that depends on the result of another. In Server Components, parallel fetches are straightforward:

\`\`\`typescript

// Bad: waterfall

const config = await fetchToolConfig();

const stats = await fetchToolStats(config.id);

// Good: parallel

const [config, stats] = await Promise.all([

fetchToolConfig(),

fetchToolStats()

]);

\`\`\`

A tool page that makes two sequential API calls before it can render will have an LCP that reflects both roundtrips. Parallel fetches cut that latency in half.

Caching Layer Review: The Layer Most Sites Get Wrong

Caching in a Next.js application operates at four distinct levels, and most sites optimize one while ignoring the others:

Level 1: CDN / Edge Cache — Static assets (JS, CSS, images) should be served from a CDN with long cache headers. Next.js sets `Cache-Control: public, max-age=31536000, immutable` on hashed static assets automatically. Verify this is happening by checking the response headers on your deployed JS and CSS files. If you see `Cache-Control: no-cache` on static assets, something in your hosting configuration is overriding Next.js defaults.

Level 2: Next.js Data Cache — The `fetch` caching described above. Verify by checking if tool pages produce identical HTML on consecutive requests without triggering upstream API calls. In Next.js 16, the Data Cache is persistent by default — it survives process restarts on edge deployments.

Level 3: Next.js Router Cache — Client-side cache of React Server Component payloads. When a user navigates between tool pages, the RSC payload for previously visited pages is cached in memory. This means second visits to any tool produce instant navigation. The default TTL is 30 seconds for dynamic pages and 5 minutes for static pages in Next.js 16.

Level 4: Full Route Cache — Pre-rendered HTML and RSC payloads stored on the server for static routes. This is what makes SSG and ISR fast — the full response is cached and served from disk or CDN without running any server code.

For a tool site, the expected state is: Level 1 and Level 4 active for all tool pages (SSG/ISR), Level 2 active for any server-side fetches, Level 3 active automatically for client navigation.

Packages and Dependencies: The Hidden Bundle Weight

Run `npx @next/bundle-analyzer` on your production build. The output is a visual treemap of your client-side bundle. Two things to look for:

Large packages in client components. A common offender is importing a full utility library (lodash, moment.js, date-fns) into a client component when you only need one or two functions. Lodash adds ~70KB gzipped to a client bundle if imported as `import _ from 'lodash'`. Import the specific function instead: `import debounce from 'lodash/debounce'`.

Server-only packages leaking to the client. If a Server Component imports a package and that component accidentally gets a `'use client'` directive added later, the previously server-only package becomes part of the client bundle. Mark server-only dependencies with the `server-only` package:

\`\`\`typescript

import 'server-only'; // This module will throw if imported client-side

import { db } from '@/lib/database';

\`\`\`

---

FCP, LCP, INP, and CLS: How to Actually Diagnose Each One

Lighthouse gives you scores. Chrome DevTools tells you why.

For LCP diagnosis: Open DevTools → Performance tab → record a page load. Look for the LCP marker in the timeline. Click it. It will identify the element (usually an image or a heading) and show the four sub-components of LCP: Time to First Byte, Resource Load Delay, Resource Load Time, and Element Render Delay. Each sub-component has a different fix:

- High TTFB → server response is slow → fix server rendering, caching, or choose a closer CDN region

- High Resource Load Delay → LCP resource discovered late → preload the LCP image or move it earlier in the HTML

- High Resource Load Time → LCP image is too large → compress, convert to WebP/AVIF, use proper sizing

- High Element Render Delay → render-blocking resources → defer non-critical CSS and JavaScript

For INP diagnosis: Open DevTools → Performance Insights panel → interact with the page (click buttons, type in inputs). Find the "Interactions" section. Any interaction over 200ms is flagged. Click the interaction to see where the time was spent: Input Delay, Processing Time, or Presentation Delay. Long Processing Time means main thread work — look for synchronous JavaScript executing during the interaction. Long Presentation Delay means layout and paint are slow — look for forced reflows caused by reading layout properties in event handlers.

For CLS diagnosis: DevTools → Layout Shift Regions (in the Rendering panel, enable "Layout Shift Regions"). Any element that shifts will flash red during page load. The most common causes on tool sites: images without explicit `width` and `height` attributes, fonts that swap from fallback to web font, and dynamic content (cookie banners, notification bars) that push page content down on load.

Images and Video Optimization Review

Next.js provides the `Image` component (`next/image`) which handles format conversion (WebP, AVIF), responsive sizing, lazy loading, and prevents layout shifts through explicit dimension requirements. But using `next/image` is not enough on its own — it needs to be configured correctly.

Priority loading for LCP images: Any image that is the LCP candidate — typically the hero image or any large above-the-fold image — needs the `priority` prop. Without it, Next.js lazy-loads the image, which directly causes a high LCP.

\`\`\`tsx

// Hero image — add priority

<Image

src="/hero.webp"

alt="Tool hero"

width={1200}

height={600}

priority // ← critical for LCP images

/>

// Below-fold images — lazy load by default (no priority needed)

<Image

src="/feature.webp"

alt="Feature screenshot"

width={800}

height={400}

/>

\`\`\`

Correct sizes prop: The `sizes` prop tells the browser how large the image will actually render at different viewport widths. Without it, the browser may download a 1200px wide image for a mobile viewport where it renders at 390px.

\`\`\`tsx

<Image

src="/tool-preview.webp"

alt="Tool preview"

fill

sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw"

/>

\`\`\`

Format selection: Next.js 16 defaults to AVIF first with WebP fallback. AVIF provides 30–50% smaller file sizes than WebP at equivalent quality. If your images are still being served as JPEG or PNG (check the Network tab), verify that `next.config.js` is not overriding the image format config.

For tool sites: if your tools are primarily text-based interfaces with minimal imagery — as they should be — image optimization has a ceiling. A calculator doesn't need a hero image at all. The fastest image is no image. Where images are used (tool preview screenshots, author photos, blog illustrations), the above rules apply strictly.

Scripts Optimization and Render-Blocking Resources

Every `<script>` tag in the document `<head>` without `async` or `defer` blocks HTML parsing. This is the most common cause of high FCP on otherwise well-built sites — a third-party script loads synchronously and holds up the entire render.

In Next.js 16, use the `Script` component from `next/script` for all third-party scripts. It enforces one of three loading strategies:

\`\`\`tsx

import Script from 'next/script';

// Load after page is interactive (analytics, non-critical)

<Script src="https://analytics.example.com/script.js" strategy="lazyOnload" />

// Load after hydration (most third-party scripts)

<Script src="https://widget.example.com/embed.js" strategy="afterInteractive" />

// Load as soon as possible, before hydration (critical scripts only)

<Script src="/critical-init.js" strategy="beforeInteractive" />

\`\`\`

`beforeInteractive` should be used only for scripts that are genuinely required before the page can be used — consent management platforms, critical polyfills. For everything else, `afterInteractive` or `lazyOnload`.

CSS render-blocking: in Next.js App Router, all CSS imported in Server Components and layouts is automatically inlined in the `<head>` as critical CSS or loaded with appropriate preload headers. The risk is importing large CSS libraries (Bootstrap, full Tailwind without purging) that bloat the critical CSS payload. Tailwind CSS with `@tailwindcss/postcss` in Next.js 16 automatically purges unused utilities — verify your Tailwind config includes all content paths so the purge is comprehensive.

Marketing and Third-Party Scripts Review

This section is where well-intentioned performance work often gets undone by business requirements. Tag managers, chat widgets, session recording tools, advertising pixels — each one adds to the main thread budget and can independently cause INP failures.

A pragmatic approach for tool sites:

Audit what is actually loaded. Open the Network tab, filter by type, and look at what third-party domains are making requests. Many tag manager implementations accumulate scripts over time as marketing campaigns launch and never get cleaned up. A site might be loading six analytics scripts when one would suffice.

Defer everything. Every marketing script should use `strategy="lazyOnload"` in the Next.js `Script` component. There is no marketing script whose data quality suffers meaningfully from being loaded 2–3 seconds after page interactive.

Use the Partytown strategy for non-critical heavy scripts. Next.js integrates with Partytown (via `@builder.io/partytown`) to run third-party scripts in a web worker, completely off the main thread. For analytics and session recording scripts that are JavaScript-heavy, this removes their INP impact entirely.

\`\`\`tsx

<Script

src="https://heavy-analytics.example.com/tracker.js"

strategy="worker" // Runs in Partytown web worker

/>

\`\`\`

For tool sites specifically: be aggressive about deferring or removing third-party scripts. The user who visits a unit converter or a token calculator has near-zero tolerance for a slow tool. Protecting their experience is more valuable than an extra 30ms of analytics coverage.

Mobile Optimization Review

Mobile Lighthouse scores simulate a Moto G Power (a mid-tier Android device) on a throttled 4G connection (10 Mbps download, 40ms RTT). This is intentionally punishing — it represents a common real-world scenario, not a worst case.

The most impactful mobile-specific optimizations:

Reduce Total Blocking Time (TBT). TBT measures the total time the main thread is blocked by long tasks (tasks over 50ms) between FCP and Time to Interactive. On mobile, JavaScript execution is 4–5x slower than on a desktop CPU. A task that runs in 30ms on desktop runs in 120–150ms on mobile — crossing the 50ms "long task" threshold and contributing to TBT.

Break long tasks using `scheduler.yield()` (available in Chrome 115+ and polyfillable):

\`\`\`typescript

async function processLargeInput(items: Item[]) {

for (let i = 0; i < items.length; i++) {

processItem(items[i]);

// Yield to browser every 50 items to prevent long task

if (i % 50 === 0) await scheduler.yield();

}

}

\`\`\`

Font loading optimization. Web fonts cause layout shifts (CLS) when they swap from fallback to loaded font, and they delay FCP if they are render-blocking. In Next.js 16 with `next/font`, fonts are automatically optimized: self-hosted at build time, zero layout shift through CSS `size-adjust`, and loaded with `display: swap` by default.

\`\`\`typescript

import { Inter } from 'next/font/google';

const inter = Inter({

subsets: ['latin'],

display: 'swap',

preload: true,

});

\`\`\`

Viewport meta tag and touch event handling. Verify `<meta name="viewport" content="width=device-width, initial-scale=1" />` is in your layout. Without it, mobile browsers render a desktop viewport and scale down — this is a CLS and readability issue. For interactive tools, ensure touch event handlers are passive where possible to avoid blocking scroll:

\`\`\`typescript

element.addEventListener('touchstart', handler, { passive: true });

\`\`\`

---

How We Built UntangleTools to Load in Under 1 Second

UntangleTools — the free suite of calculators, converters, and developer utilities at untangletools.com — was built with sub-second load times as a hard constraint, not an afterthought. Here's the specific architecture that makes it fast.

Every tool page is statically generated. Tool pages don't serve user-specific data. A unit converter page is identical for every visitor. That makes SSG the right choice across the board. The HTML for every tool is pre-rendered at build time and served from the CDN edge — TTFB is consistently under 80ms globally because there's no server-side computation happening at request time.

All calculation logic runs client-side in the browser. This is the key design decision. When you open the Unit Converter and type `100 km`, the conversion to miles happens entirely in your browser. No API call. No round-trip. No waiting. The answer appears before you finish typing. This is possible because unit conversion math is deterministic and lightweight — it belongs on the client, not a server. The same principle applies to the AI Token Counter, the Color Converter, the GPA Calculator, and every other tool. Computation is cheap; network latency is not.

Open the unit converter and watch the Network tab — there are no XHR requests when you type. The page loaded the conversion factors at startup, and everything after that is pure client-side arithmetic. That is intentional, and it is why the tool feels instant.

Try the Unit Converter — See How Fast a Lightweight Tool Actually Loads

Tool interactivity is isolated in minimal Client Components. The navigation, page layout, SEO metadata, headings, and footer are all Server Components — they ship zero JavaScript to the browser. The interactive tool widget is a single focused Client Component that handles user input and calculation. The JavaScript downloaded per tool page is typically under 40 KB gzipped — a fraction of what most React applications ship.

No unnecessary dependencies. The color converter doesn't pull in a full color science library when pure TypeScript handles the conversion math. The token calculator doesn't import a tokenization runtime when a character-based approximation serves the use case. Each tool uses exactly the code it needs, and that code is verified against the bundle analyzer on every build.

Images are used only where they add genuine value. Tool interfaces are primarily text and form inputs — there is no hero image on a calculator page, because there doesn't need to be. Where images are used (blog posts, tool preview screenshots), they are served as AVIF with WebP fallback, sized correctly, and lazy-loaded below the fold.

The result: Lighthouse scores consistently above 97 on desktop, above 85 on mobile. FCP under 0.4 seconds on desktop. LCP under 0.8 seconds on desktop. CLS at zero across all tool pages.

---

Why Your Tool Site Should Be Faster Than a Heavy IDE

Here's a comparison that most developers don't think about explicitly: the alternative to a lightweight online tool is often opening a desktop application or IDE.

Opening VS Code, navigating to a terminal, loading a Node.js REPL to run a quick JSON parse — that workflow takes 15–30 seconds on most machines. Opening a browser tab to a fast JSON formatter tool should take under 1 second from search result click to result visible. If your tool site takes 4 seconds to load, you haven't beaten the IDE workflow. You've just added a browser round-trip to the same frustration.

This is why performance for tool sites isn't just a technical metric — it's the product's core value proposition. The entire reason someone uses an online tool instead of their local environment is speed and simplicity. A slow tool site fails at its fundamental purpose.

Try the AI Token Counter on UntangleTools — from clicking the link to having a working token counter ready is under a second on a standard connection. That's the bar. Everything that makes it that fast is what this audit covers.

AI Token Counter — Instant, No Signup, Under 1 Second to Load

Or try the Color Converter — type a HEX value, get RGB, and HSL immediately. No loading state. No spinner. The conversion runs before you've finished typing because it runs in your browser, not a server.

Color Converter — Instant HEX to RGB, HSL

---

How to Improve Local Dev Performance in Next.js 16

Slow local development is a different problem than slow production, but it's worth addressing because slow dev feedback loops lead to shortcuts that hurt production performance.

Use the latest Next.js 16 and enable Turbopack. Turbopack replaces Webpack as the default dev bundler in Next.js 16. HMR times drop from 2–3 seconds to under 100ms for most code changes. Verify Turbopack is active by checking the terminal output when running `next dev` — you should see "Turbopack" in the startup message. If you're on an older lockfile that pins to an older version, update:

\`\`\`bash

npm install next@latest react@latest react-dom@latest

\`\`\`

Check antivirus interference. On Windows particularly, real-time antivirus scanning of the `.next` build cache directory can add 30–60% to compilation times. Add the project directory and the `.next` folder to your antivirus exclusion list. This is not a security compromise — you are excluding the compiled output directory, not your source files.

Audit your imports for accidental large module loads. A common dev-time performance issue is importing a module with side effects at the top level of a frequently re-executed file. Every hot reload re-executes the import chain. If one of those imports triggers a large initialization (connecting to a database, loading a large configuration file), the HMR feedback loop feels slow even though Turbopack itself is fast.

Use Node.js 22+. Next.js 16 supports Node.js 20+, but Node.js 22 includes V8 improvements to async function performance and better module resolution caching that measurably improves both dev startup time and build time.

---

What Actually Moves the Needle: Five Changes With Real Numbers

After the full audit, five changes produced the majority of the performance improvement. Ordered by impact:

1. Converting hero and preview images to AVIF with correct `sizes` prop.

LCP improvement: -0.8 seconds on mobile. Images were being served as JPEG at 1200px wide even on mobile viewports where they rendered at 390px. Converting to AVIF and adding the correct `sizes` prop cut the LCP image download from 380KB to 44KB.

2. Moving analytics from synchronous head script to `lazyOnload` strategy.

TBT improvement: -240ms on mobile. The analytics script was blocking HTML parsing on every page load. Moving it to `lazyOnload` removed it from the critical path entirely. The analytics still captures the same data — it just loads after the page is interactive.

3. Replacing a client-side data fetch with build-time static data.

TTFB improvement: -180ms. Tool configuration data was being fetched from an API on page load (`cache: 'no-store'`). The data never changes between deployments. Switching to `force-cache` and adding it to the static build eliminated the API round-trip entirely.

4. Adding `priority` prop to LCP images.

LCP improvement: -0.4 seconds on desktop. The hero image on the landing page was being lazy-loaded by default — it was discovered late because it wasn't in the initial viewport in the HTML source. Adding `priority` triggered a preload link in the document head, moving image discovery to the HTML parsing phase.

5. Code-splitting a heavy client-side library using `dynamic`.

First Load JS improvement: -67KB gzipped. A chart rendering library was being loaded eagerly on tool pages that don't use charts. Dynamic import with `next/dynamic` and `ssr: false` deferred the load to only the pages that need it.

\`\`\`typescript

// Before: loaded on every page

import { ChartComponent } from '@/components/chart';

// After: loaded only when rendered

const ChartComponent = dynamic(

() => import('@/components/chart'),

{ ssr: false, loading: () => <ChartSkeleton /> }

);

\`\`\`

---

The Full Next.js Performance Audit Checklist

Use this checklist in order. The items earlier in each section have higher average impact.

Performance Metrics Assessment

- Run Lighthouse on both desktop and mobile and record baseline scores

- Check Core Web Vitals in Google Search Console (field data, not synthetic)

- Run PageSpeed Insights to get the CrUX data for your specific URL

- Record TTFB, FCP, LCP, TBT, INP, and CLS individually before making changes

Codebase Core Review

- Verify Next.js version is 15 or 16 with App Router active

- Confirm Turbopack is enabled in development

- Run bundle analyzer and identify any client bundle over 150KB

- Check that Server Components are the default and Client Components are marked explicitly with 'use client'

- Audit for server-only packages that may have leaked to the client bundle

SSR and SSG Review

- Confirm all static pages use `force-cache` or ISR with appropriate revalidation

- Verify no static data is being fetched with `cache: 'no-store'`

- Check that data fetches are parallelized with `Promise.all` where possible

- Review streaming usage with `<Suspense>` for any dynamic data sections

Images and Media

- Confirm `next/image` is used for all images

- Add `priority` prop to all above-the-fold images

- Set correct `sizes` prop on all images

- Verify images are served as AVIF or WebP (check Network tab)

- Confirm all images have explicit `width` and `height` (prevents CLS)

- Remove hero images from tool pages where they add no value

Scripts and Third-Party

- Audit all third-party scripts loading in the document head

- Move all analytics and marketing scripts to `lazyOnload` or `afterInteractive`

- Consider Partytown for heavy third-party scripts

- Remove any unused scripts accumulated from past campaigns

Caching Strategy and CDN

- Verify static assets have `Cache-Control: immutable` headers

- Confirm full route cache is active for static pages

- Check CDN configuration — static assets should be served from edge, not origin

- Verify router cache is working for client-side navigation between tool pages

Fonts

- Replace any manual Google Fonts `<link>` tags with `next/font/google`

- Confirm `display: swap` is set

- Subset fonts to only the characters used

Mobile-Specific

- Confirm viewport meta tag is present in root layout

- Run Lighthouse mobile simulation and identify any long tasks over 200ms

- Check touch event handlers are passive

- Verify CLS is zero on mobile by testing on a real device

Accessibility and SEO

- Confirm all images have descriptive `alt` attributes

- Verify heading hierarchy (one H1 per page, logical H2/H3 structure)

- Check that Core Web Vitals data is appearing in Google Search Console

This checklist is not exhaustive — every codebase has specific issues that a generic audit cannot anticipate. But completing it will surface the majority of performance issues on any Next.js tool site and give you a clear priority order for fixes.

The 1-second load target is achievable. The architecture for it exists in Next.js 16 today. The question is whether you have deliberately chosen to use it.