First Meaningful Paint (FMP)

First Meaningful Paint (FMP) là gì?

First Meaningful Paint (FMP) là chỉ số đo thời điểm trình duyệt lần đầu tiên hiển thị phần nội dung chính — như tiêu đề bài viết, đoạn văn đầu tiên hoặc hình ảnh nổi bật — chứ không phải chỉ các yếu tố trang trí như logo, thanh điều hướng hay nền màu. Đây là một chỉ số hiệu năng web thuộc nhóm Paint Metrics, từng được Google đưa vào Lighthouse và WebPageTest để đánh giá trải nghiệm người dùng ban đầu.

Tuy nhiên, từ tháng 3/2020, Google chính thức loại bỏ FMP khỏi các công cụ phân tích hiện đại như Lighthouse (phiên bản 6.0+), Chrome DevTools và PageSpeed Insights. Lý do: FMP dựa trên thuật toán heuristics phức tạp, dễ bị sai lệch khi trang có nhiều thành phần động (ví dụ: React/Vue render client-side), dẫn đến kết quả không ổn định và khó tái tạo. Thay vào đó, Google khuyến nghị dùng Largest Contentful Paint (LCP) — chỉ số chính xác, đáng tin cậy hơn để đo thời điểm nội dung chính xuất hiện.

Tại sao quan trọng trong SEO?

FMP không còn là yếu tố xếp hạng trực tiếp của Google, nhưng giá trị lịch sử của nó vẫn liên quan đến SEO qua hai khía cạnh:

• Tác động gián tiếp đến trải nghiệm người dùng: Các trang có FMP chậm thường đi kèm với LCP chậm, tỷ lệ thoát cao và thời gian tương tác thấp — những tín hiệu mà Google dùng để đánh giá chất lượng trang.
• Hiểu bối cảnh tối ưu hóa hiệu năng: Nhiều báo cáo hiệu năng cũ (như Lighthouse phiên bản 5.x hoặc báo cáo từ năm 2018–2019) vẫn hiển thị FMP. Việc hiểu FMP giúp bạn đọc đúng báo cáo, tránh nhầm lẫn với các chỉ số khác như First Paint (FP) hay First Contentful Paint (FCP).

Lưu ý: Google chưa bao giờ xác nhận FMP là yếu tố xếp hạng. Không có bằng chứng nào cho thấy cải thiện FMP riêng lẻ sẽ nâng thứ hạng. Tuy nhiên, tối ưu hóa các nguyên nhân gây chậm FMP (như chặn render bởi CSS/JS quá nặng, tải font không hiệu quả) thường đồng thời cải thiện LCP và Core Web Vitals — yếu tố xếp hạng xác thực.

Cách hoạt động

FMP không đo thời gian cố định, mà dựa trên phân tích thay đổi bố cục (layout) và độ phủ pixel của các phần tử “có ý nghĩa” trên màn hình. Trình duyệt theo dõi các lần vẽ (paint) sau khi bắt đầu tải trang, rồi chọn thời điểm mà:

1. Một phần tử lớn (thường là tiêu đề, ảnh, hoặc khối văn bản) xuất hiện rõ ràng;
2. Phần tử đó chiếm ít nhất ~10% diện tích viewport;
3. Và nó không bị che khuất bởi các lớp overlay hoặc animation đang chạy.

Thuật toán FMP chạy hoàn toàn phía client, không phụ thuộc vào thẻ meta hay cấu hình phía máy chủ. Nó không yêu cầu thêm mã JavaScript — nhưng cũng không thể tùy chỉnh hoặc ghi đè bằng performance.mark().

Hướng dẫn thực hiện

Vì FMP đã bị loại bỏ, bạn không nên đo hoặc tối ưu FMP như một mục tiêu độc lập. Thay vào đó, hãy làm theo hướng dẫn sau để đảm bảo cả FMP (nếu vẫn xuất hiện trong báo cáo cũ) và các chỉ số hiện đại đều đạt chuẩn:

