Core Web Vitals 2026 Checklist: LCP, INP, CLS Optimization Guide

Google's 2026 Core Web Vitals update has completely replaced FID with the INP (Interaction to Next Paint) metric and tightened threshold values. Having your site's LCP below 2.5 seconds, INP below 200ms, and CLS below 0.1 is no longer just "nice to have" but mandatory for rankings. At FUTIA, I've solved Core Web Vitals issues for over 40 Turkish sites in the past two years, and here's what I've observed: most sites are optimizing in the wrong places. Everyone installs caching plugins but nobody cleans up their render-blocking CSS. In this article, I'll share the updated checklist for 2026 and lessons learned from real cases.

To optimize Core Web Vitals, you must first understand which metric is actually problematic on your site. The "Experience" tab in Google Search Console gives a general idea, but PageSpeed Insights and Lighthouse reports in Chrome DevTools are more detailed. For every project, I first test 10 different pages (homepage, category, product, blog post) on both mobile and desktop. Because on an e-commerce site, the homepage might show 2.1 seconds LCP while the product page shows 4.8 seconds. Looking at averages is misleading.

Bringing LCP (Largest Contentful Paint) Below 2.5 Seconds

LCP is the time it takes for the largest visual element of the page to render on screen. In 2026, Google is weighing this metric more heavily within mobile-first indexing. If your site's LCP is above 2.5 seconds, first find what's slowing it down.

Open Chrome DevTools (F12), go to the Performance tab, and reload the page. Find the element marked as "LCP" in the timeline. On most sites, this is the hero image, on some it's a video or large text block. On the diolivo.com.tr project, we reduced LCP from 4.2 seconds to 1.8 seconds. The problem was a 1.2 MB hero image being served as JPEG without lazy loading.

First step: convert the image to WebP format. 25-35% smaller file size compared to JPEG. If you're using WordPress, Imagify or ShortPixel plugins do automatic conversion. For custom-coded sites, Cloudflare's Polish feature or CDNs like Cloudinary handle it. On diolivo, converting the image to WebP reduced it from 1.2 MB → 380 KB.

Second step: preload the hero image. Add this line to the HTML head:

<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">

This instructs the browser to "load this image with first priority." But be careful: only preload the LCP element. If you preload every image, the browser gets confused and none get priority.

Third step: reduce server response time (TTFB). 40-50% of LCP is the time it takes the server to generate HTML. If you're using shared hosting, switch to VPS. For WordPress, installing Redis object cache can reduce TTFB from 800ms to 200ms. On memuratamalari.com, switching from SiteGround to Hetzner VPS brought TTFB from 620ms → 180ms.

Fourth step: eliminate render-blocking resources. If PageSpeed Insights gives an "Eliminate render-blocking resources" warning, your CSS and JS files are blocking HTML rendering. Put critical CSS inline in the head, load the rest with defer or async. On WordPress, Autoptimize or WP Rocket automate this but sometimes do overly aggressive combining and break the site. I always test on staging.

Overlooked Detail for LCP: Font Loading

Most sites load Google Fonts in a render-blocking way. Font files can delay LCP by 400-600ms. Solution: use font-display: swap and preload font files.

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="preload" as="style" href="https://fonts.googleapis.com/css2?family=Inter:wght@400;600&display=swap">

On italyanmutfagi.com, changing the font loading strategy reduced LCP by 300ms. Seems small but every 100ms matters on mobile.

Optimizing INP (Interaction to Next Paint) Below 200ms

INP measures how quickly the page responds when a user clicks, scrolls, or presses a key. While FID only measured the first interaction, INP tracks all interactions. In 2026, this metric is especially critical for SPAs (Single Page Applications) and sites using heavy JS.

INP issues generally stem from three causes: long JavaScript tasks, main thread blocking, and slow-running event handlers. In Chrome DevTools Performance tab, open the "Long Tasks" filter. Tasks longer than 50ms are marked yellow or red. On the doktorbul.com project, a site with 79,000 doctor profiles, INP was initially 420ms. The problem was adding the entire doctor list to the DOM on every page load.

Solution: code splitting and lazy loading. If you're using React, split components into chunks with React.lazy() and Suspense. In vanilla JS, load when entering viewport with Intersection Observer API. On doktorbul, we paginated search results and only rendered the visible 20 profiles. INP dropped from 420ms → 180ms.

Second common issue: third-party scripts. Tools like Google Analytics, Facebook Pixel, Hotjar block the main thread. Load these scripts with async or defer and manage them through Google Tag Manager if possible. GTM loads scripts asynchronously and consolidates them in a single container.

