Website mistakes: title card beside a flat illustration of a browser window with a dark header bar carrying one small scarlet button, four grey content cards stacked down the left, and a large grey image block with text lines to the right

Lists of website mistakes all name roughly the same four problems — slow pages, a weak call to action, confusing navigation, nothing designed for a phone — and they are right to. Those are the faults we find most often too. The trouble is the numbers bolted onto them. The same figures circulate from list to list: 40% of visitors leave after three seconds, 88% never return after a bad experience, one second of delay costs 7% of conversions. Follow any of them back and the trail stops at another list.

That matters, because you cannot act on a number you cannot check. So here are the same problems with the figures Google actually publishes — and one claim that is repeated so often it has become folklore, which its own source contradicts.

How slow is too slow, and who decides?

Not three seconds, because nobody official ever said three seconds. Google publishes a threshold, and it is a different number measured a different way. For Largest Contentful Paint — the moment the biggest thing on screen finishes drawing — the guidance is that “sites should strive to have Largest Contentful Paint of 2.5 seconds or less”. The same page defines what is being timed: LCP reports the render time of the largest image, text block or video visible in the viewport.

The measurement method matters more than the number. web.dev’s Web Vitals overview says the threshold should be judged at the 75th percentile of page loads, split across mobile and desktop. That is not a lab test on your own laptop. It means three quarters of real visits, on real phones and real connections, have to come in under 2.5 seconds — which is why a site that feels quick in the office can still be failing.

There are two other published thresholds worth knowing, and together they are the whole picture:

MetricWhat it timesGood
LCPHow long the largest visible element takes to draw2.5 seconds or less
INPHow quickly the page responds after a tap or click200 milliseconds or less
CLSHow much the layout jumps while loading0.1 or less

Why the site is slow, and what to do about each cause, is the subject of our article on whether three seconds is really the limit.

A labelled diagram headed WHAT GOOGLE ACTUALLY PUBLISHES listing three metrics with their good thresholds: LCP 2.5 seconds or less in scarlet, INP 200 milliseconds or less, and CLS 0.1 or less, with a footnote reading measured at the 75th percentile of real visits
A wide labelled diagram headed THE MOBILE VERSION IS THE ONE INDEXED showing a desktop browser window on the left holding six content blocks and a narrow phone outline on the right holding only four, with two blocks greyed out and struck through, and a scarlet arrow running from the phone to a box marked Google index

Does Google punish a site that is not mobile-friendly?

No — and this is the claim worth correcting, because the usual version of it is both unsourced and the wrong shape. Google’s mobile documentation contains no penalty, no deduction and no demotion. What it contains is this: “Google uses the mobile version of a site’s content, crawled with the smartphone agent, for indexing and ranking”. The same page is careful to say that a mobile version is not required for inclusion in Search, but that it is very strongly recommended.

Read that again, because the consequence is sharper than a penalty would be. The mobile version is not a lesser copy that Google checks second. It is the copy Google reads. Anything your theme hides on a small screen — a specification table, a block of service detail, the paragraph that answers price — is not demoted. It is simply not there to be indexed.

The mobile version is not the second copy Google checks. It is the copy Google reads.

That reframes the fix. It is not about scoring well on a mobile test; it is about content parity. Whether the thing is usable under a thumb is a separate question, and our article on whether your website is genuinely easy to use on a phone takes that one on.

A labelled square comparison headed DOES THE NUMBER HAVE A SOURCE with two panels: the upper panel marked Repeated lists three unattributed claims each ending in a scarlet question mark, and the lower panel marked Published lists three figures each followed by a named document and a small tick

Which numbers should you ignore?

A figure is worth acting on when you can follow it to a named document and read the method. Apply that test to the usual list and most of it falls away. “88% of online shoppers won’t return” has no named study attached in any version we have read. “A software company saw a 200% increase” names no company, no period and no baseline, which makes it an anecdote in the costume of evidence.

The published figures survive the same test easily, because they come with their method attached. Google’s guidance on Interaction to Next Paint states that “An INP below or at 200 milliseconds means a page has good responsiveness”, and that above 500 milliseconds responsiveness is poor. The same page gives the reason it is worth measuring at all: Chrome usage data shows that 90% of a user’s time on a page is spent after it loads. That is a claim you can go and check, which is the only kind worth repeating.

A test you can apply in ten seconds

  • Is a document named? Not “research shows” or “studies find” — an actual title you could search for.
  • Is the method stated? Measured how, on whom, over what period. The Core Web Vitals thresholds say 75th percentile of real page loads; that is a method.
  • Does it name the business? “A B2B company” is not a case study. If it cannot be named, it cannot be checked.

So which website mistakes are actually worth your time?

The ones you can measure before and after. In the sites we revamp, these are the four that change the enquiry count most reliably:

If none of that is obviously your issue, the honest next step is to measure rather than guess, which our guide to auditing a page without guessing covers. And if the site produces no enquiries at all, the fault is usually earlier than any of these: why your website gets no enquiries works through it stage by stage.

Frequently asked questions

Is three seconds the limit for page load time?

It is not a published standard. Google’s own threshold is for Largest Contentful Paint and sits at 2.5 seconds or less, judged at the 75th percentile of real page loads across mobile and desktop. The practical difference is the measurement: three quarters of actual visits must clear it, so a site that loads instantly on office wifi can still be failing on a mid-range phone.

Will a non-mobile-friendly site be removed from Google?

Not removed, but much of it may never be indexed. Google’s documentation says a mobile version is not required for inclusion in Search, while strongly recommending one. The real risk is content parity: because the mobile version is the one crawled for indexing, anything your layout drops on a small screen is not available to be indexed at all.

Where can I check my own numbers?

The Core Web Vitals figures come from real visits, so they are reported in Google Search Console under Core Web Vitals and in PageSpeed Insights, which shows field data alongside a lab test. Treat the field data as the real answer and the lab score as a diagnostic. Checking takes a few minutes and settles most arguments about whether a site is actually slow.

Where iRevamps fits

Almost none of this needs a new website. A site that loads slowly, hides half its content on a phone and buries its navigation usually needs those three things fixed, in that order, on the site you already have — which is what our web development and design service does most weeks. If the structure underneath turns out to be the real problem, our guide to choosing between a revamp and a full rebuild sets out how to tell the difference.