Why a law firm website has to be fast on a phone, and how to make it fast

A law firm website has to be fast on a phone because that is where legal searches happen and because the person doing the searching is usually in the middle of something bad. They have been in a collision, arrested, served, or told a parent has died, and they are looking for help on the device in their hand with several other results one tap away. The measurable version of that is Core Web Vitals, and web.dev publishes the thresholds: a good Largest Contentful Paint is 2.5 seconds or less, a good Interaction to Next Paint is 200 milliseconds or less, and a good Cumulative Layout Shift is 0.1 or less. This article explains what those three numbers mean for a law firm site, what usually breaks them, and the specific work that fixes each one.

This is general information about law firm websites and web performance. It is not legal advice. Attorney advertising rules vary by state and compliance with them is the firm’s responsibility, not the website company’s.

Why the phone is the only screen that counts

The phone is the only screen that counts for a law firm website because it is both where the visitor is and how Google evaluates the page. Google Search Central states that indexing is mobile-first, meaning the mobile version of a page is the primary version used for indexing and ranking. If the mobile page is slower, lighter on content or harder to use than the desktop one, that is the version being assessed.

The visitor side is more immediate. Legal intent searches cluster around urgent moments. Somebody standing beside a damaged car is searching on a phone, on a cellular connection, often with poor signal, on a device that may be three or four years old. Somebody who has just been released and given a court date is doing the same. Somebody handling a parent’s estate may be at a kitchen table on home wifi, which is the gentlest case and still a phone. None of these people is going to wait while a hero slider downloads.

There is a second, quieter cost. The person in an urgent moment usually opens several results. They are not reading one law firm website; they are comparing three. The site that paints first gets read first, and the site that is still blank when they glance back at it gets closed. Speed does not just affect whether the page is read. It affects which firm gets read at all.

The office computer problem

The office computer problem is that the firm never sees the slow version of its own site. The managing partner loads the site on a desktop, on business fibre, with every asset already cached from the last visit, and it appears instantly. That experience is not evidence. It is the best case, measured on the one machine least like a prospective client’s.

The only honest test is a real phone, on cellular, with the cache cleared, from somewhere other than the office. Do that once and the conversation about page speed usually ends, because the gap between the two experiences on a typical page-builder legal site is not subtle.

The three numbers, and what they actually measure

Core Web Vitals are three field metrics that stand in for three different kinds of frustration: waiting for the page to appear, waiting for it to respond, and having it move under your thumb. web.dev documents all three and publishes a good, needs improvement and poor band for each.

Metric	What it measures	Good	Needs improvement	Poor
Largest Contentful Paint (LCP)	Time until the largest content element in the viewport is rendered	2.5 seconds or less	2.5 to 4 seconds	Over 4 seconds
Interaction to Next Paint (INP)	Latency from a tap or key press to the next visual update	200 milliseconds or less	200 to 500 milliseconds	Over 500 milliseconds
Cumulative Layout Shift (CLS)	How much visible content moves without the user causing it	0.1 or less	0.1 to 0.25	Over 0.25

Every threshold in that table is the one published on web.dev for the metric in question. Two things about it matter more than the numbers themselves.

First, web.dev specifies that these are assessed at the 75th percentile of page loads, segmented across mobile and desktop. A firm does not pass by producing one fast load. It passes when three quarters of real visits are in the good band, which is a much harder and much more honest test.

Second, the three metrics fail for different reasons and are fixed by different work. Conflating them is why “make the site faster” projects stall.

Largest Contentful Paint, the one that decides whether the page is read

LCP is the one that decides whether the page is read, because it marks the moment the main content of the page becomes visible. On a law firm practice area page the largest contentful element is usually the hero photograph, the page heading, or the attorney headshot at the top of a bio. web.dev sets the good threshold at 2.5 seconds or less.

LCP is dominated by four things: how long the server takes to respond, whether a stylesheet or a font is blocking rendering, how large the hero image is and how late the browser discovers it, and whether the element is rendered by JavaScript that had to download and execute first. That last one is worth dwelling on. If the heading of a practice area page is drawn by a client-side framework, nothing is visible until that framework has arrived, parsed and run. Static HTML has the heading in the document, so the browser can paint it in the first pass.

Interaction to Next Paint, the one people feel

INP is the one people feel, because it measures the delay between a tap and something visibly happening. web.dev sets the good threshold at 200 milliseconds or less and reports INP as the metric that replaced First Input Delay in Core Web Vitals.

On a legal site the interactions that matter are opening the consultation form, tapping the phone number, expanding an FAQ and submitting an intake request. Poor INP almost always means the main thread is busy with JavaScript: a chat widget booting, a tag manager running container rules, a slider recalculating, an analytics script batching events. A page with very little JavaScript does not have an INP problem, because there is nothing occupying the thread when the tap arrives.

