Improve Website Speed 2026: The Complete Guide to a 90+ Score

In short: Website speed in 2026 is measured through Google's three Core Web Vitals: LCP (how long the main content takes to load, target under 2.5 seconds), INP (how fast the site responds to an interaction, target under 200 milliseconds) and CLS (visual stability, target under 0.1). The practical goal is a score of 90 or above on PageSpeed Insights on mobile, with all three metrics in the "good" range for 75 percent of your users. The three highest-impact levers, in almost every site, are: a fast hosting server, compressed images in a modern format, and proper caching. This guide covers each one in depth, with diagnosis tables and practical steps for WordPress, Shopify and code-based sites.

What Determines Website Speed in 2026: Core Web Vitals

A few years ago "website speed" was measured mostly in one number: how long a page took to load. Today Google looks at the whole experience and translates it into three key metrics called Core Web Vitals. These metrics are both part of Google's organic ranking system and the thing that decides whether a visitor stays or bounces. It is worth understanding them before you touch any code:

Two points worth knowing. First, in March 2024 INP replaced the older FID (First Input Delay) as an official core metric. If you are reading an old guide that talks about FID, it is no longer relevant, and INP is a stricter metric that checks every interaction on the page rather than only the first. Second, Google measures the metrics at the 75th percentile of users: it is not enough for the site to be fast on your powerful computer with fast internet, it needs to be fast for three quarters of users too, including those on mobile and cellular networks. LCP and INP are now officially supported across all major browsers, so there is no reason to ignore them.

The Thresholds Did Not Change in 2026: What Google Actually Documents

A claim has been circulating in industry blogs that Google lowered the "good" LCP threshold from 2.5 seconds to 2 seconds, and that sites which used to pass no longer do. We checked it against the official documentation, and as of August 2026 it is not supported. Both Google's official LCP page on web.dev and the Core Web Vitals documentation on Google Search Central still state the same targets: LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less.

Why this matters beyond technical accuracy: if someone is selling you an optimization project on the grounds that "the thresholds got stricter and your site no longer passes", ask for the documentation reference. The rule we work by is simple: a threshold that does not appear in Google's own documentation does not exist. What is genuinely demanding, far more than most site owners realise, is how the measurement works: Google assesses the 75th percentile of real users. The site has to hit the target for three out of every four visits, including those on an old phone over a slow mobile network, not just on your machine.

Field Data vs Lab Data: Why You Have Two Scores

This is the point most guides miss, and it is the number one source of confusion. When you run a PageSpeed Insights test you get two completely different parts:

• Field Data (CrUX) - real data collected from actual Chrome users who browsed your site over the last 28 days. This is what Google looks at for ranking. If the site does not have enough traffic, this section appears empty.
• Lab Data (Lighthouse) - a single simulated run, in a controlled environment, that produces the colored 0 to 100 score. It is an excellent diagnostic tool, but it is not what determines ranking.

The practical takeaway: do not chase a lab score of 100 while your field data shows a problem. Always start from the field data, because it reflects what users actually experience and what Google actually measures. A lab score of 95 with weak field data is worth less than a score of 82 with green field data.

How to Test Website Speed: The Tools

There are dozens of tools, and each calculates the score a little differently. The common mistake is to run between five tools and get confused by the different numbers. The right choice is to stick to one main tool (usually PageSpeed Insights, because it is the tool that counts against Google) and use the others for deep diagnosis:

Tip: the Core Web Vitals report inside Google Search Console is the most important tool most site owners ignore. It groups all your pages into "good", "needs improvement" and "poor" buckets based on real field data, so you can pinpoint exactly which page types are dragging you down instead of checking page by page.

What Slows a Site Down: A Diagnosis-to-Fix Table

Before rushing to apply ten fixes, it is worth diagnosing exactly what is slow. In most sites the usual suspects are few and repeat themselves. The table below links the cause, how it shows up in a test, and the fix:

Breaking LCP Into Four Phases: The Diagnosis That Saves Weeks of Guessing