Third issue: heavy event listeners. Especially scroll events trigger every 16ms (for 60 FPS). If you do complex calculations on every scroll, INP explodes. Solution: use debounce or throttle. Lodash's debounce function or your own implementation:

function debounce(func, wait) {
  let timeout;
  return function executedFunction(...args) {
    clearTimeout(timeout);
    timeout = setTimeout(() => func(...args), wait);
  };
}

window.addEventListener('scroll', debounce(() => {
  // scroll operations
}, 150));

This triggers the scroll event once every 150ms, not every 16ms. Can reduce INP by 100-200ms.

Advanced Technique for INP: Using Web Workers

Heavy computations should be done in Web Workers, not on the main thread. For example, large JSON parsing or data filtering. On kamupersonelhaber.com, we used a Web Worker to filter 50+ daily job listings. Since the main thread wasn't blocked, INP dropped by 80ms.

Reducing CLS (Cumulative Layout Shift) Below 0.1

CLS measures unexpected page shifts during loading. The user is about to click a button when the page shifts and they click the wrong place. In 2026, Google is strictly evaluating CLS especially for mobile experience.

The most common cause of CLS: images and iframes without defined dimensions. If the browser doesn't know the image size, the page shifts down when the image loads. Simple solution: add width and height to every img and iframe tag.

<img src="/foto.jpg" width="800" height="600" alt="Description">

In modern CSS, you can use aspect-ratio:

img {
  width: 100%;
  height: auto;
  aspect-ratio: 16 / 9;
}

On diolivo.com.tr, adding aspect-ratio to product card images reduced CLS from 0.18 → 0.04. One line of CSS.

Second common cause: dynamic content injection. Ad banners, notification popups, or cookie consents push content down after page load. Solution: reserve space for these elements in advance. For example, for a 60px notification that will appear at the top:

body {
  padding-top: 60px;
}

Or define min-height before adding dynamic content with JavaScript.

Third cause: web font loading. When fonts load, text size changes and the page shifts. Solution: use font-display: optional. This shows the fallback font if the font doesn't load and prevents shifting. Or preload font files so the page renders with the correct font on first render.

Critical Detail for CLS: Infinite Scroll and Lazy Load

Infinite scroll increases CLS because the page shifts when new content is added. On italyanmutfagi.com with 618 recipe pages, we defined fixed height for each new batch during lazy load. We used skeleton loaders, showing placeholders until content loaded. CLS dropped from 0.22 → 0.07.

Server-Side Rendering and Core Web Vitals Relationship

SSR (Server-Side Rendering) or SSG (Static Site Generation) makes a huge difference for Core Web Vitals. With client-side rendering (e.g., React SPA), the browser first receives empty HTML, then downloads JS, executes it, and renders content. During this process, LCP can be 3-5 seconds.

With SSR, the server sends pre-rendered HTML. The browser immediately shows content, JS hydrates in the background. Frameworks like Next.js, Nuxt.js, or SvelteKit make SSR easy. By doing SSG with Next.js on futia.net, we produced 2,000+ video content in 3 months and kept LCP at 1.4 seconds.

But SSR isn't always the solution. If you do heavy processing server-side, TTFB increases and LCP is still bad. For example, if you're querying the database on every request, caching is essential. Server-side cache with Redis or Memcached reduces TTFB by 80-90%.

On memuratamalari.com, we used SSR + Redis cache combination. It has 40,400 monthly organic search traffic and all three Core Web Vitals are green. The secret sauce: we auto-generate job listing content with Claude Haiku API but each listing is cached as static HTML. Looks like dynamic content but is actually static.

Improving Core Web Vitals with CDN and Edge Computing

CDN (Content Delivery Network) doesn't just speed up static files, it's critical for Core Web Vitals. CDNs like Cloudflare, Fastly, or AWS CloudFront serve content from the server closest to the user. TTFB drops, LCP improves.

But the real power of CDN is in edge computing. With Cloudflare Workers or Vercel Edge Functions, you can render HTML at the edge. If the user is in Istanbul, the server runs on the Istanbul edge node, not in the Netherlands. TTFB can drop from 400ms → 80ms.

On doktorbul.com, we cached doctor search results at the edge with Cloudflare Workers. For each search query, HTML is generated at the edge in 200ms. The origin server is only triggered when a new doctor is added. Result: LCP from 2.8 seconds to 1.6 seconds, INP from 340ms to 190ms.

