Việc giảm TBT xuống 30 lần và chuyển sang Next.js đã giúp The Ecomonic Times giảm INP gần 4 lần, dẫn đến tỷ lệ thoát giảm 50% và số lượt xem trang tăng 43%.
Lượt tương tác với Nội dung hiển thị tiếp theo (INP) là chỉ số đánh giá khả năng thích ứng của một trang web đối với hoạt động đầu vào của người dùng. Khả năng phản hồi tốt có nghĩa là trang nhanh chóng phản hồi với các tương tác của người dùng. INP của trang càng thấp thì khả năng phản hồi tương tác của người dùng càng tốt.
Khởi đầu mơ hồ
Khi Google ban đầu giới thiệu INP làm chỉ số thử nghiệm và có khả năng chuyển đổi thành một trong các Chỉ số quan trọng về trang web, nhóm Thời báo kinh tế đã thách thức khắc phục vấn đề này trước khi trở thành một chỉ số chính, vì việc mang đến trải nghiệm người dùng đẳng cấp thế giới đóng vai trò quan trọng đối với các giá trị cốt lõi của doanh nghiệp.
INP là một trong những chỉ số khó giải quyết nhất cho đến nay. Ban đầu, họ không hiểu rõ về cách đo lường INP hiệu quả. Điều khiến công việc khó khăn hơn là thiếu sự hỗ trợ của cộng đồng, trong đó có hầu hết các nhà cung cấp dịch vụ Giám sát người dùng thực (rum) chưa hỗ trợ công nghệ này. Tuy nhiên, chúng tôi có các công cụ Google rum như Báo cáo trải nghiệm người dùng trên Chrome (CrUX), thư viện JavaScript web-vitals và các công cụ khác cũng như các công cụ khác giúp chúng tôi biết được vị trí của mình trong quá trình đánh giá lộ trình phía trước. INP của chúng tôi chỉ đạt gần 1.000 mili giây ở cấp độ gốc khi chúng tôi bắt đầu.
Có một điều xuất hiện khi khắc phục INP trong trường là một trong những chỉ số phòng thí nghiệm cần nhắm mục tiêu có thể là Tổng thời gian chặn (TBT). TBT đã được ghi lại và nhận được sự ủng hộ của cộng đồng. Mặc dù đã đạt ngưỡng của Các chỉ số quan trọng về trang web, nhưng chúng tôi vẫn không đạt được hiệu quả tốt trên phương diện TBT vì thời gian bắt đầu là hơn 3 giây.
TBT là gì và chúng tôi đã thực hiện những bước nào để cải thiện TBT?
TBT là một chỉ số phòng thí nghiệm đo lường khả năng phản hồi của trang web đối với hoạt động đầu vào của người dùng trong khi tải trang. Bất kỳ tác vụ nào mất hơn 50 mili giây để thực thi đều được coi là một tác vụ mất nhiều thời gian và khoảng thời gian sau ngưỡng 50 mili giây được gọi là thời gian chặn.
TBT được tính bằng cách lấy tổng thời gian chặn của tất cả các tác vụ dài trong quá trình tải trang. Ví dụ: nếu có hai tác vụ dài trong khi tải, thời gian chặn được xác định như sau:
- Nhiệm vụ A mất 80 mili giây (30 mili giây hơn 50 mili giây).
- Nhiệm vụ B mất 100 mili giây (50 mili giây hơn 50 mili giây).
TBT của trang sẽ là: 80 mili giây (30+50). TBT càng thấp thì càng tốt và TBT cũng tương quan tốt với INP.
Dưới đây là bản so sánh ngắn gọn về TBT của chúng tôi trước và sau khi thực hiện các bước để cải thiện TBT:
Giảm thiểu công việc theo luồng chính
Luồng chính của trình duyệt xử lý mọi thứ từ phân tích cú pháp HTML, xây dựng DOM, phân tích cú pháp CSS và áp dụng kiểu, cũng như đánh giá và thực thi JavaScript. Luồng chính cũng xử lý các hoạt động tương tác của người dùng, chẳng hạn như nhấp, nhấn và nhấn phím. Nếu luồng chính đang bận thực hiện công việc khác, luồng này có thể không phản hồi hiệu quả hoạt động đầu vào của người dùng và có thể dẫn đến trải nghiệm người dùng bị giật.
Đây là nhiệm vụ khó khăn nhất đối với chúng tôi, vì chúng tôi có thuật toán riêng nhằm phát hiện danh tính người dùng để phân phát quảng cáo dựa trên trạng thái đăng ký và tập lệnh của bên thứ ba cho thử nghiệm A/B, phân tích, v.v.
Ban đầu, chúng tôi thực hiện các bước nhỏ, chẳng hạn như giảm mức độ ưu tiên tải những thành phần ít quan trọng về doanh nghiệp. Thứ hai, chúng tôi sử dụng requestIdleCallback cho các công việc không quan trọng, nhờ đó giúp giảm thiểu TBT.
if ('requestIdleCallback' in window) {
this.requestIdleCallbackId = requestIdleCallback(fetchMarketsData.bind(this), {timeout: 3000});
} else {
fetchMarketsData(); // Fallback in case requestIdleCallback is not supported
}
Bạn nên chỉ định thời gian chờ khi sử dụng requestIdleCallback, vì điều này đảm bảo rằng nếu thời gian nhất định đã trôi qua và lệnh gọi lại chưa được gọi, thì lệnh gọi lại sẽ thực thi ngay sau khi hết thời gian chờ.
Giảm thiểu thời gian đánh giá tập lệnh
Chúng tôi cũng tải từng phần thư viện bên thứ ba bằng Thành phần có thể tải. Chúng tôi cũng đã xóa JavaScript và CSS không dùng đến bằng cách phân tích trang bằng công cụ mức độ phù hợp trong Công cụ của Chrome cho nhà phát triển. Cách này giúp chúng tôi xác định những khía cạnh cần phải sử dụng tính năng rung cây để gửi ít mã hơn trong quá trình tải trang, từ đó giảm kích thước gói ban đầu của ứng dụng.
Giảm kích thước DOM
Trên mỗi Lighthouse, kích thước DOM lớn làm tăng mức sử dụng bộ nhớ, gây ra tính toán lại kiểu lâu hơn và tạo ra các quy trình chỉnh lại bố cục tốn kém.
Chúng tôi đã giảm số nút DOM theo hai cách:
- Trước tiên, chúng tôi hiển thị các mục trong trình đơn theo yêu cầu của người dùng (khi nhấp vào). Nó đã giảm kích thước DOM khoảng 1.200 nút.
- Thứ hai, chúng ta tải từng phần các tiện ích ít quan trọng hơn.
Nhờ tất cả những nỗ lực đó, chúng tôi đã giảm được đáng kể TBT và INP tương ứng cũng giảm gần 50%:
Đến thời điểm này, chúng tôi gần như đã gần như đã vượt qua các chiến thắng dễ dàng để giảm hơn nữa TBT (và INP theo proxy), nhưng chúng tôi biết rằng mình còn nhiều khả năng để cải thiện. Đây là khi chúng tôi quyết định nâng cấp mã nguyên mẫu giao diện người dùng được tạo tuỳ chỉnh lên phiên bản React mới nhất cùng với Next.js để sử dụng hook hiệu quả hơn nhằm tránh việc kết xuất lại các thành phần một cách không cần thiết.
Do các cập nhật thường xuyên hơn và lưu lượng truy cập tương đối ít hơn so với các phần khác của trang web, chúng tôi đã bắt đầu di chuyển các trang chủ đề sang Next.js. Chúng tôi cũng sử dụng PartyTown để giảm tải thêm công việc luồng chính nặng cho nhân viên web, cùng với các kỹ thuật như requestIdleCallBack để trì hoãn các tác vụ không quan trọng.
Việc cải thiện INP đã giúp ích cho Thời báo kinh tế như thế nào?
TBT và INP hiện tại trên nguồn gốc
Tại thời điểm đăng bài này, TBT cho nguồn gốc của chúng tôi là 120 mili giây, giảm từ 3.260 mili giây khi chúng tôi bắt đầu các nỗ lực tối ưu hoá của mình. Tương tự, INP cho nguồn gốc của chúng tôi là 257 mili giây sau các nỗ lực tối ưu hoá của chúng tôi, giảm từ hơn 1.000 mili giây.
Xu hướng CrUX INP
Lưu lượng truy cập nhận được trên các trang chủ đề chiếm phần nhỏ hơn đáng kể trong tổng lưu lượng truy cập. Do đó, đây là nơi lý tưởng để thử nghiệm. Kết quả CrUX cùng kết quả kinh doanh rất đáng khích lệ, giúp chúng tôi mở rộng những nỗ lực trên toàn bộ trang web để thu được nhiều lợi ích hơn nữa.
Phân tích TBT của KML mPulse
Chúng tôi sử dụng Akamai mPulse làm giải pháp rum để đo lường TBT trong thực tế. Chúng tôi nhận thấy TBT giảm liên tục, cho thấy rõ kết quả của các nỗ lực giảm INP. Như có thể thấy trong ảnh chụp màn hình dưới đây, giá trị TBT cuối cùng đã giảm từ khoảng 5 giây xuống còn khoảng 200 mili giây trong thực địa.
Kết quả kinh doanh
Nhìn chung, những nỗ lực của chúng tôi để giảm TBT xuống 30 lần, cùng với việc chuyển sang Next.js đã giúp chúng tôi giảm INP gần 4 lần, cuối cùng dẫn đến tỷ lệ thoát giảm 50% và số lượt xem trang tăng 43% trên các trang chủ đề.
Kết luận
Tóm lại, INP đã hỗ trợ rất nhiều trong việc xác định các vấn đề về hiệu suất trong thời gian chạy trên các phần của trang web của Economic Times. Chiến lược đã được chứng minh là một trong những chỉ số hiệu quả nhất để tác động tích cực đến kết quả kinh doanh. Do những con số rất đáng khích lệ mà chúng tôi nhận được từ nỗ lực này, chúng tôi có động lực để mở rộng nỗ lực tối ưu hoá sang các khu vực khác trên trang web của mình và thu được thêm nhiều lợi ích.