Core Web Vitals Mastery: The Journey of Optimizing Web Performance

“The beauty of a UI only exists as long as the user is willing to wait. 5 seconds is more than enough for that patience to evaporate.”

Hi everyone, I’m Toàn Anh, a Senior Frontend Developer at Supremetech. I once faced a web application where the mobile homepage load time exceeded 5 seconds—a disastrous figure that directly threatened the user experience.
Drawing from my real-world experience, I’m going to share how I slashed that number to under 2 seconds. I will also explain why Web Performance is the do-or-die factor that every Frontend Developer must master. I truly believe that the quality of a website is measured solely by the experience of its users.

The Context

A corporate website was facing severe issues with its homepage loading speed, particularly on mobile devices. Our initial audits revealed:

• 5 seconds for any content to actually appear.
• Nearly 8 seconds before a user could actually interact with the page.

If you were the user, would you return to this site? If you were the business owner, how would you feel?

Analysis: Identifying the Bottlenecks

Before touching a single line of code, I always start by gathering performance data using industry-standard tools like Lighthouse and PageSpeed Insights. There are three core metrics I prioritize:

1. Largest Contentful Paint (LCP)

LCP measures the time it takes for the largest content element (like a hero image, video, or a large text block) to become visible on the screen. Most often, this is an element located “Above the Fold”—the part of the page visible without scrolling.

• Benchmarks: Good: < 2.5s | Needs Improvement: 2.5s – 4s | Poor: > 4s.

2. Time to Interactive (TTI)

TTI measures the time until the website is fully interactive. The primary culprits here are usually massive resource sizes (Images, CSS, or JavaScript) that block the main thread and delay the page’s ability to respond to user input.

• Benchmarks: Good: < 3.8s | Needs Improvement: 3.8s – 7.3s | Poor: > 7.3s.

3. Cumulative Layout Shift (CLS)

CLS measures visual stability. It quantifies how much the page layout “jumps” unexpectedly during loading. This is usually caused by images or ads loading late and pushing existing content down the page.

• Benchmarks: Good: < 0.1 (10%) | Needs Improvement: 0.1 – 0.25 | Poor: > 0.25.

Implementing technical solutions

JavaScript Optimization: From Monolithic to Modular

• Code Splitting & Lazy-loading: We broke the JavaScript bundle into smaller “chunks” per page, loading them only when necessary instead of forcing the browser to download a monolithic file at once.
• Dynamic Imports: We utilized React.lazy and Suspense (or equivalents in Angular/Vue) to ensure module code is only fetched when the user actually needs it.

Image Optimization: Shrinking the Footprint

Images are the “enemy number one” of performance if not managed correctly.

• Lazy-loading Images: We deferred loading images that were “Below the Fold” using the loading=”lazy” attribute or the Intersection Observer API.
• Modern Formats & Sizing: We converted images to .webp for better compression. We also implemented srcset and sizes attributes so the browser can choose the optimal image version based on the device’s viewport.
• Preventing Layout Shift: We explicitly defined width and height for all images and videos to “reserve” space, ensuring content doesn’t jump when the media finally loads.

Rendering Optimization: Prioritizing the First View

Resources that block rendering, especially those not needed for the initial view, must be handled.

• Inlining Critical CSS: We extracted the CSS required for the “Above the Fold” content and embedded it directly into the HTML.
• Resource Hinting: We used <link rel=”preload”> to tell the browser to prioritize fetching the essential resources needed for a fast LCP.

The results

After applying these optimizations across approximately 60 pages of the corporate website:

• Score Jump: From ~50/60 pages scoring below 50 on Performance, all pages now score above 90.
• Health Status: LCP, TTI, and CLS metrics shifted from Red (Poor) to Green (Good).

Key takeaways

1. Performance is a process, not a task: It’s not a “one-and-done” job; it requires regular measurement and iteration throughout the website’s lifecycle.
2. User-Centric Coding: Every technical decision should be driven by the user experience. Ask yourself: “Does this code improve the user’s journey? Will this make the customer happy?”
3. Efficiency over Execution: Remember, our job isn’t just to make the code run—it’s to make it run efficiently.

Happy coding, and may your websites load faster than ever!