Web & Performance

Four Seconds Is Enough Time to Lose the Case

By ODBA Group · July 13, 2026 · 6 min read

A mother is on her phone at eleven at night, on the kitchen floor so the light does not wake anyone, typing "deportation lawyer" with one thumb. She taps the first firm that looks right. The page goes white and stays white. One second, two, three. Somewhere around the fourth second she taps back and opens the next result instead, and the firm she left never knows she was there. The lawyer behind that white screen may be the best deportation attorney in the borough. It did not matter, because the page asked her to wait longer than a frightened person at eleven at night will wait.

The first few seconds are where the visitor is actually lost

That is not a guess about human patience; it is a measured pattern. Portent's 2022 site-speed study found that website conversion rates are highest for pages that load in the first two seconds, and that the rate drops by roughly 4.42% for every additional second of load time across the first five seconds. Same study, sharper number: a page that loads in one second converts at about three times the rate of a page that takes five. The visitor who leaves does not fill out a form, does not call, and does not come back later to try again. She is counted, quietly, as someone who was never interested, when the truth is she was interested enough to search at eleven at night and only left because the page made her.

A slow page is usually a page being built while you wait

So the question is what actually makes a law firm's page take four seconds, because the cause is almost never the lawyer and almost always the machinery underneath. Most firm sites run on a content-management system, a WordPress install with a theme and a stack of plugins bolted on over the years. When a visitor asks for a page on a site like that, the page does not exist yet. The server has to build it, right then, on the spot: run the software, ask the database several separate questions to fetch the words and the settings, let each installed plugin add its own scripts and stylesheets to the response, and only then assemble the whole thing and send it. The browser on the other end then has to download all of those extra scripts and run them before it can finish painting the page. Every plugin is one more errand the server runs before the visitor sees anything, and the visitor is standing at the door the entire time.

A static page was already finished before she searched

A static HTML site does none of that assembling, because there is nothing to assemble. The page is a finished file that already exists, written once and saved as the exact document the browser will read. When a visitor asks for it, the server does not build anything or query a database; it hands over the file that was already sitting there. That file is served from a content-delivery network, which keeps copies on machines spread across the world, so the visitor in Queens is answered by a machine near Queens instead of one across the country. No software runs to construct the page, no database is queried, no plugin adds an errand, and the physical distance the data travels is short. The result is a page that arrives in the window Portent measured as the one that keeps the visitor, rather than the window that loses her.

Speed is also what decides how many people ever arrive

The white screen costs the firm the one visitor who was already there. Load time also quietly decides how many visitors ever get sent in the first place, because speed is one of the signals the search engine itself weighs. Since its Page Experience update in 2021, Google has used a set of real, measured loading and stability metrics as a ranking factor, which means a slow page is losing the people who reach it and, at the same time, being shown to fewer people to begin with. A fast firm and a slow firm can offer the exact same legal help and the exact same fees, and the fast one still collects more of the searches, because Google hands it more of them and then more of those visitors stay long enough to call. The slow site loses at both ends of the same funnel, and neither loss shows up anywhere the lawyer would think to look.

The fix is structural, not a plugin you add

The reflex, once a firm learns its site is slow, is to install one more plugin, a caching plugin or a speed optimizer, another layer of software on top of the software that was already too slow. That treats the symptom and keeps the cause. The page is still assembled on demand from a database by a stack of plugins; the new plugin just tries to remember the result so it can skip some of the work sometimes. Building the site as static HTML in the first place removes the work entirely instead of caching it, because there was never a database query or a plugin errand to skip. The fix for a page that takes too long to build is a page that was already built, and that decision gets made once, at construction, not patched on after the searcher has already left.

Back on the kitchen floor, the mother is reading the second firm's page now, the one that opened before she could tap away. She will call that firm in the morning. Not because its deportation lawyer is better than the one she left behind the white screen, but because that firm's page was finished before she asked for it, and the other one was still being built when she gave up. The whole contest was decided in about four seconds, before a single word of either site was read.