FCP là gì?
Chỉ số Hiển thị nội dung đầu tiên (FCP) đo lường thời gian từ khi người dùng truy cập vào trang lần đầu tiên đến khi bất kỳ phần nào của nội dung trang được hiển thị trên màn hình. Đối với chỉ số này, "nội dung" đề cập đến văn bản, hình ảnh (bao gồm cả hình nền), phần tử <svg>
hoặc phần tử <canvas>
không phải màu trắng.
Trong tiến trình tải được mô tả trong hình ảnh trước, FCP xảy ra trong khung thứ hai, vì đó là khi phần tử văn bản và hình ảnh đầu tiên hiển thị trên màn hình.
Bạn sẽ nhận thấy rằng mặc dù một số nội dung đã hiển thị, nhưng không phải tất cả nội dung đều hiển thị. Đây là sự khác biệt quan trọng để tạo ra giữa Nội dung đầu tiên hiển thị và Nội dung hiển thị lớn nhất (LCP) – nhằm đo lường thời điểm nội dung chính của trang tải xong.
Điểm FCP nào là tốt?
Để cung cấp trải nghiệm tốt cho người dùng, các trang web nên cố gắng hiển thị nội dung đầu tiên với kích thước 1,8 giây trở xuống. Để đảm bảo hầu hết người dùng của bạn đạt được mục tiêu này, ngưỡng phù hợp để đo lường là phân vị thứ 75 của lượt tải trang, được phân đoạn trên thiết bị di động và thiết bị máy tính.
Cách đo lường FCP
FCP có thể được đo lường trong phòng thí nghiệm hoặc trong thực địa và có sẵn trong các công cụ sau:
Công cụ tại hiện trường
- PageSpeed Insights
- Báo cáo trải nghiệm người dùng trên Chrome
- Search Console (Báo cáo về tốc độ)
- Thư viện JavaScript
web-vitals
Công cụ cho phòng thí nghiệm
Đo lường FCP trong JavaScript
Để đo lường FCP trong JavaScript, bạn có thể sử dụng Paint Timing API. Ví dụ sau đây cho thấy cách tạo PerformanceObserver
để theo dõi mục nhập paint
có tên first-contentful-paint
và ghi lại mục nhập đó vào bảng điều khiển.
new PerformanceObserver((entryList) => {
for (const entry of entryList.getEntriesByName('first-contentful-paint')) {
console.log('FCP candidate:', entry.startTime, entry);
}
}).observe({type: 'paint', buffered: true});
Trong đoạn mã trước, mục nhập first-contentful-paint
đã ghi sẽ cho bạn biết thời điểm phần tử có nội dung đầu tiên được vẽ. Tuy nhiên, trong một số trường hợp, mục này không hợp lệ để đo FCP.
Phần sau đây liệt kê sự khác biệt giữa nội dung mà API báo cáo và cách tính chỉ số.
Sự khác biệt giữa chỉ số và API
- API sẽ gửi một mục nhập
first-contentful-paint
cho các trang được tải trong thẻ nền, nhưng bạn nên bỏ qua các trang đó khi tính FCP (chỉ nên xem xét thời gian sơn đầu tiên nếu trang luôn ở nền trước). - API không báo cáo các mục nhập
first-contentful-paint
khi trang được khôi phục từ bộ nhớ đệm cho thao tác tiến/lùi, nhưng phải đo lường FCP trong những trường hợp này vì người dùng trải nghiệm chúng dưới dạng các lượt truy cập trang riêng biệt. - API có thể không báo cáo thời gian vẽ từ các iframe nhiều nguồn gốc, nhưng để đo lường chính xác FCP, bạn nên xem xét tất cả các khung. Khung con có thể sử dụng API để báo cáo thời gian vẽ của khung con cho khung mẹ để tổng hợp.
- API đo lường FCP từ khi bắt đầu điều hướng, nhưng đối với các trang được kết xuất trước, FCP phải được đo từ
activationStart
vì giá trị này tương ứng với thời gian FCP mà người dùng trải nghiệm.
Thay vì ghi nhớ tất cả những khác biệt nhỏ này, nhà phát triển có thể sử dụng thư viện JavaScript web-vitals
để đo lường FCP, giúp bạn xử lý những khác biệt này (nếu có thể (lưu ý rằng vấn đề iframe sẽ không được đề cập):
import {onFCP} from 'web-vitals';
// Measure and log FCP as soon as it's available.
onFCP(console.log);
Bạn có thể tham khảo mã nguồn cho onFCP()
để xem ví dụ đầy đủ về cách đo lường FCP trong JavaScript.
Cách cải thiện FCP
Để tìm hiểu cách cải thiện FCP cho một trang web cụ thể, bạn có thể chạy quy trình kiểm tra hiệu suất bằng Lighthouse và chú ý đến mọi cơ hội hoặc thông tin chẩn đoán cụ thể mà quy trình kiểm tra đề xuất.
Để tìm hiểu cách cải thiện FCP nói chung (cho mọi trang web), hãy tham khảo các hướng dẫn sau về hiệu suất:
- Loại bỏ tài nguyên chặn hiển thị
- Giảm thiểu CSS
- Xoá CSS không dùng đến
- Xoá JavaScript không dùng đến
- Kết nối trước với những nguồn gốc bắt buộc
- Giảm thời gian phản hồi của máy chủ (TTFB)
- Tránh chuyển hướng trang nhiều lần
- Tải trước các yêu cầu khoá
- Tránh tải trọng lớn trên mạng
- Phân phát các thành phần tĩnh bằng chính sách bộ nhớ đệm hiệu quả
- Tránh kích thước DOM quá lớn
- Giảm thiểu độ sâu yêu cầu quan trọng
- Đảm bảo văn bản vẫn hiển thị trong khi tải phông chữ web
- Giảm số lượng yêu cầu và chuyển những tài nguyên có kích thước nhỏ
Nhật ký thay đổi
Đôi khi, chúng tôi phát hiện lỗi trong các API dùng để đo lường chỉ số và đôi khi là trong định nghĩa của chính các chỉ số đó. Do đó, đôi khi bạn cần phải thực hiện thay đổi và những thay đổi này có thể xuất hiện dưới dạng sự cải thiện hoặc hồi quy trong báo cáo nội bộ và trang tổng quan.
Để giúp bạn quản lý việc này, tất cả các thay đổi đối với cách triển khai hoặc định nghĩa của các chỉ số này sẽ xuất hiện trong Nhật ký thay đổi này.
Nếu có ý kiến phản hồi về các chỉ số này, bạn có thể gửi ý kiến đó trong nhóm Google web-vitals-feedback.