How to Hit a 100 PageSpeed Score on a Real Client Website (Not Just a Demo)

# nextjs# performance# seo# webdev

Christopher Bailey

Anyone can score 100 on a blank HTML page. But what about a real business site — with images, custom...

Anyone can score 100 on a blank HTML page. But what about a real business site — with images, custom fonts, animations, third-party scripts, and a client who wants a hero video? That's where most agencies tap out.

At OceanWave Web, we build hand-coded Next.js websites for small businesses, and a perfect (or near-perfect) PageSpeed score isn't a bonus — it's the baseline. Here's exactly how we do it, with the real techniques we use on every project.

Why PageSpeed Actually Matters (Beyond the Bragging Rights)

Before the how, let's quickly address the why:

SEO: Google uses Core Web Vitals as a ranking signal. A slow site is a penalized site.
Conversions: A 1-second delay in load time can reduce conversions by up to 7%.
User trust: A fast site feels professional. A slow one, even a beautiful one, feels broken.

For small businesses competing against big brands, performance is a real differentiator.

The Stack We Use

We build on Next.js (App Router), deployed on Vercel, with hand-written CSS or Tailwind. No page builders, no WordPress, no theme bloat. This matters because half the battle is starting with clean code.

Images: The Biggest Win

Images are almost always the #1 culprit behind slow scores. Here's the full playbook:

Use next/image for Everything

Next.js's component handles lazy loading, responsive sizing, and WebP/AVIF conversion automatically.

jsximport Image from 'next/image'

src="/hero.jpg"
alt="Hero image"
width={1200}
height={630}
priority // Only for above-the-fold images
sizes="(max-width: 768px) 100vw, 1200px"
/>

Use priority only on your LCP (Largest Contentful Paint) image — typically the hero. Adding it everywhere defeats the purpose.

Compress Before You Even Upload

Even WebP has limits. We run all client assets through Squoosh or sharp before they ever hit the repo. Target:

Hero images: under 200KB
Card/thumbnail images: under 80KB
Icons: use SVG, not PNG

Avoid Layout Shift with Explicit Dimensions

Always set width and height on every image. This lets the browser reserve space before the image loads, avoiding Cumulative Layout Shift (CLS).

Fonts: The Silent Killer

Google Fonts are convenient but expensive. Here's how we handle typography without paying the performance tax:

Self-Host Your Fonts

js// app/layout.js
import localFont from 'next/font/local'

const myFont = localFont({
src: './fonts/MyFont.woff2',
display: 'swap',
variable: '--font-my-font',
})

With next/font, fonts are:

Self-hosted at build time (no external request)
Preloaded automatically
Injected with font-display: swap to prevent invisible text

Limit Font Weights

Every font weight is an extra file. If you only need 400 and 700, don't load 300, 500, and 900 too. Audit your design and cut ruthlessly.

JavaScript: Ship Less, Load Smarter

Code-Split with Dynamic Imports

Don't load components the user hasn't seen yet.

jsximport dynamic from 'next/dynamic'

const HeavyModal = dynamic(() => import('@/components/HeavyModal'), {
loading: () =>

,
})

This is especially useful for modals, chat widgets, map embeds, and anything "below the fold."

Audit Your Bundle

Run next build and check the output. Better yet, use bundlephobia.com before installing any npm package. A single unoptimized dependency can blow up your score.

Defer Third-Party Scripts

Analytics, chat widgets, and marketing tools are notorious score-killers. Use Next.js's component with the right strategy: jsximport Script from 'next/script' // Load after page is interactive <Script src="https://analytics.example.com/script.js" strategy="afterInteractive" /> // Load after browser is idle <Script src="https://widget.example.com/widget.js" strategy="lazyOnload" /> Never use strategy="beforeInteractive" unless the script is 100% critical (it almost never is). <ol> <li>CSS: Keep It Lean</li> </ol> Avoid Render-Blocking CSS All your CSS should either be: Inlined (handled automatically by Next.js for critical styles) Loaded asynchronously for non-critical styles Purge Unused Styles If you're using Tailwind, enable the content purge config properly: js// tailwind.config.js module.exports = { content: [ './app//*.{js,ts,jsx,tsx}', './components//*.{js,ts,jsx,tsx}', ], } This removes unused utility classes from your production build. A typical Tailwind purge goes from 3.5MB to under 15KB. <ol> <li>Core Web Vitals: The Actual Metrics</li> </ol> PageSpeed is built on three Core Web Vitals. You need all three to be green: MetricWhat It MeasuresGood ThresholdLCP (Largest Contentful Paint)Load time of main content< 2.5sINP (Interaction to Next Paint)Response time to user input< 200msCLS (Cumulative Layout Shift)Visual stability< 0.1 Fix LCP Use priority on your hero image Preconnect to critical origins: <link rel="preconnect" href="https://fonts.gstatic.com" /> Make your server respond fast (Vercel edge network helps here) Fix INP (replaced FID in 2024) Minimize long JavaScript tasks Break up heavy computations with setTimeout or Web Workers Use React's useTransition for non-urgent state updates jsxconst [isPending, startTransition] = useTransition() startTransition(() => { setFilteredResults(heavyFilter(data)) }) Fix CLS Always set image dimensions Reserve space for ads/embeds with explicit height containers Avoid injecting content above existing content dynamically <ol> <li>Server-Side Rendering + Caching</li> </ol> Next.js App Router gives you powerful caching primitives out of the box. js// Cache a data fetch for 1 hour const data = await fetch('<a href="https://api.example.com/data">https://api.example.com/data</a>', { next: { revalidate: 3600 } }) For truly static content (like a small business homepage), use export const dynamic = 'force-static' to pre-render at build time. Zero server compute, near-instant response. <ol> <li>The Audit Workflow We Use on Every Project</li> </ol> Before launch, we run through this checklist: PageSpeed Insights — pagespeed.web.dev on mobile first (it's the harder test) WebPageTest — for waterfall analysis and finding hidden render-blocking resources Lighthouse in Chrome DevTools — for local iteration before deploying GTmetrix — cross-check and historical tracking We run audits on both mobile and desktop. Mobile is the stricter standard, and it's where most real users are. Real Results On a recent project for a local service business, we took their site from a 34 (mobile) on PageSpeed to a 98 mobile / 100 desktop after migration from a WordPress theme to hand-coded Next.js. Load time dropped from 6.8s to under 1.2s. The impact wasn't just the score — organic traffic increased 40% over the next three months as the improved Core Web Vitals fed into Google's ranking algorithm. TL;DR Checklist Use next/image with explicit dimensions and priority on LCP only Self-host fonts with next/font Dynamic import heavy components Defer all third-party scripts with strategy="afterInteractive" or "lazyOnload" Purge unused CSS Preconnect to critical third-party origins Use SSG or ISR for static/semi-static pages Audit on mobile, not just desktop Performance isn't magic — it's a series of deliberate choices made at every step of the build. If you're building sites on Next.js and want to go deeper on any of these techniques, drop a comment below or reach out at oceanwaveweb.com. Built by OceanWave Web — hand-coded Next.js websites for small businesses, starting at $0 down.