Core Web Vitals 2026: Cách tăng tốc website để vừa lên SEO vừa tăng conversion

6 giờ tới · 9 phút đọc

Tại sao Core Web Vitals quan trọng hơn bao giờ hết

Mình nhớ hồi tối ưu một trang landing page cho dự án cũ. Score Lighthouse đẹp, design ngon, content ổn. Nhưng conversion cứ thấp lạ. Sau khi nhìn kỹ vào số liệu thực tế từ người dùng, hóa ra LCP trên mobile lên tới 5.2 giây. Gần một nửa số người truy cập đã rời đi trước khi trang load xong.

Đó là lúc mình hiểu Core Web Vitals không chỉ là điểm số để đối phó với Google. Nó phản ánh trải nghiệm thực của người dùng.

347395 Điểm số đẹp trên Lighthouse chưa chắc phản ánh trải nghiệm thực tế của người dùng

Từ năm 2021, Google dùng Core Web Vitals như một tín hiệu xếp hạng. Nhưng đến 2025-2026, trọng số của nó tăng lên đáng kể hơn - đặc biệt sau khi Google thay thế FID bằng INP (Interaction to Next Paint) vào tháng 3/2024. INP khó đạt ngưỡng "tốt" hơn FID nhiều, và rất nhiều site đang bị ảnh hưởng mà chưa biết.

Ba metric chính cần nắm:

LCP (Largest Contentful Paint): Thời gian render element lớn nhất - ảnh, heading, block text. Ngưỡng tốt: dưới 2.5 giây
INP (Interaction to Next Paint): Độ trễ từ lúc người dùng tương tác đến khi browser phản hồi. Ngưỡng tốt: dưới 200ms
CLS (Cumulative Layout Shift): Mức độ layout bị nhảy lung tung trong quá trình load. Ngưỡng tốt: dưới 0.1

Đo lường trước, tối ưu sau

Sai lầm phổ biến nhất là nhảy thẳng vào fix mà không biết vấn đề thực sự nằm ở đâu. Đo lường đúng cách tiết kiệm rất nhiều thời gian.

Lab data vs Field data

Có hai loại dữ liệu bạn cần phân biệt:

Lab data (dữ liệu từ môi trường kiểm soát): Lighthouse, PageSpeed Insights chạy trong điều kiện cố định. Hữu ích để debug nhưng không phản ánh người dùng thực.

Field data (dữ liệu thực tế từ người dùng): Chrome UX Report (CrUX), Web Vitals JavaScript API. Đây là số liệu Google dùng để xếp hạng.

347396 Field data từ CrUX mới là thứ Google thực sự dùng để rank - không phải điểm Lighthouse của bạn

Các tool mình hay dùng:

PageSpeed Insights - Xem cả lab lẫn field data, phân tích theo mobile/desktop riêng biệt. Nhớ test URL production, không phải localhost.

Chrome DevTools > Performance panel - Debug chi tiết từng ms. Đặc biệt hữu ích khi trace INP.

Web Vitals Chrome Extension - Hiển thị metrics realtime khi bạn browse. Nhanh để kiểm tra nhanh.

Web Vitals JavaScript API - Gắn vào site để collect field data của người dùng thực:

import { onLCP, onINP, onCLS } from 'web-vitals';