Another use of edge computing: A/B testing and personalization. To show user-specific content, you make decisions at the edge instead of going to the origin server. CLS risk decreases because content comes correct on first render.

Monitoring and Continuous Improvement for Core Web Vitals

You can't optimize Core Web Vitals once and leave it. As the site updates and new features are added, metrics change. Continuous monitoring is essential.

The "Experience" report in Google Search Console shows 28 days of real user data (CrUX) but is delayed. PageSpeed Insights does instant testing but with synthetic data. Use both together. I check Core Web Vitals reports for all projects every week.

For more detailed monitoring:

1. Google Analytics 4: Send Web Vitals events as custom events. Create a "page_speed" event in GA4, send LCP, INP, CLS values as parameters. You'll see which pages have issues.

2. Sentry or LogRocket: Records real user sessions. When a user experiences CLS, you see what shifted in session replay.

3. Lighthouse CI: Automatic Lighthouse testing on every deploy. Integrate with GitHub Actions or GitLab CI. If a new feature breaks Core Web Vitals, you'll notice before deploy.

On kamupersonelhaber.com, we set up Lighthouse CI. Automatic test on every commit, deploy fails if LCP exceeds 2.5 seconds. This way, no update broke performance.

Core Web Vitals Checklist for 2026: Step by Step

I've turned everything explained so far into a checklist. I follow this list when starting every project.

LCP Checklist

• [ ] Is the hero image in WebP or AVIF format?
• [ ] Is the LCP element being preloaded?
• [ ] Is TTFB below 200ms?
• [ ] Are render-blocking CSS and JS eliminated?
• [ ] Are font files preloaded and using font-display: swap?
• [ ] Are images lazy loaded except the LCP element?
• [ ] Is CDN being used?

INP Checklist

• [ ] Are there JavaScript tasks longer than 50ms?
• [ ] Are third-party scripts loading with async or defer?
• [ ] Is debounce/throttle used in event listeners?
• [ ] Is code splitting implemented?
• [ ] Are heavy computations in Web Workers?
• [ ] Is there virtual scrolling in React/Vue frameworks?

CLS Checklist

• [ ] Do all img and iframe tags have width/height defined?
• [ ] Is space reserved in advance for dynamic content?
• [ ] Is the font loading strategy correct?
• [ ] Is there reserved space for ads and popups?
• [ ] Are skeleton loaders used in infinite scroll?
• [ ] Are CSS animations done with transform and opacity?

General Checklist

• [ ] Is SSR or SSG being used?
• [ ] Is there Redis or Memcached cache?
• [ ] Has edge computing been evaluated?
• [ ] Is Lighthouse CI installed?
• [ ] Is Core Web Vitals tracking done in Google Search Console?

Review this checklist every 3 months. When Google updates Core Web Vitals threshold values and measurement methods (usually twice a year), revise the list.

Real World Example: diolivo.com.tr Optimization

When optimizing diolivo.com.tr, all three Core Web Vitals were red. LCP 4.2 seconds, INP 380ms, CLS 0.28. After 6 weeks of work, LCP 1.8 seconds, INP 170ms, CLS 0.04. Traffic increased 340% in 6 months.

What we did:

1. For LCP: 1.2 MB hero image → 380 KB WebP. Cloudflare CDN + Polish. Font preload. Split render-blocking CSS into critical/non-critical.

2. For INP: Moved product filtering JavaScript to Web Worker. Switched third-party scripts (Facebook Pixel, Google Analytics) to async loading through GTM. Added 200ms debounce to scroll events.

3. For CLS: All product images got aspect-ratio: 1 / 1. 50px padding-top on body for cookie consent. Skeleton loader in lazy load.

4. Bonus: Set up CartBounty cart recovery system. Automatic email + SMS for abandoned carts. Not a Core Web Vitals optimization technically but increased conversion by 18%.

Result: "Good" URL ratio in Google Search Console went from 23% to 87%. Organic traffic went from 4,200 → 18,500 monthly visitors in 6 months. Core Web Vitals has a direct impact on rankings.

If your site has Core Web Vitals issues, first test on PageSpeed Insights. Focus on whichever metric is bad. Don't try to fix everything at once, first turn the worst one green. Then move to the next. If you need technical support, as FUTIA we provide site analysis + automation + monthly maintenance services. You can reach us via WhatsApp at +90 532 491 17 05 or send a detailed explanation to info@futia.net. I work from the Netherlands but we have special services for Turkish brands.