Cumulative Layout Shift, the one that loses the call

CLS is the one that loses the call, because it is what makes a person tap the wrong thing. web.dev sets the good threshold at 0.1 or less. The classic legal-site version: the person goes to tap “Request a consultation”, a web font finishes loading and reflows the text, or a banner injects itself above the fold, and their thumb lands on something else. They do not diagnose a layout shift. They decide the site is broken and leave.

CLS comes from images and embeds without reserved dimensions, fonts that swap at a different metric size to the fallback, content injected above existing content, and anything that animates layout properties rather than transform and opacity. All four are avoidable by construction rather than by tuning.

What actually makes law firm websites slow

Law firm websites are slow through accumulation, not through one catastrophic decision. Here is the list, in roughly the order we find it when auditing an existing site.

Visual page builders

Visual page builders are the largest single cause. A builder has to be able to render anything the user might drag onto the canvas, so it ships a stylesheet and a JavaScript bundle covering every widget it supports, on every page, whether or not that page uses them. It also generates deeply nested markup, which costs layout time on a phone.

This is not an argument against the convenience. It is an observation that the convenience is paid for on every page load by every visitor, and on a mobile connection the bill is large. Optimisation plugins for these platforms mostly move the cost rather than remove it, because the builder is still the thing generating the page.

Hero sliders

Hero sliders carry several full-resolution photographs and a library to rotate them, to show content that almost nobody waits for. A slider is often the LCP element and the largest single download on the page at the same time. Replacing it with one well-chosen, correctly sized image, or with type on the brand background, is usually the largest single LCP improvement available on a law firm home page.

Attorney headshots straight from the photographer

Attorney headshots straight from the photographer are print-resolution files. They look identical on screen to a version a fraction of the size, because a phone is displaying them a few hundred pixels wide. On a bio page the headshot is typically the LCP element, so it is the worst possible place to leave an unoptimised file.

Chat widgets

Chat widgets are a third party’s whole application loaded into the firm’s page. They fetch their own scripts, styles and often fonts, they run on the main thread, and many of them inject a panel that shifts layout. If the firm has someone genuinely answering chat, the widget can be worth its cost, but it should be loaded after the page is interactive and never allowed to be part of the initial render.

Web fonts

Web fonts are worth their weight on a law firm site, because typography is most of what makes a page read as a firm rather than as a template. They become a problem when a site loads eight weights and both italics from two families, or when the text is invisible until the font arrives. web.dev’s font guidance covers the fixes: subset the characters actually needed, preload the critical font file, and use a font-display strategy that shows fallback text immediately rather than blocking.

Tracking and call-tracking scripts

Tracking scripts multiply quietly. A tag manager container, an analytics property, a call-tracking script that rewrites phone numbers on the page, a remarketing pixel, a heatmap recorder. Each was added by somebody solving one problem. Nobody removed the previous one. Call-tracking scripts deserve special attention on legal sites because they modify the visible phone number after load, which is both an INP and a CLS risk on the exact element the visitor came to tap.

How to actually make it fast

The reliable path is structural. Each of the following removes a category of slowness rather than trimming an instance of it.

Ship static HTML from a content delivery network

Static HTML from a content delivery network is the foundation. If the page is built ahead of time, the server does no work per request beyond returning a file, and a CDN returns it from a location near the visitor. There is no database query, no template render, no plugin chain. This addresses the first component of LCP, which is time to the first byte, and it is the part a firm cannot fix by compressing images.

It also removes a whole class of failure. Static pages do not slow down under load, do not break when a plugin updates, and do not have a login screen that can be attacked. Every site we build is finished HTML on a CDN, which is described on our features page.

Size and encode images for the device asking for them

Sizing and encoding images for the device is the second largest improvement available and the easiest to verify. Three rules cover almost everything on a legal site.

• Serve modern formats. AVIF and WebP both compress photographic content considerably better than JPEG at the same visual quality, with WebP support being essentially universal and AVIF widely supported. Provide a JPEG fallback and let the browser pick.
• Serve multiple widths. A headshot displayed at 320 pixels wide on a phone and 640 on a laptop should exist at both sizes, declared with srcset and sizes so the browser downloads one of them rather than the biggest.
• Always declare width and height, or an aspect ratio, on every image. This is what stops the page reflowing when the image arrives, and it is the single most effective CLS fix on a content site.

Add lazy loading for anything below the fold, and do not lazy load the hero or headshot at the top of the page, because that delays the very element LCP is measuring.

Load fonts so text appears immediately

Loading fonts so text appears immediately means three settings, all covered by web.dev’s font best practices: use font-display with swap so the fallback renders at once, preload the one or two font files used above the fold, and choose a fallback stack with similar metrics so the swap does not move the line. Then cut the number of faces. A serif for display, a sans for body, two or three weights each, is a full typographic system for a law firm and a fraction of the bytes of a loosely specified one.