1. Xác định chỉ số thay thế: Dùng Lighthouse phiên bản mới nhất (7.0+) hoặc Chrome DevTools > tab Performance để đo LCP, FCP và CLS.
2. Loại bỏ các yếu tố gây chậm render:
   • Rút gọn và hoãn tải CSS không cần thiết (critical CSS inline, phần còn lại defer);
   • Hoãn thực thi JavaScript không cấp thiết (dùng defer hoặc async);
   • Đảm bảo ảnh có kích thước hợp lý, dùng định dạng hiện đại (WebP/AVIF) và có thuộc tính width/height.
3. Kiểm tra trên thiết bị thực: FMP và LCP có thể chênh lệch tới 2–3 giây giữa máy tính để bàn và điện thoại. Luôn kiểm tra trên thiết bị di động thật hoặc mô phỏng bằng chế độ Throttling (4x slowdown + 3G network).
4. Theo dõi lâu dài: Dùng CrUX (Chrome User Experience Report) để xem dữ liệu thực tế từ người dùng — nơi không còn FMP, chỉ có LCP, FID/INP và CLS.

Lỗi thường gặp

Lỗi	Dấu hiệu	Cách khắc phục
FMP bị báo “0 ms” hoặc “NaN”	Trong báo cáo Lighthouse cũ, giá trị FMP không hiển thị hoặc hiển thị không hợp lệ	Cập nhật Lighthouse lên phiên bản mới nhất; kiểm tra xem trang có sử dụng framework SPA mà chưa render server-side hay không — nếu có, cần SSR hoặc SSG để đảm bảo nội dung sẵn sàng từ đầu.
FMP nhanh nhưng LCP chậm	FMP < 1s nhưng LCP > 4s	Do FMP bắt đầu từ phần tử nhỏ (ví dụ: tiêu đề H1 ngắn), trong khi LCP chờ ảnh lớn hoặc khối nội dung chính tải xong. Tập trung tối ưu ảnh, video và lazy-load các phần tử không nằm trong viewport đầu tiên.
FMP thay đổi mỗi lần chạy	Chênh lệch từ 0.8s đến 2.5s giữa các lần kiểm tra cùng một trang	Do FMP phụ thuộc vào layout thay đổi — thường xảy ra khi có JS thay đổi DOM sau load. Chuyển sang dùng LCP (ổn định hơn) và đảm bảo nội dung chính được render sớm, không phụ thuộc vào JS.

Ví dụ thực tế

Một trang tin tức có cấu trúc: header (logo + menu), banner ảnh lớn, tiêu đề bài viết, đoạn mở đầu. Khi kiểm tra bằng Lighthouse 5.7:

• FMP được ghi nhận ở 1.2s — thời điểm tiêu đề bài viết xuất hiện;
• Nhưng ảnh banner (kích thước 1200×630px, chưa nén, không có loading="eager") chỉ xuất hiện ở 3.8s → LCP = 3.8s;
• Sau khi tối ưu: nén ảnh, thêm width/height, preload banner → LCP giảm còn 1.4s, FMP cũng giảm về 0.9s — nhưng điều quan trọng là LCP đạt mức “tốt” (< 2.5s) theo tiêu chuẩn Core Web Vitals.

Trong trường hợp này, việc tập trung vào FMP sẽ khiến bạn bỏ qua nguyên nhân gốc (ảnh chậm tải). Còn tối ưu LCP tự động giải quyết cả hai.

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

FMP có còn được Google sử dụng không?

Không. Từ tháng 3/2020, Google ngừng thu thập và báo cáo FMP trong mọi công cụ chính thức. Các báo cáo còn hiển thị FMP đều là bản cũ hoặc bên thứ ba chưa cập nhật thuật toán.

Tôi nên dùng FMP hay LCP để báo cáo hiệu năng?

Luôn dùng LCP. Đây là chỉ số được Google xác nhận là thay thế trực tiếp cho FMP, có độ chính xác cao hơn, hỗ trợ tốt hơn cho SPA và được tích hợp đầy đủ trong CrUX, Search Console và Lighthouse.

Có thể đo FMP bằng JavaScript không?

Không thể đo FMP bằng code phía client. Không có API Performance Observer hay performance.getEntriesByName('first-meaningful-paint'). FMP chỉ tồn tại như một chỉ số nội bộ của trình duyệt và công cụ phân tích — không exposed qua Web APIs.