Skip to content

Engineering

On corporate sites, performance is a design decision

Passing Core Web Vitals is not an optimisation pass at the end. It is the consequence of architecture and design decisions taken on day one.

Published: Last updated: 6 min readNeuros Web Team · Web Engineering

In short

How fast should a site be, and how do you measure it?

Core Web Vitals are measured against three thresholds: Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds and Cumulative Layout Shift under 0.1. A corporate site passes them only when performance is written as a budget and enforced by the deployment pipeline; without a budget every new component makes the page a little heavier.

Speed is not a feature you add later. Without a resource budget from the start, every decision made in the design phase quietly becomes performance debt.

How is a performance budget set?

Set a ceiling per page for total JavaScript, image weight and third-party scripts. Enforce that ceiling in CI so a change that breaches it cannot merge.

  • Make server components the default and client components the exception.
  • Self-host fonts and serve them in variable format.
  • Require modern formats and correct dimensions for images.
  • Defer analytics and marketing scripts.

How much does animation cost in performance?

Scroll-driven animation is cheap only while it stays on transform and opacity. Anything that triggers layout comes back as dropped frames on a mid-range phone.

How are Core Web Vitals measured correctly?

Lab testing is not enough. Without real user monitoring you cannot know whether performance actually improved.

Core Web Vitals thresholds (Google, web.dev)
MetricGoodNeeds improvementPoor
LCP — Largest Contentful Paint≤ 2.5 s2.5 – 4.0 s> 4.0 s
INP — Interaction to Next Paint≤ 200 ms200 – 500 ms> 500 ms
CLS — Cumulative Layout Shift≤ 0.10.1 – 0.25> 0.25

Sources

  1. 01Core Web Vitals — LCP, INP, CLS eşikleriGoogle · web.dev · 2024
  2. 02Web Content Accessibility Guidelines (WCAG) 2.2W3C · 2023
  3. 03DORA — DevOps Research and Assessment metrikleriGoogle Cloud · 2024

Frequently asked

Questions we get asked

Get in touch

Their effect on ranking is not decisive on its own; content quality still weighs more. But a page that fails the thresholds also loses the user: on a slow page a visitor leaves before seeing the content. Treating performance as a condition for the content being read, rather than as a ranking tactic, is the more accurate frame.

JavaScript that occupies the main thread for long stretches. When a user presses a button, the browser must finish the task in front of it before it can respond, and if that task is long the interaction is delayed. The usual causes are large bundles, heavy computation at page load and listeners firing on every scroll. The fix is splitting code and deferring work until after the interaction.

It is not. A lab test assumes a fixed device and a fixed connection, while a real user may be on an older phone and a fluctuating network. The two do not substitute for each other: lab testing catches regressions, real user monitoring shows which group of users is suffering. Decisions should read both together.

Related reading

Let's discuss this with your team

We can run a technical session to translate any of this into your own context.

Book a callinfo@neuros.com.tr