The median legal-tech vendor home page we tested scored 58 out of 100 on Lighthouse's mobile performance test and loaded 1,906 KB of JavaScript, more than two and a half times the 714 KB median for the web as a whole. We ran 23 home pages, from Clio and Filevine to Harvey and Spellbook, three times each on 21 October 2026. Only one passed the test's "good" band of 90.
No public dataset labels a website as legal tech, so this page builds one small sample of its own and sets it against the HTTP Archive's field data for the tools those sites carry, Google's thresholds and the Web Almanac. Every lab figure is ours; every field figure comes from Chrome users.
Why most legal-tech sites have no public speed score
Google judges a page on three field measures from real Chrome users: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness and Cumulative Layout Shift (CLS) for stability. A page passes when 75% of visits reach an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less and a CLS of 0.1 or less, on mobile and desktop separately (web.dev). Search Console reads the last 28 days and rates a group of URLs by its worst metric.
The catch for legal tech is volume. The Chrome UX Report only covers pages and origins that are "sufficiently popular", and Google does not publish the threshold. It also leaves out Chrome on iOS and other Chromium browsers such as Microsoft Edge, which matters when buyers sit at a law firm's managed Windows laptop. A demo page with a few hundred visits a month usually has no page-level score, and Search Console falls back to the whole origin, which the blog and help centre dominate.
That is why this page uses a lab test for the vendor sample. A lab test runs the page once on a simulated mid-range phone and slow connection. It is not what Google ranks on, but it can be run on any page, and it shows the cause of a slow page rather than only the symptom. Our B2B SaaS Website Speed and Core Web Vitals Statistics 2026 post covers field pass rates by platform in detail; we do not repeat them here.
23 legal-tech home pages in the lab
We ran Lighthouse 12.8.2 on each home page in its default mobile mode, three times, and kept the median run by score. The score weights Total Blocking Time at 30%, LCP and CLS at 25% each, and two paint measures at 10% each, so it leans on script cost and loading. The tests ran from Serbia on 21 October 2026. We left out USLege, a legal-tech site we redesigned, so the sample contains no site of ours. We also dropped EvenUp from the averages: its site uses an optimisation service that served Lighthouse a page with no JavaScript at all, so its score of 100 describes the test, not the site.
| Vendor | Platform | Score | Lab LCP (s) | TBT (ms) | Page (KB) | JS (KB) | Third-party requests |
|---|---|---|---|---|---|---|---|
| Plural | Framer | 100 | 1.1 | 2 | 834 | 257 | 38 |
| Everlaw | Contentful, custom front end | 79 | 4.5 | 138 | 9,260 | 886 | 95 |
| MyCase | Astro | 79 | 2.7 | 362 | 5,794 | 3,126 | 155 |
| Lawmatics | Webflow | 75 | 3.4 | 346 | 4,187 | 3,190 | 201 |
| Eve | Astro | 71 | 4.2 | 310 | 5,935 | 1,908 | 100 |
| LawPay | Astro | 69 | 3.0 | 638 | 4,860 | 3,249 | 153 |
| BillTrack50 | Other | 67 | 4.1 | 157 | 7,615 | 1,366 | 38 |
| PracticePanther | WordPress | 67 | 3.9 | 397 | 17,186 | 2,760 | 137 |
| Litify | Webflow | 66 | 3.2 | 270 | 2,898 | 1,626 | 100 |
| NetDocuments | WordPress | 64 | 4.9 | 253 | 10,852 | 1,530 | 117 |
| Legora | Framer | 63 | 9.7 | 100 | 14,129 | 1,172 | 127 |
| Relativity | Other | 58 | 19.9 | 0 | 12,137 | 1,360 | 47 |
| DISCO | Webflow | 57 | 16.2 | 62 | 2,902 | 1,334 | 84 |
| Ontra | WordPress | 57 | 14.0 | 60 | 3,476 | 956 | 48 |
| Smokeball | Webflow | 56 | 21.0 | 213 | 2,540 | 1,906 | 145 |
| iManage | Other | 51 | 8.9 | 332 | 2,743 | 1,172 | 23 |
| Quorum | WordPress | 49 | 24.2 | 307 | 9,087 | 2,712 | 168 |
| Harvey | Next.js | 42 | 11.8 | 1,106 | 27,700 | 1,794 | 96 |
| Filevine | Other | 39 | 28.3 | 678 | 6,421 | 3,487 | 299 |
| Clio | WordPress | 36 | 13.2 | 745 | 27,113 | 4,334 | 252 |
| Juro | Webflow | 35 | 32.9 | 2,576 | 9,741 | 3,068 | 320 |
| Ironclad | WordPress | 32 | 6.9 | 1,269 | 9,426 | 3,001 | 144 |
| Spellbook | Webflow | 28 | 35.3 | 1,655 | 19,471 | 4,775 | 319 |
Source: Octo Agency Lighthouse tests, 21 October 2026; raw reports kept on file. KB is transferred bytes; TBT is Total Blocking Time. MyCase and LawPay have two valid runs.
The median page is heavy. It transferred 7,615 KB, made 182 requests and 127 of them went to third parties. The HTTP Archive's median mobile page in September 2026 was 2,504 KB, and the Web Almanac's 2025 third-parties chapter puts the median mobile page at 79 third-party requests, with about 90% of pages loading at least one. Home pages are the hardest case everywhere: the Almanac's performance chapter found 45% of mobile home pages passing Core Web Vitals against 56% of secondary pages.
Loading is the weak measure. Only one page reached a lab LCP of 2.5 seconds; 17 took longer than 4 seconds. Seven kept Total Blocking Time under 200 milliseconds, and 19 of 23 kept layout shift under 0.1. On Juro and Ontra, the largest element in view at load was the cookie banner's text.
The sales stack, not the platform, separates fast from slow
Most of these sites carry a tag manager, a marketing automation script, a consent banner, session recording, video players and, on the larger vendors, an intent tool and a chat or meeting router. We counted the tools each page loaded from its network requests.
| Tool | Our sample (of 23) | Pass all three, mobile, top 1M origins | Median mobile JS, all origins (KB) |
|---|---|---|---|
| All origins (baseline) | n/a | 46.6% | 714 |
| Google Tag Manager | 22 | 44.2% | 1,174 |
| Microsoft Clarity | 10 | 40.8% | 1,515 |
| Marketo | 9 | 33.2% | 1,612 |
| Wistia | 9 | 46.1% | 1,682 |
| HubSpot | 6 | 36.7% | 1,415 |
| OneTrust | 6 | 38.0% | 1,560 |
| Qualified | 5 | 12.6% | 2,146 |
| Intercom | 4 | 28.1% | 1,803 |
| Hotjar | 4 | 38.1% | 1,601 |
| 6sense | 3 | 21.8% | 1,883 |
| Chili Piper | 3 | 25.7% | 2,896 |
Source: Octo Agency network-request read of the 23 pages; HTTP Archive Core Web Vitals and page-weight technology reports, September 2026, read 2026-10-21
The median page carried seven of the tools we looked for, and nine carried an account identification or intent tool such as ZoomInfo, 6sense or Demandbase. In our sample, the number of tools and the JavaScript weight each track the score moderately, with a correlation of about minus 0.57: the more of either, the lower the score.
The routers stand out. The nine pages with Qualified, Intercom or Chili Piper had a median score of 39, 3,126 KB of JavaScript, 678 milliseconds of blocking time and 168 third-party requests. The 14 without one scored a median 63.5, with 1,363 KB, 185 milliseconds and 95.5 third-party requests. The field data points the same way: sites with Qualified pass on mobile at about a quarter of the top-million rate.
These are correlations. A vendor with a router is usually a larger company with a longer tag list, and neither our sample nor the HTTP Archive can separate one tool's cost from the stack around it. Google's Lighthouse guidance names Intercom and Drift among the widgets suited to a facade, a static button that loads the real script only when clicked, and the same guide swaps a 540 KB YouTube player for a 3 KB placeholder.
Platforms in the sample
We build marketing sites in Webflow and applications in Next.js, so read this section with that in mind. In Chrome field data, Webflow origins pass all three Core Web Vitals on mobile 71.3% of the time against 52.8% for all origins (HTTP Archive, September 2026). In our sample the six Webflow sites scored a median 56.5 and loaded a median 2,487 KB of JavaScript, and the six WordPress sites scored 53 with 2,736 KB.
The two worst pages in the sample, Spellbook and Juro, are Webflow sites carrying 11 and 13 of the tools we counted. Plural, a Framer site with almost no third-party tags, scored 100. The three Astro sites, MyCase, Eve and LawPay, scored 69 to 79 with 1,908 to 3,249 KB of script, so heavy script alone does not sink a page. The platform sets a floor; the tags decide where a site lands above it.
The sites legal-tech buyers run
Law firms are the buyers for most of these vendors, and their own sites form the other half of the legal web. The HTTP Archive tracks Scorpion, a marketing platform whose named industries include personal injury, family law, criminal defence and immigration alongside home services and healthcare. Its 669 mobile origins passed all three Core Web Vitals 83.0% of the time in September 2026, yet only 23.3% of its desktop origins did, with the same 23.3% on desktop layout shift. It is a proxy, because Scorpion is not legal-only, and its sites belong to firms and local businesses, not software vendors.
Older law-firm surveys are thin. A 2022 survey by the web designers Shape Works, reported by Legal Futures, rated one of the top 100 law firms excellent on mobile speed and two thirds poor, with no published method. We cite it only to show how little sector data exists.
What speed does to legal-tech leads
No study ties speed to legal-tech pipeline. The two that cover lead generation are general.
Deloitte and 55 for Google. The study followed 37 brands and more than 30 million sessions over 30 days at the end of 2019. On lead-generation sites, a 0.1 second improvement across four speed measures came with a 21.6% rise in visitors moving from the first form step to submission and a 5.5% rise from the home page to the first form step. It is correlational.
Portent. Its 2022 analysis of about 100 million page views across 20 sites, 14 of them B2B lead generation, found a page loading in one second converted three times as well as a five-second page.
Rankings. Google's documentation, updated in September 2026, says Core Web Vitals "are used by our ranking systems" but that there is no single page experience signal. For a legal-tech vendor competing on "contract management software" or "legal practice management", speed breaks ties between good pages.
The five-page speed test order for a legal-tech site
Field data shows which pages fail; a lab test shows why. We would test in this order, because it follows where buyers land and where a slow page costs a lead.
| Order | Page | Why it goes here | What to check first |
|---|---|---|---|
| 1 | Demo or contact page | Every lead passes through it, and the router and scheduler load here | INP on mobile with the form, router and chat loaded |
| 2 | Home page | It carried the heaviest media and the most tags in our sample | LCP element, hero video, tag count, cookie banner |
| 3 | Pricing or plans page | Small-firm buyers compare here, often on a phone | Layout shift from plan toggles and tables |
| 4 | Top practice-area or solution page | Paid and organic search for "software for family law firms" lands here | LCP image priority, scripts loaded before consent |
| 5 | Security or trust page | Firm IT and risk reviewers read it before a contract | Heavy PDFs, badge widgets, review embeds |
Source: Octo Agency recommendation, based on the lab tests and HTTP Archive data above
For each page, read 28-day field data in Search Console or the Chrome UX Report first, then run the lab test three times on a throttled mobile profile. Test once as a new visitor with the cookie banner showing and once with every script accepted, because many sales tools load only after consent.
What this means for a legal-tech marketing site
The fastest legal-tech pages in our sample did not win on platform. They won on restraint: fewer tags, lighter heroes and no chat router loading with the first paint. The three slowest carried 9 to 13 of the sales and analytics tools we counted, about 3 MB to 5 MB of script, and blocking times above a second.
So set a budget before the tools arrive. Agree an LCP of 2.5 seconds and an INP of 200 milliseconds on mobile for the five pages above, keep a written list of every third-party script with an owner and a reason, load chat and meeting routers on interaction, and check field data monthly rather than once at launch. On a legal-tech build such as our USLege redesign, we would write that script list into the brief, because it is easier to keep a tool off a page than to remove one sales relies on. Our marketing websites service page explains how we scope a build.
