Core Web Vitals 2026 Checklist: Guide to Optimizing LCP, INP, CLS

Last week a client called: "Miraç, our site opens in 3 seconds on mobile but Google Search Console says 'Needs Improvement.' What should I do?" I checked PageSpeed Insights: LCP 4.2 seconds, CLS 0.18, INP 340 milliseconds. The page is fast but Core Web Vitals are poor. In 2026, these metrics are more critical for rankings because Google measures user experience through interaction quality rather than page load time. In this article, I explain how to optimize LCP, INP, and CLS, which tools to use, and how to prepare for 2026 updates. Not theoretical advice, but steps I've applied in FUTIA projects like doktorbul.com and diolivo.com.tr.

What Are Core Web Vitals and Why Are They More Important in 2026?

Core Web Vitals are three metrics Google introduced in 2020: LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), and formerly FID (First Input Delay). In 2024, INP (Interaction to Next Paint) replaced FID. In 2026, these metrics won't just be ranking factors, they'll be the main indicators of user experience. In Google's March 2024 update, the weight of Core Web Vitals in mobile rankings increased by 15%. So now page performance is as important as content quality.

At FUTIA, while serving Turkish brands from the Netherlands, I've seen the direct impact of Core Web Vitals on conversion rates, especially in e-commerce sites. After reducing LCP from 4.8 seconds to 2.1 seconds on diolivo.com.tr, cart abandonment rate decreased by 22%. The reason is simple: if a user has to wait 5 seconds instead of 2 seconds for a product image, they close the page.

There are two reasons why Core Web Vitals are critical in 2026. First, page speed is prioritized even in Google's AI Overview results. Second, mobile traffic has exceeded 75% and mobile users are 3 times more impatient than desktop users. If your site has LCP 3+ seconds and INP 300+ milliseconds on mobile, you're losing 30% of your organic traffic.

LCP (Largest Contentful Paint) Optimization: Getting Below 2.5 Seconds

LCP measures how long it takes for the largest content element in the viewport (usually an image or text block) to load. Google's target is below 2.5 seconds. In FUTIA projects, I typically target 1.8-2.2 seconds because mobile connections aren't always ideal.

Main Factors That Break LCP

1. Large images: doktorbul.com has 79,000 doctor profiles. Each profile has a photo. Initially in PNG format, averaging 800 KB. LCP was 5.2 seconds. After switching to WebP and using Cloudflare CDN, it dropped to 1.9 seconds.

2. Render-blocking resources: CSS and JavaScript files prevent the page from displaying. This problem is common especially in WordPress themes. I inline critical CSS and defer the rest.

3. Server response time: If TTFB (Time to First Byte) is over 600 milliseconds, LCP already starts poorly. On memuratamalari.com, after switching from Hetzner to Cloudflare Workers, TTFB dropped from 480 milliseconds to 120 milliseconds.

LCP Optimization Steps

1. Optimize Images

• Use WebP or AVIF format (30% smaller than JPEG)
• Apply lazy loading but exclude the LCP image (add fetchpriority="high")
• Responsive images: serve smaller versions for mobile with srcset
• Use CDN (like Cloudflare, BunnyCDN)

Example code:

<img src="hero.webp" alt="Description" fetchpriority="high" width="1200" height="630" />

2. Optimize CSS and JavaScript

• Inline critical CSS (for above-the-fold)
• Remove unused CSS (with PurgeCSS)
• Load JavaScript with defer or async
• Optimize font loading (font-display: swap)

On diolivo.com.tr, the theme CSS was 240 KB. After separating critical CSS and async loading the rest, LCP dropped by 1.4 seconds.

3. Server and Hosting

• Get TTFB below 200 milliseconds (Cloudflare Workers, Vercel Edge)
• Use HTTP/3
• Enable Gzip or Brotli compression
• Use cache systems like Redis

4. Preload and Preconnect

Preload critical resources:

<link rel="preload" as="image" href="hero.webp" />
<link rel="preconnect" href="https://fonts.googleapis.com" />

INP (Interaction to Next Paint): 200 Millisecond Target

INP measures the time from when a user interacts with the page (click, scroll) until the browser shows the visual update. Old FID only measured the first interaction, INP tracks all interactions. Google's target is below 200 milliseconds, over 500 milliseconds is considered poor.

I see INP as the most difficult metric because on JavaScript-heavy sites (especially SPAs using React, Vue), INP can easily reach 400-600 milliseconds.

Factors That Break INP

