Việc giảm TBT xuống 30 lần và chuyển sang Next.js đã giúp 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à một chỉ số đánh giá khả năng phản hồi 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 phản hồi nhanh với 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 đưa INP làm chỉ số thử nghiệm có tiềm năng phát triển thành một trong các chỉ số Core Web Vitals, nhóm Economic Times chấp nhận thử thách để khắc phục vấn đề này trước khi chuyển thành một chỉ số, vì việc mang đến trải nghiệm người dùng đẳng cấp thế giới rất quan trọng đối với các giá trị kinh doanh cốt lõi của chúng tôi.
Từ trước đến nay, INP là một trong những chỉ số khó giải quyết nhất. Ban đầu, chúng tôi không rõ ràng về cách đo lường INP một cách hiệu quả. Điều khiến mọi người khó khăn hơn là thiếu sự hỗ trợ của cộng đồng, kể cả hầu hết các nhà cung cấp giải pháp Giám sát người dùng thực (RUM) chưa hỗ trợ tính năng 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à những công cụ khác hỗ trợ công cụ này. Điều này giúp chúng tôi xác định được vị thế của mình trong khi đánh giá con đường phía trước. INP của chúng tôi khi bắt đầu có thời gian gần 1.000 mili giây ở cấp độ gốc.
Một điều đã nổi lên trong khi khắc phục INP trong trường này là một trong những chỉ số trong 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 cộng đồng ghi nhận và hỗ trợ đầy đủ. Mặc dù đã đáp ứng các ngưỡng của Chỉ số quan trọng chính của trang web, nhưng chúng tôi vẫn chưa đạt được hiệu suất tốt trên TBT vì chỉ mất hơn 3 giây khi bắt đầu.
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à 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 xem là một tác vụ mất nhiều thời gian và thời gian sau ngưỡng 50 mili giây còn đượ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ụ mất nhiều thời gian trong khi tải, thì thời gian chặn được xác định như sau:
- Tác vụ A mất 80 mili giây (30 mili giây hơn 50 mili giây).
- Tác vụ B mất 100 mili giây (hơn 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.
Sau đây là phần so sánh nhanh về TBT của chúng tôi trong phòng thí nghiệm 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, đến 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, tức là nhấp, nhấn và nhấn phím. Nếu luồng chính đang làm công việc khác, thì luồng đó có thể sẽ không phản hồi hiệu quả hoạt động đầu vào của người dùng và có thể gây ra 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 để phát hiện danh tính người dùng nhằm 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, số liệu 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 các tài sản doanh nghiệp ít quan trọng hơn. Thứ hai, chúng tôi dùng requestIdleCallback cho các công việc không quan trọng, giúp giảm 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ì tính năng này đảm bảo rằng nếu một khoảng thời gian nhất định đã trôi qua mà lệnh gọi lại chưa được gọi, thì lệnh gọi lại sẽ được 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 của bên thứ ba bằng cách sử dụng Thành phần có thể tải. Chúng tôi cũng đã xoá JavaScript và CSS không dùng đến bằng cách phân tích trang bằng công cụ quản lý mức độ phù hợp trong Công cụ cho nhà phát triển của Chrome. Cách này đã giúp chúng tôi xác định được những khía cạnh cần thiết cho hoạt động rung cây để vận chuyển í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ớ, dẫn đến việc 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ố lượng các nút DOM theo 2 cách:
- Đầu tiên, chúng ta 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 xuống khoảng 1.200 nút.
- Thứ hai, chúng tôi tải từng phần các tiện ích ít quan trọng.
Nhờ tất cả những nỗ lực này, chúng tôi đã giảm đáng kể TBT và INP của chúng tôi cũng giảm được gần 50%:
Đến thời điểm này, chúng tôi gần như đã gần như giành hết những thắng lợi dễ dàng để giảm thiểu TBT (và INP theo proxy), nhưng chúng tôi biết còn rất nhiều điểm cần cải thiện. Đó là khi chúng tôi quyết định nâng cấp bả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 để tận dụng hook hiệu quả hơn nhằm tránh việc hiển thị lại các thành phần một cách không cần thiết.
Do chúng tôi 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 dùng PartyTown để giảm tải cho các công việc bổ sung nặng trên luồng chính 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 The Economic Times như thế nào?
TBT và INP hiện tại theo nguồn gốc
Tại thời điểm xuất bản bài đăng 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 nỗ lực tối ưu hóa. Tương tự, INP cho nguồn gốc của chúng tôi là 257 mili giây sau nỗ lực tối ưu hóa của chúng tôi, giảm từ hơn 1.000 mili giây.
Xu hướng CrUX của INP
Lưu lượng truy cập nhận được trên các trang chủ đề chiếm một 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 với kết quả kinh doanh rất đáng khích lệ, giúp chúng tôi mở rộ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 Zagat mPulse
Chúng tôi sử dụng Akamai mPulse làm giải pháp rum để đo lường TBT tại hiện trường. Chúng tôi quan sát thấy TBT giảm đều đặn và thể hiện rõ kết quả trong những nỗ lực giảm INP của chúng tôi. Như có thể thấy trong ảnh chụp màn hình bên dưới, 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 trường.
Kết quả kinh doanh
Nhìn chung, những nỗ lực của chúng tôi trong việc 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. Kết quả là 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 đã giúp ích 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 Economic Times. Dữ liệu này đã được chứng minh là một trong những chỉ số hiệu quả nhất giúp 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 đã quan sát được nhờ nỗ lực này, chúng tôi được thúc đẩy nỗ lực tối ưu hoá mở rộng sang các khu vực khác của trang web và gặt hái thêm nhiều lợi ích.