What to know
Useful performance evidence combines real-user measurements, where available, with repeatable lab tests and practical interaction checks. Record the tested URL, device assumptions and date. Explain loading, responsiveness and layout stability rather than presenting a single score as proof of overall quality.
Fast is not a single number. A page might display its headline quickly but ignore the first tap. Another may feel responsive until a late-loading image pushes the button the user was about to press. Both experiences contain real performance problems, even if a screenshot looks perfect.
For technical award evaluation, performance evidence should help explain how the website behaves under real conditions. It should not become a competition to optimise one synthetic score at the expense of the product.
Three useful measures, three different questions
Google's Core Web Vitals documentation identifies three primary measures of real-world experience.
| Metric | What it describes | Recommended good threshold |
|---|---|---|
| Largest Contentful Paint (LCP) | When the main content becomes visible | 2.5 seconds or less |
| Interaction to Next Paint (INP) | Responsiveness to user interactions | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | Unexpected visual movement | 0.1 or less |
These are useful thresholds for field data at the 75th percentile, not a universal verdict on artistic quality. A great experience may require explanation beyond the metrics, and a page can pass them while still having serious accessibility or reliability problems.
What LCP does not tell you
A fast headline is good. It doesn't necessarily mean the whole page is useful. An enormous hero video can delay the main content, while an otherwise quick render might hide essential navigation until client-side code loads.
When reviewing a site, inspect which element becomes the LCP candidate and whether that element genuinely matters to the user. Image compression, sensible preload choices and avoiding unnecessary render-blocking work can help.
INP: the cost of a difficult interaction
Interaction to Next Paint reflects how promptly a page responds to interactions. Heavy JavaScript, long main-thread tasks and overloaded event handlers can produce a sluggish experience after the page appears ready.
Test menus, product filters, search controls and forms. If the user clicks and nothing appears to happen, the interface has failed at communication even if the underlying operation eventually completes.
CLS: when layout movement becomes a usability problem
Unexpected shifts can make someone tap the wrong action or lose their reading position. Common causes include images without reserved dimensions, content inserted above the viewport and late-loading elements.
A little movement isn't automatically a defect. The concern is movement that surprises the visitor and interrupts the task.
Lab tests and field data have different jobs
A local test helps isolate a problem and compare changes. Field data shows how real visitors experience the website across devices and connections. Neither should be confused with a complete assessment of usability.
If field data is unavailable for a newly launched project, describe the limitation honestly. A repeatable lab test can still support a technical case, but it should not be presented as measured experience from real users.
How an awards jury should read the evidence
The Web Dev Awards assessment includes loading, responsiveness, stability and disciplined use of effects. The strongest submissions make it possible to inspect the live experience rather than rely on a prepared performance graphic.
The performance of a simple brochure site and a complex 3D experience needs context. The goal is not to excuse avoidable delays, but to understand the design brief and whether the chosen implementation serves its users.
A short evidence checklist
Before submitting, check the primary pages on mobile and desktop, review field metrics when available, test important interactions, and record any accessibility or functionality issues that the metrics will not reveal. Inspect the site with a slower connection if its audience is likely to need it.
You can pair this evidence with accessible interaction testing and the broader Web Dev Awards judging framework.
A performance score is a starting question. Good engineering is the reasoned answer.