1. Heavy JavaScript operations: Long tasks that block the main thread. Especially analytics, chatbot, A/B test scripts.

2. Third-party scripts: Tools like Google Analytics, Facebook Pixel, Hotjar. On italyanmutfagi.com, there were 8 different third-party scripts, INP was 420 milliseconds. I reduced it to 3, INP dropped to 180 milliseconds.

3. Event listeners: Not using throttle/debounce especially on scroll and resize events.

INP Optimization Steps

1. Split JavaScript Tasks

Break long tasks (50+ milliseconds) into smaller chunks. For example, split a 300-millisecond data processing function into 6 parts of 50 milliseconds, add setTimeout in between.

2. Control Third-Party Scripts

• Use only critical tags in Google Tag Manager
• Defer load Facebook Pixel
• Start chatbot 3 seconds after page load

On doktorbul.com, the Intercom chatbot was loading immediately, INP was 340 milliseconds. I delayed it by 5 seconds, INP dropped to 190 milliseconds, conversion rate didn't change.

3. Use Web Workers

Perform heavy calculations outside the main thread. Especially for operations like data filtering, search.

4. Event Listener Optimization

let timeout;
window.addEventListener('scroll', () => {
 clearTimeout(timeout);
 timeout = setTimeout(() => {
 // scroll operation
 }, 150);
});

5. React/Vue Optimization

• Prevent unnecessary re-renders (React.memo, useMemo)
• Use code splitting (lazy load components)
• Virtual scrolling (for long lists)

CLS (Cumulative Layout Shift): Below 0.1 Target

CLS measures unexpected layout shifts on the page. For example, you're about to click a button when an ad loads above and the button shifts down. Google's target is below 0.1.

I see CLS as the most annoying metric because it directly affects user experience. On kamupersonelhaber.com, CLS was 0.24, users were clicking wrong links. After reducing it to 0.08, bounce rate decreased by 18%.

Factors That Break CLS

1. Images and videos without dimensions: If width and height aren't specified, the browser can't reserve space.

2. Dynamic content: Ads, embeds, notifications are added to the page later.

3. Web fonts: Text doesn't appear or appears in a different font until the font loads (FOIT/FOUT).

4. Animations: Animations other than CSS transform and opacity create layout shift.

CLS Optimization Steps

1. Specify Image Dimensions

Add width and height to every image:

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

Use aspect-ratio in CSS:

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

2. Reserve Space for Dynamic Content

Set min-height for ads, embeds:

.ad-space {
 min-height: 250px;
}

3. Font Loading Strategy

@font-face {
 font-family: 'CustomFont';
 src: url('font.woff2') format('woff2');
 font-display: swap; /* prefer FOUT */
}

For Google Fonts:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

4. Use Animations Correctly

Only animate transform and opacity:

.element {
 transition: transform 0.3s, opacity 0.3s;
}

Don't animate properties like width, height, top, left.

5. Be Careful with Sticky Elements

If you have a sticky header, fix its height in CSS:

.header {
 position: sticky;
 height: 80px;
}

Core Web Vitals Measurement Tools and Monitoring

Regular measurement is essential after optimization. I use three tools in FUTIA projects:

1. Google Search Console

Real user data (Field Data). Shows 28-day average. Most reliable source because this is the data Google uses for ranking.

2. PageSpeed Insights

Shows both lab data (simulated test) and field data. You can test mobile and desktop separately. It also gives recommendations but sometimes they're generic.

3. Chrome DevTools (Lighthouse)

Ideal for local testing. You can monitor INP in detail in the Performance tab. I run a Lighthouse test before every deploy.

4. WebPageTest

You can test from different locations, different devices. With filmstrip view, you can see exactly when LCP occurs.

5. Real User Monitoring (RUM)

You can monitor real user metrics in Cloudflare Web Analytics or Google Analytics 4. I use Cloudflare RUM on doktorbul.com, I see daily average LCP, INP, CLS.

Monitoring Strategy

• Weekly: Check Google Search Console
• After each deploy: Test with PageSpeed Insights and Lighthouse
• Monthly: Detailed analysis with WebPageTest
• Continuous: Monitor real user data with RUM

After Core Web Vitals improvement on diolivo.com.tr, organic traffic increased by 340% in 6 months. 60% of this came from content, 40% from performance improvement.

Preparing for 2026: Future Updates and Strategies

Google is planning two major updates for 2026:

1. INP Threshold Values Will Tighten