This is what separates guessing from fixing. "Slow LCP" is a symptom, not a diagnosis, because Google itself defines LCP as the sum of four distinct phases, and each phase has a completely different fix. Compressing images will not help a site whose LCP is stuck in server response time, and changing hosting will not help a site whose hero image is simply discovered late. Google's documentation also gives the target split between the phases, which is a benchmark you can measure against:

Note the practical insight that follows from this table: the two phases that are supposed to take under 10% are exactly the ones that balloon to tens of percent on most sites, because they are caused by how the page was built and not by a small hosting budget. An LCP element that is discovered late, for example a hero image loaded through a JavaScript slider, can add a full second without any test ever flagging a "heavy image". This is also why sites upgrade hosting, pay more every month, and see no change in the score.

How to see this split in practice: in Chrome DevTools, the Performance panel shows the LCP phases in a recording; in a PageSpeed Insights report you can derive the same picture from server response time and the resource waterfall. The rule we apply with clients: before making a single fix, measure which of the four phases owns most of the time, and fix only that one.

INP: The Three Phases Behind Every Interaction

The same logic applies to INP, the metric that replaced FID in March 2024 and measures how fast the site responds to every interaction, not just the first one. Here too Google defines three phases, and here too the fix depends entirely on which phase is running long:

In practice, on most content sites and stores, the main suspect behind high INP is not the site's own code but an accumulation of third-party scripts: pixels, chat widgets, heatmaps, A/B testers and review apps. Each looks negligible on its own, and together they fill the main thread at exactly the moment the user tries to click. If you are running several measurement tools in parallel, it is worth reading how we build clean measurement in our Google Tag Manager guide.

Improving WordPress Site Speed: Step by Step

WordPress powers a large share of sites, which is why the speed question comes up most there. The upside is that there are mature tools that handle most issues in a few clicks. Here is the right order, from most impactful to least:

1. A fast, secure hosting server

This is the foundation of everything. There is no point optimizing images if the server responds slowly. Choose a fast server, close to your audience, with daily backups and available technical support. For our clients we usually recommend managed hosting tuned for WordPress. We covered choosing hosting in our cheap web hosting guide. One option we work with is Cloudways, which offers managed cloud hosting at a low starting cost.

2. A caching plugin and WP Rocket

The goal of caching is to store a ready version of the page so the server does not rebuild it on every visit, which saves significant load time. A plugin like WP Rocket handles caching, code minification and deferred script loading in one simple interface. It is a paid plugin worth every dollar, but remember it is a starting point, not the finish line: a truly heavy site still needs manual work beyond the plugin.

3. Image compression and optimization

In almost every site we optimize, images are the heaviest element. Our rule: do not upload an image heavier than 100KB unless there is a real need. Compress before uploading with a tool like TinyPNG, use WebP or AVIF format, and upload the image at the dimensions it is actually displayed rather than a huge original size.

4. Cleaning up plugins and code

Every plugin adds weight, and sometimes network requests on every page load. Keep plugins to a minimum, delete what is not in use, make sure no two plugins do the same job, and keep everything updated (for both security and speed). Minify your HTML, CSS and JavaScript files, and enable Gzip or Brotli compression at the server level.

If you are still in the planning stage, it is worth reading our comparison of WordPress vs Wix and our guide to building a WordPress site the right way from the start, because speed built into the foundation is far cheaper than speed retrofitted later.

5. PHP Version and the Database

This is the step almost every guide skips, and it directly affects TTFB, which is the phase that should own around 40% of LCP. Make sure the site runs on a current, supported PHP version: moving off an old version is usually an immediate improvement in server response time, without touching design or content. In parallel, a WordPress database accumulates post revisions, drafts, spam comments and leftovers from deleted plugins over the years. A proper table cleanup, not just a one-click "optimise", shortens the time the server needs to build the page.

6. Server-Level Compression: Gzip or Brotli

Server-level compression shrinks HTML, CSS and JavaScript files before they are sent to the browser, so it also improves resource load duration. Brotli is generally more efficient than Gzip on text files. With most managed hosting providers this is an existing setting you only need to confirm is switched on, not a development project. While you are there, verify the server is using a modern protocol (HTTP/2 or above), which lets many files download in parallel rather than in a queue.

