Short answer: Core Web Vitals are the three speed and stability numbers Google measures from real visitors to your site: how fast the main content appears (LCP), how quickly the page responds to a tap (INP), and how much the layout jumps around while loading (CLS). To pass, you need LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1, measured on real mobile visitors over 28 days. When we measured fourteen real law firm websites in September 2026, only eight of the thirteen with enough visitor data passed — and the ones that failed were not the small firms. Below is what each metric means, the measured numbers from those fourteen firms, and the fixes ranked by how much they are worth.
This is the technical companion to the law firm website mistakes guide. That article covers what loses a visitor once the page is up; this one covers whether the page comes up fast enough to keep them at all.
What Core Web Vitals actually measure
There are three, and they measure three different kinds of frustration. Google uses them as a ranking signal, but the reason they matter is simpler: each one maps to a specific way a slow site loses a client who was ready to call.
Largest Contentful Paint (LCP) — how long until the page looks ready
LCP is the time until the biggest thing on the screen — usually the hero image or the headline — has finished loading. It is the closest single number to “how long did I stare at a blank or half-built page.” The threshold is 2.5 seconds to pass, and 4 seconds is the line below which Google calls it “poor.” On a phone, on cellular data, in a parking lot after a car accident, every second past two is a share of visitors who go back to the results and try the next firm.
Interaction to Next Paint (INP) — how fast the page answers a tap
INP measures the delay between a visitor tapping something — a menu, a phone number, a form field — and the page visibly responding. The threshold is 200 milliseconds. High INP almost always means too much JavaScript running on the main thread: chat widgets, tag managers, tracking scripts and page-builder bloat all competing to run when the visitor just wanted the menu to open. It replaced the old First Input Delay metric in 2024 and is stricter.
Cumulative Layout Shift (CLS) — how much the page jumps
CLS is the one everyone has felt: you go to tap a button, an image loads above it, the whole page shifts down, and you tap an ad instead. The threshold is 0.1, and it is unitless — it is a score, not a time. On law firm sites the usual causes are images without width and height set, web fonts that reflow the text when they swap in, and cookie banners or promotional bars that push everything down after the page has already appeared.
Lab data versus field data: why your PageSpeed score lies to you
This is the single most misunderstood thing about Core Web Vitals, and it explains our most surprising finding, so it is worth a minute.
When you run a page through PageSpeed Insights you get two different sets of numbers. The field data at the top (“Discover what your real users are experiencing”) is what Google actually uses for ranking — it is collected from real Chrome users visiting your site over the last 28 days. The lab data below it, including the big colored performance score out of 100, is a single simulated load on a throttled mid-range phone. They frequently disagree, and when they do, the field data is the one that counts.
In our sample this gap was dramatic. WilmerHale’s simulated load took a lab LCP of 44.6 seconds and scored 51 out of 100 — and yet it passed Core Web Vitals, because its real visitors, on fast devices and connections, experienced an LCP of 1.5 seconds. Gibson Dunn was the same story: 30.5 seconds in the lab, 1.5 seconds in the field, passed. The large firms get away with heavy sites because their visitors are on office broadband and new iPhones. A small firm whose clients are on older Android phones on cellular data does not have that cushion, which is why the field number is the one to watch.
The practical rule: use field data to know whether you have a problem, and lab data to find out what is causing it. If your site does not have enough traffic for field data yet, the lab score is all you have — but treat it as a worst case, not a verdict.
What we measured: fourteen law firm websites
On 22 September 2026 we ran the homepage of fourteen US law firm websites through PageSpeed Insights on mobile — the same fourteen from our website teardown, spanning solo and boutique firms, regional and national personal injury practices, and five of the largest firms in the country. The table shows the field data Google uses to rank (LCP, INP, CLS, and the overall pass or fail) alongside the lab performance score, so you can see how far apart they sit.
| Firm | Segment | Field LCP | Field INP | Field CLS | Core Web Vitals | Lab score /100 |
|---|---|---|---|---|---|---|
| Sokolove Law | Mass tort | 1.2 s | 147 ms | 0 | Passed | 86 |
| Miller & Zois | Mid-size PI | 1.3 s | 74 ms | 0 | Passed | 61 |
| Gibson Dunn | BigLaw | 1.5 s | 88 ms | 0 | Passed | 63 |
| WilmerHale | BigLaw | 1.5 s | 101 ms | 0.01 | Passed | 51 |
| Shouse Law Group | Criminal defense | 1.6 s | 105 ms | 0.01 | Passed | 88 |
| Davis Wright Tremaine | BigLaw | 1.6 s | 77 ms | 0 | Passed | 63 |
| Farah & Farah | Regional PI | 1.8 s | 113 ms | 0 | Passed | 78 |
| JacksonWhite Law | Multi-practice regional | 2.1 s | 79 ms | 0 | Passed | 57 |
| Morgan & Morgan | National PI | 1.4 s | 295 ms | 0 | Failed (INP) | 77 |
| Cravath | BigLaw | 1.8 s | 107 ms | 0.38 | Failed (CLS) | 91 |
| Stange Law Firm | Family law | 2.6 s | 79 ms | 0.09 | Failed (LCP) | 61 |
| King & Spalding | BigLaw | 2.7 s | 79 ms | 0.88 | Failed (LCP + CLS) | 38 |
| Law Tigers | Motorcycle PI | 3.1 s | 147 ms | 0 | Failed (LCP) | 87 |
| Grossman Attorneys | Boutique PI | — | — | — | Not enough data | 80 |
Five of the thirteen firms with field data failed, and no two failed for the same combination of reasons. That is the useful part: Core Web Vitals is not one problem, it is three, and a firm usually has exactly one of them.
Finding 1: the biggest firms have the slowest builds and get away with it
Cravath scored 91 in the lab but failed on layout shift. WilmerHale and Gibson Dunn took 44 and 30 seconds respectively in the simulated load and passed anyway, on the strength of their visitors’ hardware. King & Spalding scored 38 — the lowest in the sample — and failed on both LCP and a catastrophic 0.88 layout shift score, nearly nine times the threshold. Budget buys design; it does not buy performance, and the field data cushion that saves the big firms will not save a small one.
Finding 2: layout shift is the silent failure
Two of the five failures were CLS, not speed. King & Spalding at 0.88 and Cravath at 0.38 both loaded quickly and then rearranged themselves violently as fonts and images settled in. This is the easiest of the three to miss, because on the developer’s fast machine with everything cached, the shift never happens. It only shows up for a first-time visitor on a phone — which is to say, every prospective client.
Finding 3: one render-blocking problem is nearly universal
Ten of the fourteen sites — and our own homepage among them, which we include below rather than exempt — had “render-blocking requests” as their top opportunity, with estimated savings from 600 milliseconds to over 3.5 seconds. This is stylesheets and scripts that the browser must download and process before it can show anything. It is the highest-value fix on most law firm sites and the one covered first below.
The fixes, ranked by what they are worth
Run your own homepage through PageSpeed Insights first, note which of the three metrics you fail and what the top “opportunity” says, then work down this list to the fix that matches. They are ordered by how often they are the deciding factor and how much time they typically return.
1. Eliminate render-blocking resources (fixes LCP)
The most common and usually the largest single win. The browser stops and waits for every blocking stylesheet and script in the page’s head before it paints anything. The fixes: defer non-critical JavaScript, inline the small amount of CSS needed for the first screen and load the rest asynchronously, and audit what is actually in the head. On page-builder sites the culprit is usually the builder loading its entire stylesheet on every page. This alone moved the estimated savings needle by seconds on nine of our fourteen sites.
2. Fix the layout shift sources (fixes CLS)
Set explicit width and height (or an aspect ratio) on every image and video so the browser reserves the space before the file arrives. Use font-display: optional or swap with a matched fallback so text does not reflow when the web font loads. Give any cookie banner, promo bar or announcement a fixed height reserved in the layout rather than letting it push content down. This is a from-zero fix for the King & Spalding and Cravath category of failure and costs nothing but attention.
3. Optimise the hero image (fixes LCP)
On most law firm homepages the LCP element is the hero photo. Serve it in a modern format (WebP or AVIF), size it to the space it actually occupies rather than shipping a 3000-pixel image into a 700-pixel slot, and mark it high priority so the browser fetches it first. Nine of our fourteen sites had image-delivery savings flagged, two of them over 3 MB — Gibson Dunn at 3.5 MB and Davis Wright Tremaine at 3.4 MB of avoidable image weight on the homepage alone.
4. Cut third-party JavaScript (fixes INP)
Morgan & Morgan was the only INP failure in the sample, at 295 milliseconds, and it is the classic profile: a large national site with chat, multiple tracking pixels and marketing tags all executing on the main thread. Audit every third-party script and ask what each one earns. Load chat widgets after the page is interactive rather than during load, consolidate tag managers, and remove anything nobody can name a reason for. Each removed script gives the main thread back to the visitor’s taps.
5. Improve server response time (helps everything)
Time to First Byte is not a Core Web Vital itself, but a slow server delays every metric downstream. Stange Law Firm and Law Tigers both had field TTFB near or above 2 seconds — the page had not even started arriving that late. Good hosting, a caching layer and a CDN address this. Our hosting guide covers what to look for; the short version is that shared budget hosting is a common cause of a TTFB you cannot fix any other way.
How to check your own site in five minutes
- Go to PageSpeed Insights and enter your homepage URL. Leave it on the Mobile tab.
- Read the field data at the top first. If it says “Passed”, Google is happy with your real-world speed — your job is to keep it that way. If it fails, note which of the three metrics is red.
- If there is no field data, your site does not yet have the traffic for it. Use the lab score as a rough guide and re-check monthly as traffic grows.
- Scroll to the lab section and read the top two or three “opportunities” or “insights”. Match them to the fixes above.
- Run one practice-area page as well as the homepage. They often differ, because the homepage gets the most optimisation attention and the interior pages get none.
- Re-test after each change. Field data updates over 28 days, so lab data is how you confirm a fix worked today.
For context, our own site, legalwebagency.com, scored 67 in the lab that day with render-blocking resources as its top opportunity — the same issue we flag first above. We publish that rather than hide it, because the point of the fourteen-firm table is that almost every site has one of these three problems, and knowing which one is most of the work.
Frequently asked questions
Do Core Web Vitals really affect law firm rankings?
They are a real but modest ranking factor. Google has said they act as a tiebreaker between pages of otherwise similar relevance and authority. For a competitive legal search where several firms have strong content and backlinks, they can be the deciding margin; they will not lift a thin page above a strong one. The stronger reason to care is conversion: a site that passes is a site that visitors do not abandon before it loads.
Why does my site score 90 in the lab but fail Core Web Vitals?
The reverse of the big-firm pattern above. The lab score is one simulated load; the pass or fail comes from real visitors over 28 days. If your visitors are on slower devices or connections than the simulated phone, or if a specific interaction is slow only under real conditions, the field data can fail while the lab score looks fine. Trust the field data.
What is a good PageSpeed score for a law firm website?
Aim to pass all three Core Web Vitals in the field data first; that is the number Google uses. For the lab performance score, 90+ is excellent and 50 to 89 is the range most real sites live in. In our sample the passing sites ranged from 51 to 88 in the lab, which tells you the lab score alone is a poor verdict — a 51 passed and a 91 failed.
How long after I fix something will Core Web Vitals update?
Field data is a rolling 28-day average, so a fix takes up to four weeks to fully show in the pass/fail status even though the improvement is real immediately. Lab data reflects the change the moment you re-test, which is why you use it to confirm a fix and field data to confirm the outcome.
Is a slow website worth rebuilding, or can it be fixed?
Usually fixed. Render-blocking resources, unoptimised images and layout shift are all repairable on an existing site without a rebuild. A rebuild is warranted only when the platform itself is the bottleneck — a page builder that cannot be made to stop loading its full stylesheet on every page, or hosting with a TTFB no caching can rescue. If you are weighing it, the redesign guide covers how to decide.
Want to know which of the three you fail and what it would take to pass? Request the free audit and we will run your homepage and top practice-area pages, read the field data, and tell you the one fix that moves the needle. If the site needs more than a tune-up, our legal web designers build sites that pass all three from launch.
All measurements taken 22 September 2026 from Google PageSpeed Insights (mobile), using field data from the Chrome User Experience Report where available and lab data otherwise. Figures describe those pages as served on that date and will have changed since. This article is commentary on public website performance, not on any firm’s legal services.