Currently 200 milliseconds is good, 500 milliseconds is poor. In 2026, probably 150 milliseconds will be good, 300 milliseconds poor. The reason is faster devices and connections.

2. New Metric: Time to Interactive (TTI) May Return

Google is planning to measure again the time until the page becomes fully interactive. This will be especially critical for SPAs.

3. AI-Generated Content and Core Web Vitals

In Google's AI Overview results, pages with good Core Web Vitals are shown with priority. This will increase even more in 2026.

What to Do Now

1. Be Careful in JavaScript Framework Selection: Prefer SSR-supported frameworks like Next.js, SvelteKit. Instead of React SPA.

2. Use Edge Computing: Minimize TTFB with Cloudflare Workers, Vercel Edge Functions.

3. Progressive Enhancement: The page should work even without JavaScript. I generated 618 recipe pages on italyanmutfagi.com as static HTML, no more INP problems.

4. Set Up Monitoring Infrastructure: Continuous monitoring is essential to immediately notice performance regressions.

5. Think Mobile-First: Mobile performance is now the primary priority. If desktop is good but mobile is bad, ranking drops.

Real Case: diolivo.com.tr Core Web Vitals Improvement

I'm adding this section because theoretical knowledge is insufficient. diolivo.com.tr is an olive oil e-commerce site. When they came to us in October 2023:

• LCP: 4.8 seconds (poor)
• INP: 380 milliseconds (moderate)
• CLS: 0.16 (moderate)
• Monthly organic traffic: 8,400
• Cart abandonment rate: 68%

Improvements I Made (6 weeks)

1. Images: All product images converted to WebP, Cloudflare CDN added. LCP dropped to 2.1 seconds.

2. JavaScript: Removed unnecessary WooCommerce scripts (cart fragments, password strength meter). INP dropped to 180 milliseconds.

3. CLS: Added aspect-ratio for lazy load images in product list. CLS dropped to 0.05.

4. Hosting: Migrated from SiteGround to Cloudflare Workers. TTFB dropped from 480 to 140 milliseconds.

5. CartBounty: Added cart abandonment automation (not related to Core Web Vitals but critical for conversion).

Results (6 months later)

• LCP: 2.1 seconds
• INP: 180 milliseconds
• CLS: 0.05
• Monthly organic traffic: 36,960 (340% increase)
• Cart abandonment rate: 46% (22% decrease)
• Conversion rate: increased from 1.8% to 2.9%

In Google Search Console's "Core Web Vitals" report, 240 pages moved to the "Good" category. Previously it was 18 pages.

Common Mistakes and How to Avoid Them

1. Focusing Only on PageSpeed Insights Score

PageSpeed score can be 90+ but real user data can be poor. I always look at field data in Google Search Console.

2. Adding Lazy Loading to All Images

If you add lazy loading to the LCP image, LCP gets even worse. Images visible on the first screen should load immediately.

3. Ignoring Third-Party Scripts

Google Analytics, Facebook Pixel, chatbots can increase INP by 200+ milliseconds. Remove every script that's not really necessary.

4. Forgetting Mobile Testing

Core Web Vitals can be perfect on desktop but disastrous on mobile. I always do tests on mobile first.

5. One-Time Optimization

Core Web Vitals should be continuously monitored. When you add a new feature, there can be performance regression. I do weekly monitoring in FUTIA projects.

How We Approach Core Web Vitals at FUTIA

At FUTIA, I offer clients not just a "fast site" but sustainable performance. My approach has three stages:

1. Technical Audit (1 week)

• PageSpeed Insights, WebPageTest, Lighthouse tests
• Real user data analysis (Google Search Console)
• Bottleneck identification (which resources break LCP, INP, CLS)

2. Optimization (2-4 weeks)

• Image optimization (WebP, CDN, lazy loading)
• JavaScript and CSS cleanup
• Hosting/server improvement
• Third-party script management

3. Monitoring and Maintenance (continuous)

• Weekly Google Search Console check
• Monthly detailed performance report
• Performance testing when new features are added

For example, on memuratamalari.com, to maintain 40,400 monthly organic searches, every time we add a new job posting (50+ daily postings, pulled from ilan.gov.tr API), I test LCP. While generating automatic job postings with Claude Haiku, I also automatically optimize image sizes.

If you want to improve your site's Core Web Vitals, you can email info@futia.net. Or send your site's URL to info@futia.net, I'll do a free technical audit. Don't fall behind your competitors in 2026.