When relatives search for a care service, every second counts – literally. Around 53 percent (Think with Google) of mobile visitors leave a page that takes longer than three seconds to load, and since roughly 59 percent (Statista) of web traffic now happens on mobile, load time decides directly whether a search turns into a call. Google summarises this loading experience in three measurable values, the Core Web Vitals: Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. They are not a technical afterthought but a ranking signal and an enquiry factor at once. This article explains the three values and their good thresholds in plain terms, shows why a slow page loses stressed relatives in particular, and describes which levers – images, hosting, fonts and code – make a care website measurably faster. Unlike the article on the care website optimised for mobile relatives, which deals with operation and layout, this one is about pure metrics, speed and visibility.
Key takeaways
- Around 53 percent (Think with Google) of mobile visitors leave a page that takes longer than three seconds to load. Going from one to three seconds raises the bounce probability by 32 percent, and at five seconds by 90 percent (Think with Google).
- The three Core Web Vitals have clear good thresholds: Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, Cumulative Layout Shift under 0.1 (Google Search Central). A page counts as fast only when all three hold.
- Since 12 March 2024 (Google Search Central), Interaction to Next Paint has replaced the former First Input Delay. It measures the whole interaction up to the next visible update and is driven by the slowest interactions in a session, not the first one.
- Assessment runs on real page views from the Chrome UX Report at the 75th percentile (Google Search Central): a page counts as fast only when three of four visits are good. A single lab test on a fast machine does not replace this field data.
- Images are the most common brake: on 73 percent (HTTP Archive Web Almanac) of mobile pages an image is the LCP element, and 16 percent lazy-load exactly that image. Compress, declare dimensions, load it with priority and self-host fonts.
- Core Web Vitals are a confirmed ranking signal among many and will not lift a page with weak content. Because Google measures in the field over weeks, regressions surface late, so checking the values belongs in ongoing maintenance.
Why Load Time Decides Enquiries and Visibility
In the care context, speed is not a comfort feature but a direct lever for the first contact. The need for care usually arises under pressure: after a fall, a diagnosis or a discharge from hospital. In this situation relatives research on the move and have neither the patience nor the nerves to wait for a sluggish page. The figures are clear: if the load time rises from one to three seconds, the probability of a bounce increases by 32 percent (Think with Google); at five seconds it climbs by 90 percent (Think with Google). Every second saved is therefore directly measurable in calls and enquiries.
Beyond user experience comes visibility. Search engines assess pages via the mobile view and factor the Core Web Vitals into the ranking as a signal (Google Search Central). A slow, unsteadily building page thus has a double problem: it loses visitors who are already there, and it is found less often by new ones. For a care service that wants to be visible in its region, local findability therefore depends directly on the technical quality of the website. The demand is real: at the end of 2023, around 5.7 million (Destatis) people in Germany were classified as in need of care, cared for predominantly at home with the involvement of relatives – exactly the mobile audience that rewards fast pages.
A Ranking Signal, but No Miracle Cure
Speed Is a Conversion Question
The Three Core Web Vitals Explained Clearly
Behind the clunky term sit three everyday questions: how quickly is the main content visible, how promptly does the page react to an input, and how steadily does it build without jumping? That is exactly what Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift measure. For each value there is a clear good threshold that Google documents publicly (Google Search Central).
LCP – Loading Feel
Largest Contentful Paint measures when the largest visible content – usually an image or a heading – has loaded. A value under 2.5 seconds (Google Search Central) is considered good. It best describes the perceived speed of a care website.
INP – Responsiveness
Interaction to Next Paint measures how quickly the page reacts to taps and clicks. Under 200 milliseconds (web.dev) it is considered good. A high value feels as if the page is hanging – a common annoyance especially on older smartphones.
CLS – Stability
Cumulative Layout Shift rates how steadily the content builds. If the text jumps because an image loads late, the value rises; under 0.1 (web.dev) it is considered good. On forms, a low CLS prevents mis-taps when submitting an enquiry.
It is important that these three values are considered together. A page that loads quickly but hangs on the first tap fails the check just as much as one that reacts promptly but whose content keeps shifting. Only when LCP, INP and CLS are in the green together does a page count as fast in the sense of the Core Web Vitals.
INP Since 2024: the New Metric for Responsiveness
The Core Web Vitals are not a rigid construct. On 12 March 2024 (Google Search Central), Google made Interaction to Next Paint an official Core Web Vital, replacing the earlier First Input Delay. The reason: the old metric only captured the delay until the first reaction, while INP measures the entire interaction up to the next visible update – a considerably more honest picture of how responsive a page feels.
For care websites this is relevant because their audience is on the move above average with older or cheaper devices, where heavy code is especially noticeable. A page that briefly hangs when opening a menu or submitting a form costs trust – and, in case of doubt, the call. The switch to INP made visible how many pages have catching up to do here: the share of mobile pages with all-round good Core Web Vitals stood at 43 percent (HTTP Archive Web Almanac) in 2024, after being higher under the old metric.
What INP Means in Everyday Use
Field, Not Lab: How Google Really Measures
A widespread misconception is that a single speed test is enough as a verdict. In fact, Google assesses the Core Web Vitals based on real page views from real visitors, collected in the Chrome UX Report (Chrome UX Report). These field data reflect the actual bandwidth and device diversity of users – from fast fibre to the older smartphone in a rural dead spot. A lab value on a fast test machine can deviate considerably from that.
The decisive figure is the 75th percentile (Google Search Central) of page views: only when three out of four visits reach a good value does a page count as fast for that metric. This bar is deliberately strict, because it prevents a good average from masking a poor experience for a quarter of users. For care services this means: it is not enough for the page to load quickly on your own new office computer – it must also convince on the three-year-old phone of the searching daughter.
The Lab Plans, the Field Judges
A page is not fast when it looks good in a test, but when three out of four real visitors experience it as fast.
Where a Care Website Loses Speed
When a page misses the good thresholds, it is rarely down to a single cause. Usually several brakes add up. The analysis of millions of real pages shows where the biggest levers lie: on 73 percent (HTTP Archive Web Almanac) of mobile pages, the load-defining LCP element is an image – making images the most common reason for a slow page build. Added to that are a sluggish server response, heavy fonts and overloaded code.
Large, Uncompressed Images
Photos at full camera resolution are the most common drag. Since an image is the LCP element on most pages, its size decides the perceived load time directly.
Slow Server Response
If the server only reacts after a long wait, everything else is delayed. This server response time is one of the largest single parts of the LCP and depends heavily on the hosting location.
Heavy Web Fonts
Several embedded font weights, often loaded from external servers, delay the text display and can lead to jumping layouts.
Superfluous Scripts
Chat widgets, trackers and effect libraries from third parties block responsiveness and push up the INP value – with questionable benefit for a care service.
It is striking how many brakes are self-inflicted. For instance, 16 percent (HTTP Archive Web Almanac) of mobile pages lazy-load of all things their most important image – a well-meant but here harmful trick that artificially worsens the LCP. The share of pages with a good LCP is accordingly only 59 percent (HTTP Archive Web Almanac) on mobile, while visual stability at 79 percent (HTTP Archive Web Almanac) and responsiveness at 74 percent (HTTP Archive Web Almanac) are in the green far more often. Load time is thus the hardest of the three disciplines – and at the same time the one with the greatest room for improvement.
Optimising Images, Hosting and Fonts Deliberately
The good news: almost all brakes can be solved with proven means, without expensive special technology. The biggest lever is the images. Anyone who delivers them in a modern, strongly compressed format, scales them to exactly the size needed and tells the browser the dimensions in advance lowers both the load time and the layout shift. The load-defining image in the visible area should be loaded with priority and not delivered late.
- Compress images and deliver them in a modern encoding, at exactly the displayed size instead of full camera resolution
- Set the height and width of images so the content does not jump while loading and the CLS stays low
- Load the most important image in the visible area with priority instead of delivering it late
- Self-host fonts, limit them to a few weights and give them a display behaviour that shows the text immediately
- Avoid superfluous third-party scripts and implement necessary functions leanly and, where possible, in-house
- Host on a fast server with a short response time and a location in Germany
With hosting, it pays to look at two things at once: speed and data protection. A server with a short response time and a location in Germany shortens the decisive server response time and at the same time keeps the sensitive health data touched on a care website within the European legal framework. The two belong together: a nearby, fast server is rarely at odds with a privacy-friendly one. How to implement complete content for relatives without losing speed is shown in the article on the well-considered structure of a care-service website; why real photos build trust despite their weight and how to keep them lean is covered in the article on real photos on the care website.
Caution With External Helpers
Good, Needs Improvement, Poor: the Values Compared
To make the abstract numbers tangible, a classification in three tiers helps. Google rates each of the three values not just as pass or fail, but in the categories good, needs improvement and poor (web.dev). The following overview shows the official boundaries – a useful benchmark for placing your own measurement report.
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| Largest Contentful Paint (LCP) | up to 2.5 seconds | 2.5 to 4 seconds | over 4 seconds |
| Interaction to Next Paint (INP) | up to 200 ms | 200 to 500 ms | over 500 ms |
| Cumulative Layout Shift (CLS) | up to 0.1 | 0.1 to 0.25 | over 0.25 |
A single value in the yellow zone is no cause for concern, but it is a hint. If, on the other hand, several values are persistently in the red, the page measurably loses visitors and visibility at once. Whether a targeted optimisation pays off or a fundamental rebuild is the more economical choice depends on how deep the weaknesses sit – a consideration the article on the care website relaunch 2026 treats in detail. As a rule of thumb: selective weaknesses can be fixed, structurally slow technology cannot.
Staying Fast Is an Ongoing Task
Speed is not a state you establish once and then forget. Over time, images, posts and functions are added, and a care website that was fast at first can quietly become sluggish again. Because Google measures in the field over weeks, a regression also shows up with a delay – and is then all the more laborious to fix. A regular check of the Core Web Vitals therefore belongs to ongoing website maintenance and should not be left to chance.
From more than 50 website projects (project experience), we know that the greatest gain lies not in one-off special technology but in solid foundations that are maintained over time: lean code, disciplined handling of images and avoiding everything superfluous. Which building blocks belong to this is summarised in our overview of services. Whether your existing site reaches the good thresholds can be checked objectively – a good starting point for any further decision.
Start With a Measurement
Sources and Studies