7. Third-Party Scripts: The Quiet Source of High INP

Before adding another speed plugin, count how many third-party scripts run on the site. An ad pixel, a chat widget, a heatmap, a review tool and a cookie banner are five scripts before you have even started. With clients we go through the list and ask two questions about each: is it actually in use right now, and does it need to run on every page or just one. On most sites, answering those two questions alone cuts response time more than any caching plugin.

8. What to Fix First: By the Metric That Failed

The order matters as much as the actions. Instead of a flat list of dozens of steps, we map each action to the metric it genuinely improves, and start from the metric that is actually failing for you:

Improving Speed on Other Platforms: Shopify and Code-Based Sites

Not every site is built in WordPress, and while the principles are the same, the implementation differs. This is the angle almost no guide covers:

Shopify

On Shopify you have no server access, but there are two main slowdown sources: a heavy theme and apps. Every app you install injects code into the store, even on pages that do not need it. The key steps: choose a light, modern theme, delete unused apps, optimize product images, and reduce third-party scripts. We expanded on this in our Shopify SEO guide, and if you run a store it is worth looking at our Shopify advertising service.

Code-based sites and Next.js

In code-based sites (for example React or Next.js, which this very site is built on) you have the most control, and therefore the most responsibility. The main tools: server-side rendering (SSR) or static generation, built-in image optimization, code splitting so you load only what is needed, and a global CDN that serves content from the server nearest the visitor. Here, investing in clean code from the start pays off many times over, as we do in every new website build project.

Images: The Number One Cause of Slowdown (and the Easiest to Fix)

If there is one thing worth fixing first, it is images. They are almost always the heaviest component on a page, and they directly affect two metrics: LCP (because the hero image is usually the largest element) and CLS (because an image without defined dimensions makes content jump). The four rules:

• Modern format - WebP or AVIF instead of JPG/PNG. A 25 to 50 percent weight saving with no visible quality loss.
• Correct dimensions - do not upload a 4000px wide image to display it at 800px. Use srcset to serve the right size per device.
• Lazy load - images below the fold load only when scrolled into view, so the initial page loads fast.
• Defined dimensions - set width and height for every image to prevent layout shift (CLS).

Speed and SEO: How Much Does It Really Affect Ranking?

This needs precision, because there is a lot of exaggeration in the market. Speed and Core Web Vitals are indeed an official ranking signal in Google, but they are one signal among many, and usually act as a "tiebreaker" between pages with similar content relevance. A slow site with excellent content can still rank well, and a fast site with thin content will not rise on speed alone. So why invest in speed at all?

Because the real and immediate impact is on user experience and conversions, not just ranking. A slow site increases bounce, hurts conversion rate and raises customer acquisition cost in paid campaigns. The link between speed, experience and ranking is explained in depth in our user experience and SEO guide, and the impact on conversion rate in our improving site conversions guide. If you are just starting to grasp the big picture, begin with what is SEO and our organic SEO service.

A Quick Checklist for Improving Site Speed

Before you start, back up the entire site. Then work through the list in order of impact:

• Measure a baseline in PageSpeed Insights (mobile and desktop) and save a screenshot.
• Make sure the hosting server is fast with a low response time (TTFB).
• Enable caching at the plugin or server level.
• Compress and convert all images to WebP/AVIF.
• Enable lazy loading for images and videos.
• Minify code and enable Gzip/Brotli compression.
• Limit the number of fonts to 3 at most.
• Remove unnecessary plugins and external scripts.
• Set fixed dimensions for images to zero out CLS.
• Measure again after 28 days using field data, not just lab.

Why It Pays: The Business Impact of a Fast Site

Improving speed is not a technical exercise for the score, it is a business move. When the site loads faster, every stage of the funnel improves: fewer visitors bounce before the page even loads, more of them reach the conversion page, and cost per lead in paid campaigns drops because the same budget produces more leads. The table illustrates the chain of impact:

The takeaway: in most cases the investment in speed pays for itself through both the organic and the paid channel, which makes it one of the highest-ROI improvements you can make to an existing site.

