FCP vs LCP — phân biệt 2 metric paint trong Core Web Vitals

FCP và LCP là 2 chỉ số paint trong Core Web Vitals đo 2 thời điểm khác nhau. FCP đo lúc render nội dung đầu tiên (text, ảnh, SVG bất kỳ); LCP đo lúc render phần tử lớn nhất visible.

Định nghĩa FCP và LCP — đo gì khác nhau

FCP và LCP đo 2 thời điểm khác nhau trong pipeline tải trang. Hiểu chính xác từng chỉ số đo gì là điều kiện tiên quyết để chọn đúng chiến lược tối ưu.

Sửa nhầm điểm nghẽn là lý do phổ biến khiến shop tốn 2–3 tháng audit mà xếp hạng không cải thiện.

FCP — First Contentful Paint

FCP là thời điểm trình duyệt render pixel đầu tiên có nội dung thật — text, ảnh, SVG, hoặc canvas không rỗng. FCP báo với người dùng rằng trang đã bắt đầu hiển thị.

Đo từ khi điều hướng bắt đầu đến khi trình duyệt vẽ frame nội dung đầu tiên. Không tính nền trắng hoặc skeleton placeholder.

Ngưỡng Tốt là dưới 1,8s.

LCP — Largest Contentful Paint

LCP là thời điểm phần tử nội dung lớn nhất trong khung nhìn hoàn tất hiển thị. Phần tử này thường là ảnh hero, heading H1, hoặc poster video.

LCP có thể cập nhật khi trình duyệt phát hiện phần tử mới lớn hơn. Giá trị cuối là LCP của phần tử lớn nhất từng visible trong phiên tải.

Ngưỡng Tốt là dưới 2,5s.

So sánh FCP vs LCP — 8 khía cạnh

Ngưỡng pass và tín hiệu xếp hạng

FCP có ngưỡng “Tốt” dưới 1,8s, “Cần cải thiện” 1,8–3s, “Kém” trên 3s. PSI và Lighthouse hiển thị FCP nhưng Google không dùng FCP làm tín hiệu xếp hạng — FCP chỉ là chỉ số bổ sung.

LCP có ngưỡng “Tốt” dưới 2,5s, “Cần cải thiện” 2,5–4s, “Kém” trên 4s. LCP là 1 trong 3 Core Web Vitals chính thức ảnh hưởng đến xếp hạng.

Bảng ngưỡng và tác động xếp hạng

Khoảng cách FCP–LCP điển hình

Khoảng cách điển hình giữa FCP và LCP là 0,5–1,5s. Sau khi FCP kích hoạt, trình duyệt cần thêm thời gian đó để hoàn tất render ảnh hero.

Khoảng cách trên 2s = điểm nghẽn rõ ràng ở tải ảnh hoặc render nội dung động. LCP fail trong khi FCP pass là trường hợp phổ biến với shop có ảnh hero lớn.

Thứ tự ưu tiên tối ưu — FCP hay LCP trước

Tối ưu LCP trước. LCP ảnh hưởng trực tiếp đến xếp hạng, FCP thì không.

LCP và FCP chia sẻ nhiều điểm nghẽn chung: TTFB chậm, CSS chặn hiển thị, font tải chậm.

Sửa LCP thường cải thiện FCP cùng lúc trong phần lớn trường hợp. Đây là lý do tập trung vào LCP trước là hiệu quả nhất về thời gian đầu tư.

Bảng điểm nghẽn chung và cách sửa

Khi nào FCP và LCP gần nhau, khi nào xa nhau

FCP–LCP gap nhỏ (dưới 500ms) khi trang có hero là text hoặc heading nhỏ — hiển thị xong gần như cùng lúc. Trang tin tức, blog, bảng điều khiển SaaS thường có gap nhỏ.

FCP–LCP gap lớn (trên 1,5s) khi hero là ảnh lớn cần tải riêng. Landing page thương mại điện tử, danh mục dự án, hero full-bleed thường có gap lớn.

Cách đo khoảng cách FCP–LCP

Mở tab Performance của Chrome DevTools — ghi lại quá trình tải trang, xem timeline có 2 marker FCP và LCP. Gap lớn = điểm nghẽn ở ảnh hoặc render nội dung động.

Gap nhỏ = điểm nghẽn nằm ở pipeline TTFB hoặc hiển thị chung — sửa một sẽ sửa cả hai.

Kịch bản đặc thù cần lưu ý

SPA (React, Vue) thường có FCP nhanh (skeleton render ngay) nhưng LCP chậm (fetch dữ liệu + render nội dung thật mất thêm thời gian). Xem thêm tại bài tối ưu LCP và so sánh FCP vs LCP trong cluster này.

Lộ trình tối ưu thực tế — 3 bước

Thứ tự ưu tiên không phụ thuộc vào chỉ số nào cao hơn mà phụ thuộc vào nguyên nhân gốc rễ.

Đừng chạy theo số liệu mà bỏ qua chẩn đoán — biết đúng nguyên nhân trước khi bắt đầu sửa.

Bước 1 — Đo baseline cả FCP và LCP

Chạy PSI cho URL chính (trang chủ, trang sản phẩm tiêu biểu, trang danh mục). Ghi lại cả hai giá trị và khoảng cách.

So sánh với ngưỡng để biết mức độ nghiêm trọng.

Bước 2 — Đo khoảng cách FCP–LCP

