There is a pervasive culture in the web development industry of accepting "orange" scores on Google's Core Web Vitals (Lighthouse) reports. Agencies will commonly deliver a final product to a client boasting a desktop performance score of 85 and a mobile score hovering around 60, claiming that getting to 100/100 is physically impossible without stripping out all the imagery and Javascript. The root cause is almost always poor infrastructure decisions—explored in detail in our guide to fast website architecture.
This is a common but mistaken view. Achieving top scores is difficult, but it is entirely possible with the right architectural discipline from day one. At torsn, we treat a 99/100 score as the baseline expectation, not a bonus.
The Four Pillars of the Lighthouse Algorithm
Google's Core Web Vitals are the three field metrics that directly influence real-world search rankings: LCP (Largest Contentful Paint), INP (Interaction to Next Paint), and CLS (Cumulative Layout Shift). In the lab, Lighthouse supplements these with FCP (First Contentful Paint) and TBT (Total Blocking Time) as proxies. To achieve a perfect score, you must engineer solutions for every layer.
Here is exactly how each metric is addressed in practice.
These metrics measure how fast the initial server responds and how quickly the biggest "above the fold" element (usually a hero image or massive headline) renders on the screen. The threshold for a "Perfect" LCP score is under 1.2 seconds on a simulated 3G mobile network.
- Zero-Javascript Initial Render: We utilized Nuxt 3's advanced Server-Side Rendering. Our Node servers compile the Vue application into raw HTML before the response is even sent. The browser instantaneously receives a fully painted HTML skeleton in under 40 milliseconds.
- Preconnecting Assets: The moment the HTML hits the browser, we use `` tags in the document head to establish early handshake connections with our global font networks and CDNs.
- LCP Preloading: We explicitly target the hero image or video on every single page and inject a `` tag. This forces the browser compiler to bypass normal sequential fetching and prioritize downloading the hero asset immediately.
TBT measures how long the website is "frozen" while Javascript executes. On a heavy React or Shopify site, you might click a button and nothing happens for 3 seconds while the main browser thread is blocked by a massive JS bundle.
We address TBT through Code Splitting. By analyzing our build graph, we fragment our Javascript into page-specific chunks. A user visiting the Homepage downloads only the Javascript required for that specific page. We defer all analytics scripts (Google Tag Manager, Meta Pixel) using Web Workers (via tools like Partytown) so they execute on a background thread, freeing up the main thread for the user.
INP replaced First Input Delay (FID) as an official Core Web Vital in March 2024. While FID only measured the delay before the browser began processing the first click, INP measures the full duration of every interaction on the page—from the moment you click or tap, to the moment the display visually updates in response. Google's threshold for a 'Good' INP score is under 200ms.
This is a far stricter standard than FID. A page that passed FID easily can still fail INP if interactions trigger heavy JavaScript work on the main thread. Common INP killers include: rendering large component trees on user input, synchronous data fetching inside click handlers, and unoptimized third-party scripts that monopolize the main thread during user interaction.
Our approach to INP optimization operates on three levels:
- Yielding to the browser: After any significant JavaScript task, we explicitly yield control back to the browser with a short async gap (using
scheduler.yield()or asetTimeout(0)pattern). This gives the browser a chance to paint the visual update before continuing the remaining work, slashing perceived INP. - Offloading work to Web Workers: Any computation that does not need direct DOM access—filtering, sorting, data transformation, search indexing—is moved off the main thread entirely into a worker. The main thread stays free to respond to user input instantly.
- Debouncing and virtualizing: Input handlers that trigger re-renders (search fields, range sliders, filter controls) are debounced aggressively. Long lists are virtualized so only the visible DOM nodes are rendered, preventing large layout recalculations on every interaction.
INP is the metric most agencies overlook because it is invisible in basic Lighthouse runs—Lighthouse is a static page load test and does not simulate real user interactions. You must use Chrome's User Timing API, Web Vitals JS library, or real-user monitoring (RUM) tools like Vercel Analytics or web-vitals.js to measure INP accurately on live traffic.
Layout shift is the phenomenon where you go to click a link, but an image suddenly loads above it, physically shoving the text down, causing you to misclick. Google heavily penalizes this because it causes massive user frustration.
Achieving a 0.00 CLS score requires careful, consistent practice:
- Explicit Aspect Ratios: Every single `
` or `
- System Font Fallbacks: Custom web fonts (like Space Grotesk) take milliseconds to download. While they load, the browser displays a fallback font (like Arial or Times New Roman). Because fonts have different physical widths, the text "reflows" when the custom font finally loads. We counter this by utilizing `font-display: swap` and explicitly engineering css `size-adjust` overrides so our fallback fonts perfectly mimic the exact geometric width of our premium fonts. The jump is mathematically eliminated.
Performance is Not an Add-on
Achieving 100/100 cannot be outsourced to a "PageSpeed Plugin" installed a week before launch. You cannot spray WD-40 on a crumbling architecture and expect it to win a Formula 1 race.
Strong Core Web Vitals scores cannot be added retroactively with a plugin. They must be engineered into the foundation from the start — requiring a developer to carefully evaluate every dependency, every asset, and every third-party integration for its real-world performance cost. When you work with torsn, performance is a first-class requirement from day one of the build, not an afterthought addressed before handover.