7 Common Mistakes in Site Speed Optimization

Over the years we have seen the same mistakes repeat again and again. Avoiding them saves time and money:

Frequently Asked Questions About Site Speed

What is considered a good load time in 2026?

The practical target is an LCP of up to 2.5 seconds for 75 percent of mobile users, which usually translates to a score of 90 or above on PageSpeed Insights. A full load time under 3 seconds is considered fine, but the LCP metric matters more than total load time because it reflects when the visitor sees the main content.

What is the difference between INP and FID?

FID (First Input Delay) measured only the delay of the first interaction on the page. INP (Interaction to Next Paint), which replaced it as an official core metric in March 2024, measures the response time of every interaction throughout the visit, making it stricter and more accurate. The target is up to 200 milliseconds.

Do I have to reach a PageSpeed score of 100?

No. A score of 100 is a simulated lab score, while Google ranks by real field data. A site with a score of 85 and green field data (all metrics "good") is better than a site with a score of 98 and weak field data. Chase the metrics in green, not the perfect number.

How much does speed affect Google ranking?

Core Web Vitals are an official ranking signal, but one of many, acting mainly as a tiebreaker between pages with similar content relevance. The larger and more direct impact is on user experience, bounce rate and conversion rate, which in turn indirectly affect organic performance.

Why is the mobile speed score lower than desktop?

Because PageSpeed simulates a mid-range mobile device and a slower cellular network, which is a much harsher scenario than a computer with fast internet. And Google ranks mainly by the mobile experience (Mobile-First), so the mobile score is the one to prioritize.

Is a plugin like WP Rocket enough on its own?

For most sites a quality caching plugin gives a significant jump within minutes, but it does not fix a slow server, giant images or a heavy theme. It is an excellent starting point, not a substitute for optimizing the infrastructure and content.

How much does site speed optimization cost?

The cost depends on complexity: a standard WordPress site with caching and image issues can be improved at a relatively low cost, while a heavy store or a custom code site requires deeper work. The first step is always cheap: an accurate diagnosis that identifies the two or three factors that truly matter, so you do not waste budget on marginal fixes.

Did Google change the Core Web Vitals thresholds in 2026?

No. As of August 2026, Google's official documentation still defines the same thresholds: LCP up to 2.5 seconds, INP up to 200 milliseconds and CLS up to 0.1, measured at the 75th percentile of real users. Claims about a new 2-second LCP threshold appear in industry blogs but not in Google's own documentation.

I improved the site, so why has the Search Console score not moved?

Because the field data Google reports is collected from real users over a rolling 28-day window. Even if the fix worked perfectly, it enters the average alongside 27 days of older data, so the change appears gradually rather than the next day. To confirm a fix worked immediately, use lab testing, and check field data after roughly three to four weeks.

What is fetchpriority and when should it be used?

It is a hint telling the browser that a particular resource is especially important and should start downloading early. The most common correct use is on the hero image, that is, on the LCP element, in order to shorten the delay phase before loading begins. Use it on one central element only: marking several images as urgent cancels out the benefit.

Which LCP phase is usually to blame?

It tends to be one of two extremes. On WordPress sites running on cheap shared hosting, the time is usually swallowed by TTFB, meaning the server. On design-heavy sites with a slider or video at the top of the page, the culprit is usually the delay phase before loading starts, because the LCP element is only discovered after JavaScript runs. Both cases look identical in the overall score and require completely opposite treatment, which is why you measure before you fix.

Want a Fast Site That Ranks and Converts? We Are Here

At SFB we have been supporting businesses for over 11 years, managing campaigns worth tens of millions of shekels a year, and we see every day how much site speed directly affects leads and revenue. We build fast sites from the start and thoroughly improve existing ones: accurate diagnosis, treating the root of the problem rather than the symptoms, and measuring by real field data. Want to know where your site stands and what can be improved? Leave your details and we will get back to you with an initial diagnosis.

For ecommerce stores the speed impact is even larger, because every extra second on a product page meets abandonment head on. See also our guide to online store promotion on Google.