Page speed
optimization.

I'm Byron Johnson. I do page speed optimization for sites that are already live, including WordPress, React, Next.js, and Vite. I measure Core Web Vitals with PageSpeed Insights, Lighthouse, and CrUX, then fix the slow path in the framework the site already uses.

Fifteen-plus years in the industry. I use PageSpeed Insights, Lighthouse, and CrUX field data, and I use Claude, GitHub Copilot, and Cursor as development partners so the fix stays inside the theme, template, or app you already ship.

Send the slow URL Other freelance work
  • Any stack WordPress, React, Next.js, Vite, or HTML.
  • Measured LCP, INP, and CLS, before and after the fix.

01 / Services

What I fix on a slow page

Send the URL. I measure it with PageSpeed Insights, Lighthouse, and CrUX, including WordPress, then fix the path that is holding the score.

  • Core Web Vitals

    PageSpeed Insights, Lighthouse, and CrUX field data. I name the metric that is failing, then fix that path.

  • WordPress page speed

    The site stays on the stack it uses today, including WordPress. No rewrite onto a new framework.

  • Largest Contentful Paint

    The hero image, web font, render-blocking CSS, or server response that holds the first view. I shorten that path.

  • Interaction to Next Paint

    Main-thread JavaScript, dynamic imports, lazy loading, and third-party scripts that delay a tap or a click.

  • Cumulative Layout Shift

    Images, fonts, and embeds that move the page after it paints. Space is reserved so the layout stays still.

  • JavaScript, CSS, and HTML

    Semantic markup, CSS, and vanilla JavaScript, plus React lazy loading when the UI is already React.

  • Build tooling

    Vite builds, bundle weight, and legacy migration when the toolchain itself is what makes the page slow.

  • Measure again

    The same PageSpeed Insights and Lighthouse run after the change, plus a smoke test so the page still works.

02 / In place

The framework stays

Page speed work does not start with a rebuild. I use the same diagnosis on WordPress, React, Next.js, Vite, and plain HTML, and the edit lands in that codebase.

  1. WordPress

    The theme is already live

    Themes, templates, plugins, and third-party tags. I find the script, image, or font that is costing the score and change it in the WordPress site you already run.

  2. React and Next.js

    The app is already shipped

    Server and client components, dynamic imports, and lazy loading. Server rendering and static generation stay in play when the app already uses them.

  3. HTML, CSS, and JavaScript

    The page is markup

    Semantic HTML, CSS that does not block the first paint, and vanilla JavaScript. Reduced motion stays in place so a faster page is still usable.

  4. Fonts and images

    The first view is heavy

    The Largest Contentful Paint element is often a hero image or a web font. I load that asset so the first view arrives, and I reserve space so the layout does not jump.

  5. Vite and legacy builds

    The bundle is the wait

    Multi-page Vite builds and older bundles. When the toolchain is what ships too much JavaScript, I lighten that build instead of replacing the framework.

03 / Method

Measure, then change one path

A speed fix starts from the report, not from a new stack. I keep a baseline, change the cause, and run the same report again.

Baseline

PageSpeed Insights, a Lighthouse run, and CrUX field data when the page has it. That is the before.

One cause

The script, image, font, layout shift, or server response that accounts for the failing metric. Not a list of every warning.

In the current code

The edit stays in the theme, template, or app. A rewrite is a different engagement, on the hire page.

The same report again

Lighthouse and PageSpeed Insights after the change, plus a Playwright smoke test so the page still does what it did.

The same measurement, on whichever of these the site already uses:

  • WordPress
  • React
  • Next.js
  • Vite
  • HTML, CSS, JavaScript
  • PageSpeed Insights
  • Lighthouse
  • CrUX

04 / Questions

Before you send a URL

What does page speed optimization include?

I improve the speed of a site that is already live. The work covers Core Web Vitals with PageSpeed Insights, Lighthouse, and CrUX; Largest Contentful Paint; Interaction to Next Paint; Cumulative Layout Shift; JavaScript, CSS, and HTML; build tooling; and a second measurement after the fix. WordPress, React, Next.js, Vite, and server-rendered HTML are all in scope.

Do you optimize WordPress page speed?

Yes. WordPress stays WordPress. I work in the theme, templates, and scripts the site already ships, including plugins and third-party tags that are costing the score.

Do I have to move the site to a new framework?

No. The fix stays in the architecture you have. A rewrite is not part of this service.

Can you improve a PageSpeed Insights score?

Yes. Send the URL. I start from that page's PageSpeed Insights and Lighthouse report, fix the path that is holding the score, and run the same reports again. One slow page is enough to start.

How do you use AI on a speed engagement?

I use Claude, GitHub Copilot, and Cursor as development partners. The baseline report and the current theme or codebase stay in context, so a change does not wander into a rewrite.

How do I hire you for page speed?

Send the form on this page with your name, email, the page URL, and a short note. I will reply back by email.

05 / Start

Send the slow page

The URL is enough to start. Add the framework if you know it, and what feels slow. I read every message.

Let's Go!