# Law Firm Website Speed and Core Web Vitals, Measured _There are three Core Web Vitals and First Input Delay has not been one since 2024, which most firm-facing advice has not noticed. Fifteen firm sites loaded on a throttled phone: only three met the loading threshold on every page, and scripts tracked slow loading more closely than images did._ **The short answer** **There are three Core Web Vitals and one of them changed in 2024.** Largest Contentful Paint should land inside 2.5 seconds, Interaction to Next Paint inside 200 milliseconds, and Cumulative Layout Shift at 0.1 or below. First Input Delay is gone, and most advice written for law firms still names it. **Loading is where firm sites fail, and layout shift mostly is not.** Loaded on the throttled mobile profile audit tools use, only three of fifteen firms kept every page inside the loading threshold, while fourteen of fifteen stayed inside the layout-shift one. **The usual advice points at the wrong suspect.** Across these pages, script weight tracked slow loading more closely than image weight did, and the median page reached nine third-party hosts before it finished. Site speed is the one website subject where a firm can be told to fix a metric that no longer exists. It can buy a plugin for a problem it does not have, and still end up with a slow site. The vocabulary moves, the advice lags, and almost nobody checks against real pages. So here is what the three metrics are now, and what Google does and does not claim for them. Then what actually loads slowly, across fifteen law firm sites measured rather than discussed. - **2.5 seconds** - The loading threshold your main content should land inside - **75th percentile** - Where Google measures, across real visitors rather than one test - **3 of 15** - Firms whose every page met the loading threshold on a throttled phone - **9 hosts** - Outside domains the typical firm page contacts as it loads ## The three metrics, and the one that left Core Web Vitals is a set of three measurements, and Google states that stable ones "won't change more than once per year." Here is the current set with the thresholds attached. | Metric | What it measures | Good | Poor | | --- | --- | --- | --- | | Largest Contentful Paint | When the biggest thing on screen finishes loading | 2.5 s or less | over 4 s | | Interaction to Next Paint | How long the page takes to respond when tapped | 200 ms or less | over 500 ms | | Cumulative Layout Shift | How much the page jumps around while loading | 0.1 or less | over 0.25 | **First Input Delay is not on that list and has not been since 2024.** Google promoted its replacement "with the intent to eventually retire FID," and dates the handover: "INP became a stable Core Web Vital metric in 2024." This matters because the advice has not caught up. Among the law firm speed guides measured for this article, more pages still name First Input Delay than name its replacement. If a proposal you are reading optimizes for FID, it was written against a standard Google stopped measuring. **Three supporting metrics get confused for Core Web Vitals.** Time to First Byte, First Contentful Paint and Total Blocking Time are all useful diagnostics, and Google classes them as supporting metrics rather than Core Web Vitals. A report that grades your firm on Total Blocking Time is telling you something real about your JavaScript, but it is not telling you your Core Web Vitals. ## Where Google actually measures, and what it claims Two misunderstandings cause most of the wasted money in this area, and both are settled by Google's own wording. **The assessment is not your test result.** Core Web Vitals are assessed at the **75th percentile of real page loads**, split between mobile and desktop. Google chose that point for two reasons. It should "ensure that a majority of visits to a page or site experienced the target level of performance" without being "overly impacted by outliers." So a single score from an online tool is a diagnostic, not a verdict. It runs on one simulated device from one location at one moment. Your assessment comes from what your actual visitors experienced, on their actual phones, on their actual networks. None of the nine law firm guides measured mentions the 75th percentile at all. **And the ranking claim is narrower than you have been told.** Google says plainly that "Core Web Vitals are used by our ranking systems." It then says three other things that rarely travel alongside that sentence: - "There is no single signal. Our core ranking systems look at a variety of signals that align with overall page experience." - Good scores "doesn't guarantee that your pages will rank at the top of Google Search results." - Search "always seeks to show the most relevant content, even if the page experience is sub-par." Read together, that supports a real but modest claim. Speed is used, and speed is not a lever that lifts a thin page above a better one. Two thirds of the guides measured call it a ranking factor, one of them still in the future tense, and not one carries any of the qualifications above. ## What fifteen firm sites actually do Each firm's homepage and contact page loaded three times in a throttled mobile browser, on the same profile public audit tools use. The middle result of the three is the figure below. | Measure | Fastest page | Typical page | Slowest page | | --- | --- | --- | --- | | Largest Contentful Paint | 1.3 s | 3.2 s | 21.1 s | | Cumulative Layout Shift | 0.000 | 0.013 | 0.226 | | Transferred weight | 0.18 MB | 1.52 MB | 8.58 MB | | Requests | 18 | 69 | 206 | | Third-party hosts contacted | 0 | 9 | 34 | | Images with no size set | 0 | 7 | 122 | Take the worst page at each firm, since a visitor meets whichever page they land on. **Three firms in fifteen kept every page inside the 2.5-second loading threshold. Fourteen in fifteen kept every page inside the layout-shift threshold.** A third of the firms had at least one page in the poor band for loading. That asymmetry is the useful part. **Loading is the problem on these sites and layout shift is largely solved.** If your budget buys one fix, it belongs on what loads, not on what jumps. **What these numbers are not.** This is a throttled lab test, which is harsher than a decent phone on decent wifi, and it is not a Core Web Vitals assessment. It is the profile a firm sees when it runs an audit tool. Treat the figures as a comparison between these sites on equal terms, not as the grade Google holds for any of them. ## The suspect most advice names, and the one the numbers point at Rank the 29 pages by loading time and see what moves with it. Script requests track slow loading more closely than image weight does, and JavaScript shows up near the top in three different forms. | Moves with slow loading | Strength of association | | --- | --- | | Main-thread blocking time | Strongest | | Number of script requests | Strong | | Script bytes | Strong | | Total page weight | Moderate | | Blocking scripts in the head | Moderate | | Third-party hosts | Moderate | | Image bytes | Weaker | | Page complexity | Weakest | Now set that against the advice, where two thirds of the guides measured tell firms to compress images. A third mention third-party scripts at all. **The most-repeated recommendation addresses the weaker association, and the stronger one goes mostly unmentioned.** Be careful how much weight that carries. This is a rank association across 29 pages, which points at where to look first rather than proving what causes what. Images still cost real bytes, and the heaviest page measured transferred 8.58 MB. The honest reading is that compressing images is worth doing and is not where the biggest wins are hiding. ## What those nine hosts are doing The typical firm page here contacts nine outside domains before it finishes, and the heaviest contacts thirty-four. The recurring names are instructive, and two of them are worth acting on. **Most of these firms load their fonts from Google's servers.** That spends a connection on the critical path for files that could sit on the firm's own domain. It is one of the cheapest fixes available, and the advice almost never mentions it. **Call tracking appears on more than half of them.** That is a tool bought to measure where inquiries come from, loaded as script weight on every page a visitor touches. It may well earn its place, but it should be a decision rather than an accident, and somebody should know what it costs. The wider point is that the tag manager is where speed goes to die quietly. Every tool added over five years is still firing, long after whoever asked for it stopped reading the reports. ## Where the first byte comes from One cause sits underneath all the others and gets blamed last, which is the server a firm is renting. Time to First Byte measures how long the host takes to begin answering, before any image or script is requested. Google counts it as a supporting metric rather than a Core Web Vital, which is a distinction most reports blur. Any speed tool reports the first byte separately from everything that follows, so this is one number a firm can check for itself in a minute. That distinction is worth holding onto when a vendor quotes the figure at you. A poor first byte drags your loading metric down because everything behind it queues. Improving it is not the same as passing a Core Web Vital, and a report grading you only on it measures your hosting bill rather than your visitor's experience. The practical reading for a firm on shared hosting is that the cheapest plan is frequently the thing capping every other improvement. Compressing images on a server that takes most of a second to respond is tidying a room while the roof leaks. Moving to a better hosting plan is frequently less work than the long list of optimizations it would otherwise replace. ## About those images with no size set The typical page here carries seven images with no width or height specified, and one carries 122. The standard advice says that causes layout shift, and this sample does not support that conclusion. Layout shift was fine on fourteen of fifteen firms despite all those unsized images, because images loading below the fold do not move anything the visitor is looking at. Setting dimensions removes a risk rather than fixing a measured fault. So do it, because it is nearly free and it protects you when a layout changes. Do not expect it to move a score that is already passing. ## The page that earns the call is the slower one Splitting the measurement by page type produced the result worth acting on first. The typical contact page loaded its main content in 3.4 seconds against 2.9 seconds for the typical homepage, and it did that while carrying less weight. That combination rules out the obvious explanation. Contact pages here transferred about 1.2 MB against 1.8 MB for homepages, so they are lighter and still slower. The weight is not what is holding them up. What they carry instead is machinery: a form, an embedded map, a spam check, sometimes a chat widget. Each of those arrives as script and runs before the page settles. The median contact page reached one more third-party host than the median homepage, on a page with fewer pictures and less text. **Four of the fourteen firms with both pages had a contact page more than a quarter slower than their homepage.** On the worst of them the contact page took 12.4 seconds against 2.8 for the homepage, optimizing the page people browse and neglecting the page they use. This is the cheapest audit on the list and almost nobody runs it. Test the contact page separately from the homepage, because law firm client intake happens on the slower one. ## What to do, in order Ordered by what the measurement found, not by what is easiest to sell. - **Get your real numbers, not a test score.** Search Console reports Core Web Vitals from actual visitors at the 75th percentile. That is the assessment; a tool run is a diagnostic for chasing causes. - **Audit the tag manager.** List every script firing, find the owner of each, and remove what nobody reads. This is where the strongest association in the measurement lives. - **Self-host your fonts.** Most of these firms do not, and it removes a third-party connection from the critical path. - **Move scripts out of the head.** Blocking scripts above your content delay everything behind them. - **Then compress the images.** Worth doing, and the heaviest page here was 8.58 MB, so it is not nothing — just not first. - **Set width and height on images.** Nearly free, prevents a future problem, and will probably not change today's score. - **Check the contact page separately.** On several firms here it behaved differently from the homepage, and it is the page that earns the call. - **Ignore anything optimizing First Input Delay.** That metric was retired in 2024. ## Common questions ### What are the Core Web Vitals in 2026? Largest Contentful Paint at 2.5 seconds or less, Interaction to Next Paint at 200 milliseconds or less, and Cumulative Layout Shift at 0.1 or less. Each is assessed at the 75th percentile of real loads, and First Input Delay was retired in 2024. ### Does site speed affect my law firm's search rankings? Google says Core Web Vitals "are used by our ranking systems" but that there is "no single signal" and good scores do not guarantee top placement. Treat speed as one input among many, and as something that affects whether a visitor stays regardless of ranking. ### Why does my audit tool score differ from Search Console? They measure different things: an audit tool runs one simulated load, while Search Console reports what real visitors experienced at the 75th percentile. Disagreement between them is normal and the real-visitor data is the assessment. ### What slows law firm websites down most? In this sample, script weight and main-thread blocking tracked slow loading more closely than image weight. The typical page contacted nine third-party hosts. Start with what is loading scripts before resizing photographs. ### Is a slow site worse than a site with thin content? By Google's own account, no: Search "always seeks to show the most relevant content, even if the page experience is sub-par." Speed is worth fixing on its own merits, not as a substitute for having something worth reading. **What to take away** - The three Core Web Vitals are LCP at 2.5 s, INP at 200 ms and CLS at 0.1. First Input Delay was retired in 2024 and most firm-facing advice still names it. - Your assessment is the 75th percentile of real visitor loads, not a score from one test run. - Google says Core Web Vitals are used in ranking, that there is no single signal, and that good scores guarantee nothing. - On a throttled phone, only three of fifteen firms met the loading threshold on every page, while fourteen met the layout-shift one. - Scripts tracked slow loading more closely than images did, and the typical page reached nine third-party hosts. - Setting image dimensions removes a risk rather than fixing a fault, on evidence from these sites. ## Where these figures come from Fifteen firm sites, a homepage and a contact page each, 29 pages, measured 23 October 2026. The browser was a throttled mobile Chromium at 1.6 Mbps with 4× CPU throttling, the profile public audit tools use. Each page was loaded three times and the median recorded. Per page the medians ran, across fastest, typical and slowest: LCP 1,300 / 3,180 / 21,076 ms; CLS 0.000 / 0.013 / 0.226. Then transferred 0.18 / 1.52 / 8.58 MB; requests 18 / 69 / 206; third-party hosts 0 / 9 / 34; images with no dimensions 0 / 7 / 122. By page type, contact pages ran a median LCP of 3,398 ms against 2,888 ms for homepages, on 1.16 MB against 1.84 MB. Per firm, worst page: 3 of 15 inside the LCP threshold, 5 of 15 with a page in the poor band, and 14 of 15 inside the CLS threshold. LCP varied more than 50% between passes on 4 of 29 pages. The median is the figure used, and the spread sits in the research notes. Transferred bytes come from content-length headers, which are often absent on compressed responses, so weights are a floor. Interaction to Next Paint cannot be measured without real interactions and is not reported; main-thread blocking time stands in as a labeled proxy. Nine competing guides were measured alongside, mean 2,249 words, and three further candidates returned 404. **Sources** - [web.dev: Core Web Vitals](https://web.dev/articles/vitals) — the current metric set - [web.dev: defining the thresholds](https://web.dev/articles/defining-core-web-vitals-thresholds) - [Google: page experience](https://developers.google.com/search/docs/appearance/page-experience) — the ranking language - [web.dev: LCP](https://web.dev/articles/lcp) - [web.dev: INP](https://web.dev/articles/inp) - [web.dev: CLS](https://web.dev/articles/cls) - [web.dev: TTFB](https://web.dev/articles/ttfb) - [Chrome UX Report](https://developer.chrome.com/docs/crux) - [Google: CWV report](https://developers.google.com/search/docs/appearance/core-web-vitals) - [Google: people-first content](https://developers.google.com/search/docs/fundamentals/creating-helpful-content) - [web.dev: optimize LCP](https://web.dev/articles/optimize-lcp) These are lab measurements rather than field data. Google assesses Core Web Vitals at the 75th percentile of real user loads, and three scripted lab loads from one location are not that. No figure here is any firm's Core Web Vitals assessment. Rank associations describe these 29 pages and point at where to look first; they are not causal claims. Counts are per firm, taking each firm's worst page, because a visitor meets whichever page they land on.