Law Firm Website Speed: The Five Fixes That Actually Move Core Web Vitals

Short answer: Google's Core Web Vitals thresholds are Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds and Cumulative Layout Shift under 0.1, measured on real mobile visits. Law firm sites fail them for five reasons: a hero image that is too large, a chat widget that loads on every page, tag and tracking scripts, web fonts that swap late, and content that only appears after JavaScript runs. The fifth also hides the site from AI retrieval bots. Fix them in that order.

Why does speed matter for a firm that gets ten visits a day?

Because those ten visits are on phones, at night, from people deciding whether to call. A page that takes five seconds to show the phone number loses some of them, and Google uses the field data from those visits as a ranking input for the map pack and organic results. It is not the biggest ranking factor. It is the cheapest one to fix, and most firm sites have never had it fixed.

There is a second reason that has nothing to do with speed. The same practices that make a site slow (rendering content with JavaScript, loading everything through third-party scripts) also make it invisible to AI retrieval bots, which mostly do not execute JavaScript. A site that passes Core Web Vitals because it renders on the server is also a site an engine can quote.

How to measure it

Two sources, and they answer different questions:

Ignore the lab score as a target. A site can score 60 in the lab and pass in the field, or the reverse. Fix the causes, then wait 28 days for the field data to reflect it.

Fix 1: the hero image

The largest element in the viewport on most firm home pages is a photo of the office or the attorneys, exported straight from a camera at 4,000 pixels wide and three megabytes. That one file is usually the entire Largest Contentful Paint problem.

• Resize to the largest size it is displayed at (typically 1,600 pixels wide for a full-bleed hero, 800 for a half-width one).
• Export as WebP or AVIF at quality 75 to 80. A three-megabyte JPEG becomes 120 kilobytes.
• Set explicit width and height attributes so the browser reserves the space.
• Mark it as high priority (fetchpriority="high") and do not lazy-load it; lazy-load everything below the fold instead.

Fix 2: the chat widget

Live-chat and "intake bot" widgets load a few hundred kilobytes of JavaScript on every page, run on the main thread during load, and are the most common cause of a failing Interaction to Next Paint on firm sites. Ask one question: is someone answering it within a minute during business hours? If not, remove it and put the phone number and the form where the widget was. If yes, load it only after the page is interactive and only on the contact and practice pages.

Fix 3: third-party scripts

Tag managers, heat maps, three analytics tools, a remarketing pixel, a review widget, an accessibility overlay, a font service. Each is a network request and a block of script that runs before the visitor can tap anything. The audit is a list: open the page's network panel, sort by domain, and ask what each third party is for. Keep analytics and the consent tool. Load everything else after interaction or remove it.

Accessibility overlays deserve a specific note: they are heavy, they do not make a site compliant, and several have been the subject of litigation against the sites using them. A properly built page is accessible without one.

Fix 4: fonts

Layout shift on firm sites is usually the headline font arriving late and reflowing the page, plus a review badge or a "call now" bar injected above the content after load.

• Self-host the fonts, preload the one used in the headline, and set font-display: swap with a fallback whose metrics are close.
• Reserve space for anything injected after load, or do not inject it.
• Give every image and embed explicit dimensions.

Fix 5: server-rendered content

If the practice page's text arrives only after a script builds it in the browser, three things go wrong: the Largest Contentful Paint is late, the layout shifts as content appears, and AI retrieval bots that fetch the HTML see an empty shell. Most modern site builders and WordPress themes render on the server by default; single-page application frameworks and some page builders do not. The test is simple: fetch the page with the JavaScript disabled, or with a bot user agent, and see whether the answer text is in the HTML.

curl -A "OAI-SearchBot/1.0" https://yourfirm.com/family-law/ | grep -c "custody"

A zero means the engine sees nothing. The full list of bots and what they need is in which AI crawlers a law firm should allow.

What does not matter for a firm site

• Lab scores in the nineties. Passing field data is the goal; chasing a 98 wastes a developer's week.
• Minifying CSS by hand, critical-CSS extraction, HTTP/3. Real, small, and irrelevant next to a three-megabyte image.
• Switching hosts. Rarely the cause. A slow site on a fast host is still slow.
• A rebuild. The five fixes above apply to WordPress, Webflow, Squarespace and custom sites alike. A rebuild is justified only when the platform blocks server rendering or clean URLs, and it is scoped separately.

Where this sits in the program

Speed is in the first month of the law firm SEO service alongside indexing, redirects and schema, because each fix is cheap and each one blocks the next. It is also the least visible work we do; nobody calls a firm because its Largest Contentful Paint dropped a second. They call because the page loaded, said the answer, and showed the number. The free AI visibility check includes the crawler and rendering test above for every firm we audit.