Budget third-party scripts, and hold the budget

Budgeting third-party scripts means deciding in advance how many the site gets, and requiring each new one to displace an existing one rather than join it. A practical policy for a small firm site:

• One analytics tool, loaded after the page is interactive.
• Chat only if a human or an answering service genuinely responds, deferred until after first paint, never blocking.
• Call tracking only if the firm actively uses the recordings, and configured so it does not reflow the visible number.
• No tag manager unless there is someone who will audit the container quarterly. Otherwise it becomes the place tags go to be forgotten.

The point is not that third-party tools are bad. It is that each one runs on the phone of a person deciding whether to call, and it should have to justify that.

Keep the page’s own JavaScript near zero

Keeping the page’s own JavaScript near zero is what protects INP. A law firm website is documents: practice area pages, bios, consultation terms, a form. Almost none of that needs client-side rendering. When interaction is genuinely needed, small self-contained scripts that do one thing cost far less than a framework runtime shipped to render static text.

Measuring it honestly

Measuring honestly means separating lab data from field data and using each for what it is good at.

PageSpeed Insights, for both at once

PageSpeed Insights is the place to start because it reports both. The top of the report shows field data, drawn from the Chrome UX Report, which Chrome for Developers documents as a dataset of real user experience data collected from opted-in Chrome users. Below it, a Lighthouse run gives lab data: a single simulated mobile load with diagnostics and specific opportunities.

Use the field section to know whether you have a problem, because that is the data assessed at the 75th percentile as web.dev describes. Use the Lighthouse section to find out why, because it names the LCP element, lists render-blocking resources and attributes main-thread time.

Chrome UX Report, for the real answer

Chrome for Developers documents the Chrome UX Report as the official dataset of the Core Web Vitals programme, aggregated from real Chrome users who have opted in to sharing usage statistics. A new or very low-traffic firm site may not have enough data to appear, in which case lab data plus a real-phone test is the best available signal, and the field data will arrive as traffic does.

The test that needs no tools

The test that needs no tools is the one to run first and last. Take a phone off wifi, clear the browser data, open the practice area page the firm most wants to rank for, and count. If you can say “one, two” before the heading is readable, the page is in reasonable shape. If you are still counting at four, the field data will confirm what you already know.

A realistic before and after

A realistic before and after for a small firm site, expressed as the work rather than as invented numbers, looks like this.

Area	Typical before	After
Platform	Page builder rendering every page on request	Pre-built static HTML served from a CDN
Hero	Five-slide slider with full-resolution images	One sized, modern-format image, or type on the brand ground
Headshots	Print-resolution files scaled down in the browser	Multiple widths, AVIF or WebP with fallback, explicit dimensions
Fonts	Two families, all weights, blocking render	Two families, a few weights, subset, preloaded, swap enabled
Third-party scripts	Tag manager, two analytics tags, chat, call tracking, heatmap	One analytics tool, chat only if answered, both deferred
Layout stability	Images and embeds without dimensions	Every image and embed has reserved space
Forms	Third-party embed loaded on every page	Native form on the page, embed loaded only where used

The checklist to work through, in order, because each step makes the next one easier to measure:

1. Run PageSpeed Insights on the three pages that receive the most search traffic, usually a practice area page, a bio and the home page.
2. Identify the LCP element on each. If it is a slider or an oversized image, fix that first.
3. Remove every third-party script that nobody is actively using. This is usually the fastest large improvement after images.
4. Give every image and embed explicit dimensions. That is the CLS fix.
5. Cut font faces and set a swap strategy following web.dev’s font guidance.
6. Re-test in the lab, then wait for field data to catch up, because the Chrome UX Report reflects real visits over time rather than instantly.
7. If the platform itself is the bottleneck, stop optimising and rebuild the pages as static HTML.

Where speed fits with everything else

Speed is a gate, not a differentiator. A fast page that does not say which matters the firm takes, what a consultation costs and who the visitor would be speaking to will not earn a call either. The page still has to do the work described in our guide to how a small law firm website earns the first call, and the structure of a personal injury page or any other practice area page matters just as much as its weight.

What speed does is make sure the page gets the chance. Everything the firm has written, every consultation term stated plainly, every bio with admissions in the right order, is worth nothing to a visitor who left before the first paint. That is the whole argument, and it is why performance is built into the page rather than added afterwards. Our services and every plan on the pricing page are built on the same static foundation, because retrofitting speed onto a page builder is a worse investment than starting from HTML that is already fast.

See it on your own phone

The quickest way to judge any of this is to look at a page built this way on the device your clients use. A demo shows a site for your practice area on your screen, and you can run PageSpeed Insights against it while you are looking at it. Bring the firm’s current site along and test both. The comparison tends to make the decision for itself.