Website speed optimisation services: what gets fixed and what it costs

Website speed optimisation services find what makes your pages slow, fix it, and prove the result with before and after measurements. On most sites the work is the same short list: oversized images, too much JavaScript, slow hosting, missing caching and heavy third-party scripts. Published prices run from a flat $95 to $400 per site for a basic pass up to $1,250 to $12,000 for audit-led projects. (Americans search for "website speed optimization services". It's the same job.)

What changes between a WordPress, React and Next.js site is where the slowness hides, and that decides the bill.

I'm Mohit, a freelance web developer in Gurugram, India. I build and fix sites on WordPress, React and Next.js for clients in India, the UK and the US, and speed work is a regular part of that. This is the plain-English version of what I tell a business owner before they pay anyone for speed work, me included.

What do website speed optimisation services actually include?

A proper speed service has three parts: an audit that names the causes, the fixes themselves, and a re-test that shows what changed. If any of the three is missing, you're buying a plugin install or a PDF, not a service.

Here's what the work usually covers, in everyday terms:

• Images. Resizing and compressing photos, serving them in lighter formats such as WebP, and loading the ones lower down the page only when the visitor scrolls to them.
• JavaScript and CSS. These are the code files that make a page interactive and styled. The work is removing what a page doesn't use and delaying what it doesn't need straight away.
• Caching. Saving a ready-made copy of each page so the server doesn't rebuild it for every visitor.
• Hosting and server response. How long the server takes to start replying. If that first reply is slow, nothing else can be fast.
• A CDN. Short for content delivery network: copies of your files stored in many cities, so a visitor in London isn't waiting on a server in Mumbai.
• Fonts. Loading fewer font files, and loading them in a way that doesn't hide your text while they arrive.
• Third-party scripts. Chat widgets, analytics, ad pixels, heatmaps, cookie banners. Each one is somebody else's code running on your page.
• Layout stability. Stopping the page from jumping around while it loads, which is what makes people tap the wrong button.

That list matches what the big agencies publish. WebFX, for example, lists a performance audit, CSS and JavaScript minification, image compression, caching setup, font delivery and Core Web Vitals reporting in its plans.

What most service pages skip is the order. A good developer doesn't do all of these. They measure first, find the two or three things causing most of the delay on your site, and fix those. On one site that's a 4 MB hero image. On another it's six marketing scripts. The audit exists to tell the difference.

How do I know if my website needs a speed service?

Your site needs speed work if real visitors on phones are waiting more than about 2.5 seconds to see the main content, or if Google's own report says you fail Core Web Vitals. A gut feeling that the site "feels slow" is a fair reason to check, but check with numbers.

Core Web Vitals are Google's three measurements of how a page feels to a real visitor. The pass marks come from Google's own threshold definitions:

Google judges these at the 75th percentile, which means three out of four visits have to hit the "good" mark, including visits from older phones on poor networks.

To check your own site, open Google's free PageSpeed Insights and paste in your URL. You'll see two different things, and mixing them up is the most common mistake I see.

Field data (the top section) is what real visitors experienced, collected over the previous 28 days. This is the one Google uses and the one that matters.

Lab data (the score out of 100) is a single simulated test. Google's documentation says 90 or above is good, 50 to 89 needs improvement and below 50 is poor. It's useful for finding problems, but Google is clear that lab and field results can differ, sometimes by a lot. A site can get a middling lab score and still pass with real visitors, or a high lab score and still fail.

If you're failing, you have company. The HTTP Archive's 2025 Web Almanac found that only 48% of websites pass all three Core Web Vitals on mobile, against 56% on desktop. The loading measurement is where most of them fall down:

• LCP (loading)62%
• INP (reaction)77%
• CLS (stability)81%
• All three48%

The same report shows why. An image is the largest element on 76% of mobile pages, and only 44% of mobile sites have a good server response time. So for most business sites, the first two suspects are the big image at the top of the page and the hosting underneath it.

If the report confuses you, my free Page Speed Fix Planner reads a PageSpeed Insights or Lighthouse report and turns it into a ranked fix list in plain English. It's a good way to see what you'd be paying someone to do.

What gets fixed on a WordPress site?

On WordPress, the slowness usually sits in the hosting, the plugins and the page builder, not in WordPress itself. Most WordPress speed jobs are a matter of setting up caching properly, cutting what each page loads, and fixing images.

The typical fix list on a WordPress or WooCommerce site:

1. Caching, set up correctly. A caching plugin such as WP Rocket or LiteSpeed Cache, configured for your site rather than left on defaults. On a store, the cart, checkout and account pages must be left out, or customers start seeing each other's baskets.
2. Plugin audit. Finding which plugins add the most weight and whether they load on pages that don't need them. A contact form plugin has no business loading its files on your blog posts. Script manager tools handle this, and they're cheap: Perfmatters starts at $29.95 a year for one site.
3. Page builder clean-up. Elementor, WPBakery and Divi pages often carry far more code than the design needs. Some of that can be switched off in settings. Some needs sections rebuilt.
4. Images. Converting to WebP, sizing them for phones, and making sure the main image at the top of the page is not lazy-loaded (a surprisingly common own goal).
5. Database clean-up. Years of post revisions, expired temporary data and leftovers from deleted plugins slow down every uncached page and the whole admin area.
6. Hosting. If the server is slow to respond before any of the above, no plugin will rescue it. Sometimes the honest fix is a move to a better host.

I've written a fuller guide on what WordPress speed optimisation costs if WordPress is your only concern.

The Nortek LED store shows the same list from the other side. It is a WooCommerce store with a large, image-heavy lighting catalogue. I built it on a custom Oxygen Builder theme instead of a page-builder theme, with caching and image optimisation set up from the start. Post-launch analytics reported 35 percent faster load times. The store runs on WordPress, and it is quick because of how the theme, images and caching were handled.

One thing to know before you hire: installing a caching plugin and switching on every option is a quick job, and it's what the cheapest gigs sell. It often lifts the lab score and breaks something quietly, such as a menu on mobile or a form that stops submitting. The price difference between a cheap gig and a proper job is mostly the testing.

Related guide: How to speed up an Elementor site without rebuilding it

What does React website performance optimisation involve?

React website performance optimisation is mostly about sending less JavaScript to the visitor's phone and making sure there's real content on the page before that JavaScript runs. A plain React site often shows a blank screen first and builds the page in the browser, which is slow on cheap phones and bad for Google.

React is a JavaScript library for building interfaces. A classic React app (built with Create React App or Vite) sends the browser an almost empty page plus a large bundle of code, and the phone has to download and run all of it before anything shows. On a new iPhone you won't notice. On a three-year-old Android on mobile data, you will.

The usual fixes:

• Bundle analysis. A report showing which libraries make up your JavaScript. It's common for a date library, an icon pack or a charting tool to take up more space than the business's own code.
• Code splitting. Loading the code for a page only when someone visits that page, instead of the whole app up front.
• Server rendering or pre-rendering. Building the page on the server so the visitor gets real content immediately. For a marketing site this is usually the single biggest win, and it often means moving to a framework such as Next.js.
• Fixing slow interactions. If the page freezes for a moment when someone types in a search box or opens a filter, that's a poor INP result. The fix is finding which component is redoing work it doesn't need to.
• Long lists and tables. Rendering 2,000 rows at once when 20 are visible.
• Images and fonts. The same basics as any other site, but nobody set them up, because React doesn't do it for you.

The cost difference from WordPress is that none of this is settings. It's a developer reading and changing code, then testing that nothing broke. So React speed work is priced by developer time, and the audit matters more because guessing is expensive.

Related guide: How to fix Core Web Vitals on a WordPress site

What gets fixed on a Next.js site?

A Next.js site that's slow is almost always using Next.js against its own defaults. The framework ships with the fast options switched on, so the work is finding where a past developer switched them off or went around them.

Next.js is a framework built on top of React that renders pages on the server. Its own production checklist says Server Components are the default and have no impact on the size of the JavaScript sent to the browser, and it provides built-in image, font and script tools that optimise images, cut layout shift and stop third-party scripts from blocking the page.

So on a slow Next.js site I look for these:

• "use client" at the top of everything. That one line tells Next.js to send a component's code to the browser. Put it too high up and the whole page goes with it. Moving it down to the small interactive parts can cut the JavaScript sharply.
• Plain image tags instead of the Image component. You lose the automatic resizing and modern formats.
• Third-party scripts pasted straight into the page instead of loaded through the Script component with a sensible delay.
• Pages rendered fresh on every visit when the content changes once a week. Those should be built once and cached.
• Data fetched one request after another when the requests could run at the same time.
• Heavy libraries loaded on every page for a feature that lives on one.
• Slow sources behind the site. A sluggish CMS or API makes a server-rendered page slow no matter how clean the front end is.

I've covered the detail in how to fix a Next.js site failing Core Web Vitals.

How do the three platforms compare?

How much do website speed optimisation services cost?

Published prices for website speed optimisation run from under $100 for a flat-rate pass to five figures in dollars for an audit-led project on a large site. For a normal business site, the useful middle is a fixed-price audit followed by a scoped set of fixes.

These are real published prices I found, each linked to the page it came from. They're examples from individual sellers, not market averages, so read them as markers:

Why is the spread so wide? Hours. WebFX says the first round of work generally needs 20 to 100 hours of developer time. A brochure WordPress site sits near the bottom of that range. A React app with real problems in its code sits near the top, and that's why it costs more.

What moves the price up or down?

Six things, in rough order of how much they matter:

• Platform. WordPress fixes are often configuration. React and Next.js fixes are code. Code costs more per fix.
• Number of templates, not pages. A 500-page site with four page layouts is four jobs. A 30-page site where every page was hand-built in a page builder is thirty.
• E-commerce. Carts, checkouts and logged-in accounts can't be cached the simple way, and every change needs a test order.
• Hosting. If the server is the problem, there's a migration on top.
• Third-party scripts. These are a business decision as much as a technical one. Somebody has to agree to remove the heatmap tool nobody has opened since 2023.
• How the result is defined. "Pass Core Web Vitals on mobile for the home page and product pages" costs more than "improve the score", and it's the one worth paying for.

Is a monthly speed plan worth it?

For most small business sites, no. Speed work is mostly a one-off project followed by light upkeep. A monthly plan makes sense when the site changes constantly: a store adding products and apps every week, or a marketing team shipping new landing pages and tracking scripts. In that case sites do get slower again, and someone should be watching. Otherwise fold a quarterly speed check into your normal maintenance arrangement.

What is a Core Web Vitals service, and is it different?

A Core Web Vitals service is speed optimisation with a specific finish line: getting your real-visitor results for LCP, INP and CLS into Google's "good" range. A general speed service might only promise a better score or a shorter load time.

The difference matters because the target changes the work. Chasing the lab score rewards tricks that impress the testing tool, such as delaying every script until the first tap. Chasing Core Web Vitals means improving what real visitors on real phones experience, which is slower to prove (remember the 28-day window) but is the thing Google measures. Google's guidance says it highly recommends site owners achieve good Core Web Vitals for success with Search.

When you compare quotes for a Core Web Vitals service, look for three things: which pages or templates are covered, whether the target is field data or lab score, and what happens if the target isn't reached. The UK sprint in the table above is a good model of scope written down properly: five named pages, three fixes, a before and after report and a fixed 14 days.

Can I speed up my website myself first?

Yes. If you've typed "speed up my website" into Google, there are four things you can do today without a developer, and they'll either fix the problem or make the paid work cheaper.

1. Shrink your images before you upload them. Most slow business sites I open have photos straight off a phone or a photographer, several megabytes each. Resize to the largest size the page will show and compress. I built a free in-browser tool, Under1MB, for this exact chore.
2. Remove scripts you no longer use. Open your tag manager or plugin list and ask of each item: has anyone looked at this tool in the last three months? Old chat widgets, finished ad campaigns and abandoned A/B testing tools are common.
3. Delete unused plugins and apps. Deactivated is not deleted.
4. Ask your host a direct question. "What is my server response time, and what plan would improve it?" The answer tells you whether you have a hosting problem.

What I'd leave to a developer: anything involving caching rules on a store, deferring or delaying JavaScript, critical CSS, and any code change on a React or Next.js site. These are the changes that break things in ways you won't see until a customer tells you.

How long does website speed optimisation take?

Most speed projects take between a few days and a few weeks of work, then about a month for Google's real-visitor data to catch up. The published examples line up with that: a 3 working day audit at the small end and a 14 day audit-and-fix sprint in the middle.

A typical project runs like this:

1. 1

   Measure

   Record field data and lab results for your key page types on mobile, so there is a baseline everyone agrees on.

2. 2

   Audit

   Find the specific causes on each template and rank them by impact and effort. You should get this list in writing.

3. 3

   Fix on a copy

   Make the changes on a staging copy of the site first, then test forms, checkout, menus and tracking.

4. 4

   Go live and re-test

   Release the fixes, re-run the same lab tests and send you the before and after.

5. 5

   Confirm with real visitors

   Check the field data again once the 28-day window has rolled over, and fix anything that slipped.

The last step is the one cheap services skip, because it happens a month after they've been paid.

Things that stretch the timeline: waiting for hosting access, a marketing team that needs to approve each script removal, and stores where every change needs a full test purchase.

Does a faster website bring more sales and better rankings?

Faster sites tend to convert better, and Google does use Core Web Vitals in ranking, but speed is not a magic lever for either. It removes a reason for people to leave.

The best-known evidence is a study commissioned by Google and run by 55 and Deloitte across 37 brand sites and over 30 million sessions. It found that a 0.1 second improvement in mobile speed went with an 8.4% rise in conversion rates for retail sites and 10.1% for travel sites. Read the small print though: every page in the journey had to improve, the data is from late 2019, and it shows a link, not a guarantee for your site.

On rankings, I tell clients the same thing every time. Passing Core Web Vitals won't lift a page with thin content above a better answer. Where pages are otherwise close, the faster one has an edge, and a site that fails badly is giving that edge away.

The sales case is usually the stronger one. On the Wow Vastra boutique store, a UK fashion shop I worked on, the store loads in 1.5 seconds. For a shopper who tapped through from social media on a phone, that's the difference between seeing the product and going back to the feed.

What should I ask before hiring a speed optimisation service?

Ask for the scope in writing, the measurement they'll be judged on, and how they'll avoid breaking your site. A good provider answers all three without hedging.

Questions worth asking:

• Which pages or templates are included?
• Is the target real-visitor Core Web Vitals or the lab score? On mobile or desktop?
• Will you work on a staging copy first, and is there a backup before anything goes live?
• What will you test after the changes? (Forms, checkout, menus, cookie banner and analytics should all be on the list.)
• Do I get a written list of what you changed, so the next developer isn't guessing?
• If the cause turns out to be hosting or a third-party script I refuse to remove, what happens to the quote?
• Is there a re-check after a month?

And the red flags:

• A guaranteed score of 90 or 100. Nobody honest guarantees a number before seeing the site. Even WebFX notes that some sites top out around 75% to 80% because of things like third-party ad scripts.
• Desktop screenshots only. Desktop is easy. Your customers are on phones.
• No audit, straight to a price. That means the same checklist for every site.
• "We'll just install a plugin." Fine as a first step, not as the whole service.
• Asking for full admin access with no mention of backups.
• No mention of what might break. Anyone who has done this work has a list.

When is a rebuild cheaper than optimisation?

A rebuild is the better buy when the slowness is built into how the site was made, so each fix is fighting the foundation. Optimisation is the better buy when the foundation is sound and the problems are on top of it.

Signs you're in rebuild territory:

• A WordPress site on an old multipurpose theme with a bundled page builder and dozens of plugins, where removing any one of them breaks a page.
• A marketing site built as a plain React app with no server rendering, where Google and visitors both get a blank page first.
• A site that has already been "optimised" twice and is still failing.

It doesn't have to be all or nothing. You can rebuild the two or three templates that earn the money (home page, product or service page, landing pages) on a lighter setup and leaving the rest alone.

How can I help with your slow website?

I fix speed and Core Web Vitals on WordPress, WooCommerce, React and Next.js sites, working as a freelancer from Gurugram with clients in India, the UK and the US. It's one of my standing services: technical SEO and Core Web Vitals.

What that looks like in practice:

• I start with an audit of your real-visitor data and your main templates, and send you a ranked list in plain language before any fixing starts. You can take that list to another developer if you want to.
• On WordPress I work across Elementor, Bricks and Oxygen sites, set up caching (WP Rocket is in my regular toolkit), clean up plugins and scripts, and handle host moves when the server is the problem.
• On React and Next.js I do the code-level work: cutting the JavaScript bundle, moving rendering to the server, and putting the image, font and script handling right.
• I test forms, checkout and tracking after every change, and I give you a written record of what was changed.

What I won't do is promise a score before I've seen the site, or tell you a slow site needs a rebuild when it needs three fixes. I'll also tell you when the cheapest answer is deleting a script, which costs you nothing.

I don't publish a price list, because a five-page brochure site and a WooCommerce store with forty plugins are different jobs. You'll get a quote after I've looked at the site.

What should you do next?

Run your home page and your most important money page through PageSpeed Insights on mobile and look at the field data first. If both pass, spend your budget elsewhere. If they fail, paste the report into the Page Speed Fix Planner to see what's behind it, do the four do-it-yourself steps above, and then send me the URL through the contact page. I'll tell you what I'd fix first and whether it's a small job or a bigger one.