// Gửi metrics về analytics hoặc monitoring service
function sendToAnalytics(metric) {
  // Gửi lên server hoặc Google Analytics
  console.log(metric.name, metric.value, metric.rating);
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

Nếu bạn dùng Google Analytics 4, có thể tích hợp thẳng vào đó để xem phân phối theo device, trang, quốc gia. Rất hữu ích khi trang có traffic đến từ nhiều loại thiết bị khác nhau.

Một điểm cần lưu ý: PageSpeed Insights chỉ hiện field data khi URL của bạn có đủ traffic trong CrUX database. Site mới hoặc traffic thấp sẽ không có field data - lúc đó chỉ dựa vào lab data được.

Tối ưu LCP: Làm cho nội dung chính xuất hiện nhanh hơn

LCP thường bị ảnh hưởng bởi 4 yếu tố chính: server response chậm, render-blocking resources, ảnh chưa được tối ưu, và CSS/font làm chậm quá trình hiển thị.

1. Preload LCP image

Nếu LCP element là một ảnh (thường gặp nhất), đừng để browser tự discover nó. Khai báo thẳng trong <head>:

<!-- Preload ảnh hero - LCP element chính -->
<link rel="preload" as="image" href="/images/hero.webp"
  imagesrcset="/images/hero-400.webp 400w,
               /images/hero-800.webp 800w,
               /images/hero-1200.webp 1200w"
  imagesizes="100vw">

Và đừng lazy load LCP element:

<!-- ❌ Sai - lazy load ảnh hero làm LCP tệ hơn -->
<img src="hero.webp" loading="lazy" alt="Hero">

<!-- ✅ Đúng - fetchpriority cao cho LCP image -->
<img src="hero.webp" fetchpriority="high" loading="eager" alt="Hero">

2. Tối ưu font

Font là thủ phạm âm thầm của LCP. Text là LCP element không kém gì ảnh.

/* Dùng font-display: swap để text hiển thị ngay bằng fallback font */
@font-face {
  font-family: 'MyFont';
  src: url('/fonts/myfont.woff2') format('woff2');
  font-display: swap; /* Hiện text ngay, swap khi font load xong */
}

<!-- Preconnect tới font provider để giảm connection time -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

3. Cải thiện server response time (TTFB)

LCP không thể tốt nếu server response chậm. TTFB dưới 800ms là ngưỡng cần nhắm tới.

347397 Preload + fetchpriority đúng chỗ có thể cắt LCP xuống hơn 1 giây

Một số cách nhanh để giảm TTFB:

Enable HTTP/2 hoặc HTTP/3 trên server
Dùng CDN để phục vụ static assets gần người dùng hơn
Cache response ở tầng server (Redis, Varnish) hoặc tầng CDN
Với Next.js/Nuxt: cân nhắc SSG hoặc ISR thay vì SSR thuần cho các trang không cần dynamic data

Một điều mình thấy hay bị bỏ qua: Resource Hints. dns-prefetch và preconnect cho third-party domains (analytics, CDN, font) giúp giảm đáng kể thời gian kết nối ban đầu.

Tối ưu INP: Làm cho tương tác mượt mà hơn

INP là metric khó nhất trong bộ ba. Không giống LCP hay CLS, INP liên quan trực tiếp đến JavaScript execution - thứ nằm trong tầm kiểm soát của developer nhưng cũng dễ bị phá vỡ nhất.

INP đo thời gian từ lúc người dùng click/tap/keypress đến khi browser paint frame tiếp theo. Nếu main thread đang bận xử lý một đống JS, tương tác sẽ bị trì hoãn.

Break up long tasks

Long task là bất kỳ task nào chạy trên main thread quá 50ms. Chúng block mọi tương tác trong thời gian đó.

// ❌ Xử lý 10,000 items một lần - block main thread
function processItems(items) {
  items.forEach(item => heavyProcess(item));
}

// ✅ Chia nhỏ thành chunks, yield cho browser giữa các lần
async function processItemsChunked(items) {
  const CHUNK_SIZE = 50;
  
  for (let i = 0; i < items.length; i += CHUNK_SIZE) {
    const chunk = items.slice(i, i + CHUNK_SIZE);
    chunk.forEach(item => heavyProcess(item));
    
    // Yield cho browser xử lý tương tác giữa các chunk
    await new Promise(resolve => setTimeout(resolve, 0));
  }
}

Tối ưu event handlers

// ❌ Làm quá nhiều thứ synchronously trong click handler
button.addEventListener('click', () => {
  const data = fetchAndProcessHugeDataset(); // tốn 200ms
  updateUI(data);
  logAnalytics();
  sendNotification();
});

// ✅ Chỉ update UI ngay, defer phần còn lại
button.addEventListener('click', () => {
  // Update UI ngay để browser paint nhanh
  updateUI();
  
  // Defer các tác vụ không ảnh hưởng UI
  requestIdleCallback(() => {
    logAnalytics();
    sendNotification();
  });
});

347398 Main thread rảnh = tương tác mượt. Defer mọi thứ không cần thiết ngay lập tức

Reduce JavaScript bundle size

Bundle to là nguyên nhân gốc rễ của nhiều INP vấn đề. Một số chiến lược:

Code splitting: Chỉ load JS cần thiết cho trang hiện tại. Với React, dùng React.lazy() + Suspense
Tree shaking: Import cụ thể thay vì toàn bộ library. import { debounce } from 'lodash-es' thay vì import _ from 'lodash'
Third-party script audit: Mỗi script analytics, chat widget, A/B testing tool đều ảnh hưởng INP. Delay load chúng sau interaction đầu tiên nếu có thể

Một điểm hay bị bỏ qua: Scheduler API (hiện đã available trên Chrome). Cho phép ưu tiên tasks theo mức độ quan trọng với user interaction.

Tối ưu CLS: Chấm dứt layout nhảy loạn

CLS là metric có vẻ dễ nhất nhưng thực tế lại hay bị ignore. Bạn đã bao giờ đang đọc bài rồi bỗng dưng nội dung nhảy xuống vì quảng cáo load vào? Đó là CLS.

Nguyên nhân phổ biến nhất

Ảnh không có kích thước cố định:

<!-- ❌ Browser không biết trước chiều cao - layout shift khi ảnh load -->
<img src="photo.jpg" alt="Photo">

<!-- ✅ Khai báo width/height - browser reserve space ngay -->
<img src="photo.jpg" width="800" height="600" alt="Photo">

<!-- Hoặc dùng aspect-ratio trong CSS -->
<style>
.image-container {
  aspect-ratio: 4 / 3; /* Reserve space theo tỉ lệ */
  width: 100%;
}
</style>

Font gây layout shift (FOUT/FOLS):

Dùng size-adjust và ascent-override để làm fallback font khớp kích thước với web font:

@font-face {
  font-family: 'FallbackFont';
  src: local('Arial');
  /* Điều chỉnh để match kích thước với web font */
  size-adjust: 105%;
  ascent-override: 90%;
}

Dynamic content chèn từ trên xuống:

// ❌ Chèn banner vào đầu trang sau khi load - đẩy content xuống
document.body.prepend(adBanner);

// ✅ Reserve space trước, fill vào sau
// HTML: <div id="ad-slot" style="min-height: 90px"></div>
document.getElementById('ad-slot').appendChild(adBanner);

347399 Reserve space trước khi content load - cách đơn giản nhất để tránh CLS

Animations gây layout shift:

Tránh animate các property ảnh hưởng layout (width, height, top, left, margin). Thay vào đó dùng transform và opacity - chúng chạy trên GPU, không trigger layout recalculation:

/* ❌ Animate height gây layout shift */
.dropdown { transition: height 0.3s; }

/* ✅ Dùng transform thay thế */
.dropdown {
  transform: scaleY(0);
  transform-origin: top;
  transition: transform 0.3s;
}
.dropdown.open { transform: scaleY(1); }

Case study: Trước và sau tối ưu

Dưới đây là kết quả thực tế từ một trang landing page e-commerce với traffic chủ yếu từ mobile. Trước khi tối ưu, trang này bị stuck ở nhóm "Cần cải thiện" trên cả 3 metrics.

Metric	Trước	Sau	Ngưỡng tốt
LCP	5.2s	1.8s	< 2.5s
INP	480ms	140ms	< 200ms
CLS	0.34	0.06	< 0.1

LCP từ 5.2s xuống 1.8s - Nguyên nhân chính: hero image 1.8MB chưa được compress, không có preload, và đang lazy load nhầm. Fix: convert sang WebP (giảm xuống 180KB), thêm fetchpriority="high", preload trong <head>. Server cũng được chuyển sang gần người dùng hơn qua CDN.

INP từ 480ms xuống 140ms - Thủ phạm là một third-party chat widget load sớm và một analytics script nặng. Fix: delay load cả hai sau DOMContentLoaded + 3 giây. Đồng thời refactor filter/sort handler cho danh sách sản phẩm - trước đó đang re-render toàn bộ list mỗi khi filter.

CLS từ 0.34 xuống 0.06 - Hai nguyên nhân: ảnh sản phẩm không có width/height, và banner khuyến mãi được inject từ JS vào đầu trang. Fix cả hai trong khoảng 30 phút.

347400 Chỉ 3 fix đơn giản - kết quả thay đổi rõ rệt trên cả SEO lẫn conversion

Kết quả sau 6 tuần (so sánh với cùng kỳ trước):

Organic traffic tăng từ 15-30%
Bounce rate giảm 24% bounce rate reduction (Google Core Web Vitals Research & Multiple 2024 Case Studies)
Conversion rate trên mobile tăng {{fact:2}}

Con số cụ thể sẽ khác nhau tùy site và ngành, nhưng hướng cải thiện là nhất quán: trang nhanh hơn = người dùng ở lại lâu hơn = nhiều cơ hội convert hơn.