Dùng DevTools hoặc xem PSI Diagnostics. Gap trên 1,5s = tập trung vào ảnh hero trước.

Gap dưới 500ms = tập trung vào TTFB và pipeline hiển thị chung.

Bước 3 — Fix theo thứ tự tác động

TTFB → CSS chặn hiển thị → font → ảnh hero. Đo lại sau mỗi bước, không sửa hàng loạt rồi mới đo.

Cách đo FCP và LCP — 3 công cụ thực tế

Đo FCP và LCP trước mỗi lần tối ưu là bắt buộc. Không có baseline thì không biết liệu thay đổi có hiệu quả không.

Cả ba công cụ dưới đây bổ trợ nhau, không thay thế nhau.

Quy tắc: dùng PSI để biết trạng thái hiện tại, DevTools để debug nguyên nhân, web-vitals.js để theo dõi liên tục sau khi deploy.

PageSpeed Insights — kiểm tra nhanh

Truy cập pagespeed.web.dev, dán URL trang và chạy. PSI hiển thị FCP và LCP từ dữ liệu CrUX 28 ngày ở tab “Origin Summary” — đây là dữ liệu xếp hạng thực tế.

Tab “Lab Data” hiển thị FCP và LCP từ lần chạy Lighthouse đơn lẻ. Hữu ích để debug nhưng không dùng để đánh giá pass/fail.

Chrome DevTools — đo và debug trực tiếp

1. Mở DevTools (F12) → tab Performance.
2. Bật “Web Vitals” và “Screenshots” trong phần cài đặt.
3. Giả lập mạng “Slow 4G” và CPU 4x slowdown để sát điều kiện người dùng di động.
4. Click record → tải lại trang → dừng sau 5s.
5. Xem 2 marker FCP và LCP trên timeline. Khoảng cách giữa 2 marker = gap cần phân tích.

web-vitals.js — theo dõi RUM liên tục

import {onFCP, onLCP} from 'web-vitals';

onFCP((metric) => {
  gtag('event', 'web_vitals', {
    metric_name: 'FCP',
    metric_value: Math.round(metric.value),
    metric_rating: metric.rating,
  });
});

onLCP((metric) => {
  gtag('event', 'web_vitals', {
    metric_name: 'LCP',
    metric_value: Math.round(metric.value),
    metric_rating: metric.rating,
    lcp_element: metric.attribution?.element,
  });
});

Gửi cả hai chỉ số vào GA4 để so sánh trend theo thời gian. Phát hiện hồi quy trong 24–48h thay vì đợi 28 ngày từ Search Console.

Ưu tiên tối ưu theo loại trang

FCP và LCP không cần tối ưu giống nhau cho mọi loại trang. Ưu tiên theo tác động thực tế đến người dùng và xếp hạng.

Phân loại trang trước khi lập kế hoạch. Tối ưu ảnh hero cho trang blog tĩnh thường không cải thiện nhiều bằng tối ưu TTFB.

Trang chủ và landing page e-commerce

FCP–LCP gap thường lớn (1–3s) do ảnh hero nặng. Tập trung: preload ảnh hero, chuyển sang WebP với fetchpriority="high", đặt loading="eager".

Cải thiện LCP sẽ cải thiện FCP đồng thời.

Trang blog và tin tức

FCP–LCP gap thường nhỏ (200–500ms) vì hero thường là text hoặc heading. Tập trung: TTFB (cache + hosting), CSS quan trọng inline, preload font.

Sửa TTFB cải thiện cả FCP lẫn LCP cùng lúc.

Trang chi tiết sản phẩm WooCommerce

LCP thường là ảnh sản phẩm gallery đầu tiên. Đặt fetchpriority="high" cho ảnh gallery đầu, tối ưu kích thước ảnh theo từng breakpoint.

Đây là trang ảnh hưởng đến tỉ lệ chuyển đổi nhiều nhất — ưu tiên cao.

Checklist FCP và LCP cho shop WordPress

1. Đo FCP và LCP baseline qua PSI, ghi lại cả hai giá trị.
2. Tính khoảng cách FCP–LCP để xác định nhóm điểm nghẽn.
3. Ưu tiên sửa LCP trước vì tác động xếp hạng trực tiếp.
4. Kiểm tra TTFB — nếu trên 800ms, fix server và cache trước.
5. Inline CSS quan trọng để giảm thời gian hiển thị lần đầu.
6. Preload font woff2 và thêm font-display: swap.
7. Chuyển ảnh hero sang WebP với fetchpriority="high" và loading="eager".
8. Defer tất cả JS không cần thiết cho lần hiển thị đầu.
9. Đo lại sau mỗi thay đổi và so sánh với baseline.
10. Thiết lập web-vitals.js để theo dõi cả FCP và LCP trên production.

Bài liên quan

• Core Web Vitals 2026 — tổng quan 3 chỉ số
• Tối ưu LCP — đo và sửa toàn diện
• TTFB deep-dive — phân tích pipeline và chiến lược tối ưu
• CSS quan trọng là gì — inline và tách cho FCP tốt hơn
• Defer vs async — khi nào dùng cái nào

Câu hỏi thường gặp

Cần audit và tối ưu FCP và LCP cho shop WordPress? Web22 chẩn đoán nguyên nhân, lập lộ trình ưu tiên và thiết lập theo dõi RUM.

Xem dịch vụ tối ưu Core Web Vitals của Web22.