Web performance: feeling fast and working fast
Consider loading, interaction response and layout stability together with a concrete user task.

In this article
A screen looking fast is different from a user completing a task quickly. The first image may appear promptly while the response to a tap is delayed. Review performance through a user task rather than one isolated score.
Ask three different questions
Core Web Vitals evaluates the appearance of the main content with LCP, interaction response with INP and unexpected shifts with CLS. Google's good thresholds are 2.5 seconds for LCP, 200 milliseconds for INP and 0.1 for CLS. Assessment uses the 75th percentile of real visits, considering mobile and desktop separately.
Repeat a concrete task
Find an article or product on a phone, select a filter and complete a form. Record where you wait and what appears during the wait. Use that observation together with measurements; a single fast test does not represent everyone's experience.
Avoid unnecessary work before the first content
Starting a heavy component early may not support the immediate task. Identify the image in the first screen, reserve its area and load lower content at an appropriate time. Keep a change small and measure again.
Show state as well as speed
If saving is not immediate, explain what is happening. An empty screen can encourage duplicate submissions. When the operation finishes, show the saved result clearly.
The official Web Vitals article — web.dev describes the metrics and thresholds. The task review here is a practical way to connect those measurements to your interface.