Tập hợp các phương pháp hay nhất mà nhóm Chrome DevRel cho là những cách hiệu quả nhất để cải thiện hiệu suất cho Các chỉ số quan trọng chính của trang web trong năm 2023.
Trong những năm qua, Google đã đưa ra nhiều đề xuất cho các nhà phát triển web về cách cải thiện hiệu suất.
Mặc dù từng đề xuất trong số này, riêng lẻ, có thể cải thiện hiệu suất cho nhiều trang web, nhưng việc tập hợp đầy đủ các đề xuất được chấp nhận là quá choáng ngợp và trên thực tế, không có cách nào để một người hoặc trang web có thể áp dụng tất cả các đề xuất đó.
Nếu không phải là công việc thường ngày của bạn, thì có thể bạn sẽ không rõ ràng những đề xuất có tác động tích cực lớn nhất đến trang web của bạn. Ví dụ: có thể bạn đã biết rằng việc triển khai CSS quan trọng có thể cải thiện hiệu suất tải và bạn cũng có thể nghe nói rằng việc tối ưu hóa hình ảnh là rất quan trọng. Nhưng nếu không có thời gian để làm cả hai việc, làm thế nào bạn sẽ quyết định chọn công cụ nào?
Trong nhóm Chrome, chúng tôi đã dành một năm qua để cố gắng trả lời câu hỏi sau: chúng tôi có thể đưa ra đề xuất nào quan trọng nhất cho nhà phát triển để giúp họ cải thiện hiệu suất cho người dùng?
Để trả lời đầy đủ câu hỏi này, chúng tôi không chỉ xem xét giá trị kỹ thuật của bất kỳ đề xuất nào, mà còn cả các yếu tố con người và tổ chức ảnh hưởng đến khả năng nhà phát triển thực sự có thể áp dụng các đề xuất này. Nói cách khác, về mặt lý thuyết, một số đề xuất có thể có tác động cực kỳ lớn, nhưng trên thực tế, rất ít trang web có thời gian hoặc nguồn lực để triển khai chúng. Tương tự, một số đề xuất rất quan trọng, nhưng hầu hết trang web hiện đang áp dụng các phương pháp này.
Tóm lại, chúng tôi muốn danh sách các đề xuất hàng đầu về hiệu suất web của chúng tôi tập trung vào:
- Các đề xuất mà chúng tôi tin rằng sẽ có tác động thực tế lớn nhất
- Các đề xuất phù hợp và phù hợp với hầu hết các trang web
- Những đề xuất thiết thực mà hầu hết nhà phát triển nên áp dụng
Trong năm qua, chúng tôi đã dành rất nhiều thời gian để kiểm tra toàn bộ các đề xuất về hiệu suất mà chúng tôi đưa ra và đánh giá từng đề xuất (cả về mặt định tính và định lượng) theo 3 tiêu chí nêu trên.
Bài đăng này trình bày những đề xuất hàng đầu giúp cải thiện hiệu suất cho từng chỉ số trong Các chỉ số quan trọng về trang web. Nếu bạn chưa quen với hiệu suất web hoặc đang cố gắng quyết định xem điều gì sẽ mang lại cho bạn hiệu suất lớn nhất, chúng tôi nghĩ những đề xuất này là nơi tốt nhất để bắt đầu.
Thời gian hiển thị nội dung lớn nhất (LCP)
Bộ đề xuất đầu tiên của chúng tôi là dành cho Nội dung lớn nhất hiển thị (LCP), một chỉ số đo lường hiệu suất tải. Trong 3 chỉ số Core Web Vitals, LCP là chỉ số mà nhiều trang web nhất đang gặp khó khăn (chỉ khoảng một nửa số trang web trên web hiện nay đáp ứng ngưỡng đề xuất – vì vậy, hãy bắt đầu từ đó.
Đảm bảo tài nguyên LCP có thể tìm thấy qua nguồn HTML
Theo Niên giám web năm 2022 của HTTP Archive, 72% số trang dành cho thiết bị di động có hình ảnh làm phần tử LCP. Điều này có nghĩa là hầu hết các trang web cần tối ưu hoá LCP, họ cần đảm bảo những hình ảnh đó có thể tải nhanh.
Có thể nhiều nhà phát triển không thấy rõ rằng thời gian tải hình ảnh chỉ là một phần trong thách thức. Một phần quan trọng khác là thời gian trước khi hình ảnh bắt đầu tải, và dữ liệu trong Kho lưu trữ HTTP cho thấy đó thực sự là nơi nhiều trang web bị vướng mắc.
Trên thực tế, trong số những trang mà phần tử LCP là một hình ảnh, có 39% trong số những hình ảnh đó có URL nguồn không phát hiện được qua nguồn tài liệu HTML. Nói cách khác, hệ thống không tìm thấy những URL đó trong các thuộc tính HTML chuẩn (chẳng hạn như <img src="..."> hoặc <link rel="preload" href="...">). Điều này sẽ cho phép trình duyệt nhanh chóng phát hiện ra các URL đó và bắt đầu tải ngay.
Nếu một trang cần phải đợi các tệp CSS hoặc JavaScript được tải xuống, phân tích cú pháp và xử lý đầy đủ trước khi hình ảnh có thể bắt đầu tải thì có thể đã quá muộn.
Theo quy tắc chung, nếu phần tử LCP của bạn là một hình ảnh, thì URL của hình ảnh đó phải luôn tìm thấy được từ nguồn HTML. Bạn có thể áp dụng một số mẹo sau:
Tải hình ảnh bằng phần tử
<img>có thuộc tínhsrchoặcsrcset. Không sử dụng các thuộc tính không chuẩn nhưdata-srcyêu cầu JavaScript để hiển thị, vì sẽ luôn chậm hơn. 9% số trang che khuất hình ảnh LCP (Nội dung lớn nhất hiển thị) phía saudata-src.Ưu tiên hiển thị phía máy chủ (SSR) hơn là hiển thị phía máy khách (CSR) vì SSR ngụ ý rằng mã đánh dấu trang đầy đủ (bao gồm cả hình ảnh) có trong nguồn HTML. Các giải pháp CSR yêu cầu JavaScript chạy trước khi có thể khám phá hình ảnh.
Nếu hình ảnh của bạn cần được tham chiếu từ một tệp JS hoặc CSS bên ngoài, bạn vẫn có thể đưa hình ảnh đó vào nguồn HTML thông qua thẻ
<link rel="preload">. Lưu ý rằng trình quét tải trước của trình duyệt không thể tìm thấy hình ảnh được tham chiếu theo kiểu cùng dòng, vì vậy, mặc dù chúng được tìm thấy trong nguồn HTML nhưng việc khám phá các hình ảnh này vẫn có thể bị chặn khi tải các tài nguyên khác, vì vậy việc tải trước có thể hữu ích trong những trường hợp này.
Để giúp bạn biết liệu hình ảnh LCP của bạn có vấn đề về khả năng được phát hiện hay không, Lighthouse sẽ phát hành một bản kiểm tra mới trong phiên bản 10.0 (dự kiến vào tháng 1 năm 2023).
Việc đảm bảo tài nguyên LCP có thể tìm thấy được qua nguồn HTML có thể giúp cải thiện những kết quả có thể đo lường được, đồng thời cũng mang lại thêm nhiều cơ hội để ưu tiên tài nguyên này, đây là đề xuất tiếp theo của chúng tôi.
Đảm bảo tài nguyên LCP được ưu tiên
Việc đảm bảo có thể khám phá tài nguyên LCP từ nguồn HTML là bước quan trọng đầu tiên để đảm bảo tài nguyên LCP có thể bắt đầu tải sớm. Tuy nhiên, một bước quan trọng khác là đảm bảo rằng quá trình tải tài nguyên đó được ưu tiên và không bị xếp hàng đợi sau một loạt tài nguyên khác ít quan trọng hơn.
Ví dụ: ngay cả khi hình ảnh LCP của bạn hiện diện trong nguồn HTML bằng thẻ <img> tiêu chuẩn, nếu trang của bạn có hàng chục thẻ <script> trong <head> của tài liệu trước thẻ <img> đó, thì có thể mất một lúc trước khi tài nguyên hình ảnh bắt đầu tải.
Cách dễ nhất để giải quyết vấn đề này là cung cấp gợi ý cho trình duyệt về những tài nguyên nào có mức độ ưu tiên cao nhất bằng cách đặt thuộc tính mới fetchpriority="high" trên thẻ <img> hoặc <link> tải hình ảnh LCP của bạn. Lệnh này sẽ hướng dẫn trình duyệt tải tập lệnh sớm hơn thay vì đợi các tập lệnh đó hoàn tất.
Theo Web Almanac, chỉ 0,03% số trang đủ điều kiện đang tận dụng lợi thế của API mới này, nghĩa là có rất nhiều cơ hội để hầu hết các trang web trên web cải thiện LCP mà không cần nhiều công sức. Mặc dù thuộc tính fetchpriority hiện chỉ được hỗ trợ trong các trình duyệt dựa trên Chromium, nhưng API này là một tính năng nâng cao tiến bộ mà các trình duyệt khác bỏ qua. Vì vậy, các nhà phát triển nên sử dụng ngay.
Đối với các trình duyệt không phải Chromium, cách duy nhất để đảm bảo tài nguyên LCP được ưu tiên hơn các tài nguyên khác là tham chiếu đến tài nguyên đó sớm hơn trong tài liệu. Sử dụng lại ví dụ về một trang web có nhiều thẻ <script> trong <head> của tài liệu, nếu muốn đảm bảo tài nguyên LCP được ưu tiên hơn các tài nguyên tập lệnh đó, bạn có thể thêm thẻ <link rel="preload"> trước bất kỳ tập lệnh nào trong số đó hoặc bạn có thể di chuyển các tập lệnh đó xuống dưới <img> sau trong <body>. Mặc dù cách này hiệu quả nhưng sẽ ít tiện dụng hơn so với việc sử dụng fetchpriority. Vì vậy, chúng tôi hy vọng các trình duyệt khác sẽ sớm được hỗ trợ.
Một khía cạnh quan trọng khác của việc ưu tiên tài nguyên LCP là đảm bảo bạn không làm bất cứ việc gì khiến tài nguyên đó bị giảm mức độ ưu tiên, chẳng hạn như thêm thuộc tính loading="lazy". Hiện nay, 10% số trang thực sự đặt loading="lazy" trên hình ảnh LCP. Cảnh giác với các giải pháp tối ưu hoá hình ảnh áp dụng bừa bãi hành vi tải từng phần cho tất cả hình ảnh. Nếu chúng đưa ra cách ghi đè hành vi đó, hãy nhớ sử dụng hành vi đó cho hình ảnh LCP. Nếu bạn không chắc hình ảnh nào sẽ là LCP (Nội dung lớn nhất hiển thị), hãy thử dùng phương pháp phỏng đoán để chọn ra một hình ảnh phù hợp.
Trì hoãn các tài nguyên không quan trọng là một cách khác để tăng mức độ ưu tiên tương đối của tài nguyên LCP một cách hiệu quả. Ví dụ: các tập lệnh không hỗ trợ giao diện người dùng (như tập lệnh phân tích hoặc tiện ích mạng xã hội) có thể được trì hoãn một cách an toàn cho đến sau khi sự kiện load kích hoạt. Điều này đảm bảo các tập lệnh đó sẽ không cạnh tranh với các tài nguyên quan trọng khác (như tài nguyên LCP) để có băng thông mạng.
Tóm lại, bạn nên làm theo các phương pháp hay nhất sau đây để đảm bảo tài nguyên LCP được tải sớm và ở mức độ ưu tiên cao:
- Thêm
fetchpriority="high"vào thẻ<img>của hình ảnh LCP. Nếu tài nguyên LCP được tải thông qua thẻ<link rel="preload">, đừng lo vì bạn cũng có thể đặtfetchpriority="high"trên đó! - Không bao giờ đặt
loading="lazy"trên thẻ<img>của hình ảnh LCP. Thao tác này sẽ giảm mức độ ưu tiên của hình ảnh và trì hoãn thời gian hình ảnh bắt đầu tải. - Trì hoãn các tài nguyên không quan trọng nếu có thể. Bạn có thể di chuyển chúng đến cuối tài liệu, sử dụng tính năng tải từng phần gốc cho hình ảnh hoặc iframe, hoặc tải không đồng bộ qua JavaScript.
Sử dụng CDN để tối ưu hoá tài liệu và tài nguyên TTFB
Hai đề xuất trước tập trung vào việc đảm bảo tài nguyên LCP của bạn được phát hiện sớm và được ưu tiên để có thể bắt đầu tải ngay. Phần cuối cùng của câu đố này là đảm bảo tài liệu phản hồi ban đầu cũng được gửi nhanh nhất có thể.
Trình duyệt không thể bắt đầu tải bất kỳ tài nguyên phụ nào cho đến khi nhận được byte đầu tiên của phản hồi tài liệu HTML ban đầu và việc đó càng xảy ra sớm thì mọi thứ khác cũng có thể bắt đầu sớm hơn.
Thời gian này được gọi là Thời gian đến byte đầu tiên (TTFB) và cách tốt nhất để giảm TTFB là:
- Phân phát nội dung của bạn ở vị trí địa lý gần người dùng nhất có thể
- Lưu nội dung đó vào bộ nhớ đệm để nội dung được yêu cầu gần đây có thể được phân phát lại nhanh chóng.
Cách tốt nhất để làm cả hai việc này là sử dụng CDN. CDN phân phối tài nguyên của bạn đến các máy chủ gần nguồn được trải rộng trên toàn cầu, do đó hạn chế khoảng cách mà những tài nguyên đó phải được truyền qua mạng đến người dùng. CDN cũng thường có các chế độ kiểm soát chi tiết về việc lưu vào bộ nhớ đệm, có thể được tuỳ chỉnh và tối ưu hoá theo nhu cầu của trang web.
Nhiều nhà phát triển đã quen thuộc với việc sử dụng CDN để lưu trữ nội dung tĩnh, nhưng CDN cũng có thể phân phát và lưu tài liệu HTML vào bộ nhớ đệm, ngay cả những tài liệu được tạo động.
Theo Web Almanac, chỉ 29% yêu cầu tài liệu HTML được phân phát từ CDN. Điều này đồng nghĩa với việc các trang web có nhiều cơ hội để yêu cầu tiết kiệm thêm tiền.
Một số mẹo để định cấu hình CDN của bạn là:
- Cân nhắc tăng thời lượng nội dung được lưu vào bộ nhớ đệm (ví dụ: nội dung luôn mới có thật sự quan trọng không? Hoặc nó có thể lỗi thời vài phút không?).
- Thậm chí, bạn nên cân nhắc việc lưu nội dung vào bộ nhớ đệm vô thời hạn rồi xoá bộ nhớ đệm nếu/khi cập nhật.
- Khám phá xem bạn có thể di chuyển logic động hiện đang chạy trên máy chủ gốc của mình sang Edge (một tính năng của hầu hết các CDN hiện đại) hay không.
Nhìn chung, bất cứ lúc nào bạn có thể phân phát nội dung trực tiếp từ lề (tránh phải chuyển tới máy chủ gốc của bạn), thì bạn đều đạt được hiệu suất cao. Và ngay cả trong trường hợp bạn phải quay lại máy chủ gốc của mình, CDN thường được tối ưu hoá để thực hiện việc đó nhanh hơn nhiều, vì vậy, dù bằng cách nào thì vẫn hiệu quả.
Điểm số tổng hợp về mức thay đổi bố cục (CLS)
Chúng tôi đề xuất tiếp theo cho chỉ số Mức thay đổi bố cục tích luỹ (CLS). Đây là chỉ số đo lường độ ổn định của hình ảnh trên trang web. Mặc dù CLS đã cải thiện rất nhiều trên web từ năm 2020, nhưng khoảng 1/4 số trang web vẫn chưa đáp ứng ngưỡng đề xuất, do đó, nhiều trang web vẫn còn cơ hội lớn để cải thiện trải nghiệm người dùng.
Đặt kích thước rõ ràng cho mọi nội dung được tải từ trang
Thay đổi bố cục thường xảy ra khi nội dung hiện có di chuyển sau khi nội dung khác tải xong. Do đó, cách chính để giảm thiểu tình trạng này là đặt trước mọi chỗ trống cần thiết càng nhiều càng tốt.
Cách đơn giản nhất để khắc phục sự thay đổi bố cục do hình ảnh không có kích thước là thiết lập rõ ràng các thuộc tính width và height (hoặc các thuộc tính CSS tương đương). Tuy nhiên, theo HTTP Archive, 72% số trang có ít nhất 1 hình ảnh chưa định kích thước. Nếu không có kích thước rõ ràng, ban đầu, các trình duyệt sẽ đặt chiều cao mặc định là 0px. Việc này có thể gây ra sự thay đổi đáng kể về bố cục khi hình ảnh được tải xong và kích thước được tìm thấy. Điều này vừa là một cơ hội lớn cho web tập thể, vừa là cơ hội đòi hỏi ít nỗ lực hơn nhiều so với một số đề xuất khác được đề xuất trong bài viết này.
Bạn cần lưu ý rằng hình ảnh không phải là yếu tố duy nhất đóng góp vào CLS. Những thay đổi về bố cục có thể là do các nội dung khác thường được tải sau khi trang hiển thị lần đầu, bao gồm cả quảng cáo của bên thứ ba hoặc video được nhúng. Thuộc tính aspect-ratio có thể giúp ngăn chặn vấn đề này. Đây là một tính năng CSS tương đối mới cho phép nhà phát triển cung cấp rõ ràng tỷ lệ khung hình cho hình ảnh cũng như các phần tử không phải hình ảnh. Việc này sẽ cho phép bạn đặt width động (ví dụ: dựa trên kích thước màn hình) và cho phép trình duyệt tự động tính toán chiều cao thích hợp, giống như cách tính toán chiều cao thích hợp đối với hình ảnh có kích thước.
Đôi khi, bạn không thể biết chính xác kích thước của nội dung động vì bản chất của nội dung động là linh động. Tuy nhiên, ngay cả khi không biết kích thước chính xác, bạn vẫn có thể thực hiện các bước để giảm mức độ nghiêm trọng của việc thay đổi bố cục. Việc đặt min-height hợp lý hầu như luôn hiệu quả hơn việc cho phép trình duyệt sử dụng chiều cao mặc định là 0px cho phần tử trống. Việc sử dụng min-height cũng thường là cách khắc phục dễ dàng vì nó vẫn cho phép vùng chứa tăng đến chiều cao nội dung cuối cùng nếu cần – cách này chỉ làm giảm mức tăng trưởng đó từ mức đầy đủ xuống một mức có thể chấp nhận được hơn.
Đảm bảo các trang đủ điều kiện dùng bfcache
Trình duyệt sử dụng cơ chế điều hướng có tên là bộ nhớ đệm cho thao tác tiến/lùi (hay gọi tắt là bfcache) để tải ngay một trang từ trước đó hoặc sau đó trong nhật ký duyệt web ngay từ ảnh chụp nhanh bộ nhớ.
Bộ nhớ đệm bfcache là một giải pháp tối ưu hoá hiệu suất quan trọng ở cấp trình duyệt và nó giúp loại bỏ hoàn toàn sự thay đổi bố cục trong quá trình tải trang, đây là nơi hầu hết CLS (Mức thay đổi bố cục tích luỹ) xảy ra. Sự ra đời của bfcache đã mang lại sự cải thiện lớn nhất về CLS mà chúng tôi nhận thấy vào năm 2022.
Mặc dù vậy, một số lượng đáng kể các trang web không đủ điều kiện để dùng bfcache và do đó đang bỏ lỡ cơ hội nâng cao hiệu suất web miễn phí này trong một số lượng đáng kể các thao tác. Trừ khi trang của bạn đang tải thông tin nhạy cảm mà bạn không muốn bị khôi phục từ bộ nhớ, bạn sẽ phải đảm bảo rằng các trang của mình đủ điều kiện.
Chủ sở hữu trang web nên kiểm tra để đảm bảo các trang của họ đủ điều kiện được thêm vào bfcache và tìm hiểu nguyên nhân. Chrome đã có trình kiểm thử bfcache trong Công cụ cho nhà phát triển và năm nay chúng tôi dự định tăng cường công cụ ở đây với tính năng kiểm tra mới của Lighthouse thực hiện kiểm thử tương tự và một API để đo lường điều này trong thực địa.
Mặc dù chúng tôi đã đưa bfcache vào phần CLS, nhưng chúng tôi nhận thấy đây là điểm tăng lớn nhất từ trước đến nay, nhưng nhìn chung thì bfcache cũng sẽ cải thiện được các Chỉ số quan trọng chính khác của trang web. Đây là một trong nhiều thao tác điều hướng tức thì có sẵn để cải thiện đáng kể thao tác điều hướng trang.
Tránh các ảnh động/chuyển đổi sử dụng thuộc tính CSS tạo bố cục
Một nguồn phổ biến khác gây ra sự thay đổi bố cục là khi các phần tử được tạo ảnh động. Ví dụ: biểu ngữ cookie hoặc biểu ngữ thông báo khác trượt vào từ trên cùng hoặc dưới cùng thường đóng góp vào CLS (Mức thay đổi bố cục tích luỹ). Điều này đặc biệt khó khăn khi các biểu ngữ này đẩy nội dung khác sang một bên, nhưng ngay cả khi chúng không làm như vậy, việc tạo ảnh động cho nội dung đó vẫn có thể ảnh hưởng đến CLS (Mức thay đổi bố cục tích luỹ).
Mặc dù dữ liệu của Kho lưu trữ HTTP không thể kết nối chắc chắn ảnh động với thay đổi bố cục, nhưng dữ liệu cho thấy rằng các trang tạo ảnh động cho bất kỳ thuộc tính CSS nào có thể ảnh hưởng đến bố cục ít có khả năng có CLS "tốt" hơn 15% so với tổng thể của các trang. Một số cơ sở lưu trú có liên quan đến CLS (Mức thay đổi bố cục tích luỹ) thấp hơn so với những cơ sở lưu trú khác. Ví dụ: các trang tạo ảnh động cho chiều rộng margin hoặc border có CLS "kém" với tốc độ gần gấp đôi so với tỷ lệ tổng thể của các trang bị đánh giá là kém.
Điều này có lẽ không có gì bất ngờ, vì bất cứ khi nào bạn chuyển đổi hoặc tạo ảnh động cho bất kỳ thuộc tính CSS nào tạo ra bố cục, điều này sẽ dẫn đến sự thay đổi bố cục và nếu những thay đổi bố cục đó không diễn ra trong vòng 500 mili giây của một lượt tương tác của người dùng, thì chúng sẽ ảnh hưởng đến CLS (Mức thay đổi bố cục tích luỹ).
Điều này có thể khiến một số nhà phát triển ngạc nhiên vì điều này vẫn đúng ngay cả trong trường hợp phần tử bị đưa ra ngoài luồng tài liệu thông thường. Ví dụ: các phần tử có vị trí tuyệt đối tạo ảnh động cho top hoặc left sẽ khiến bố cục thay đổi, ngay cả khi các phần tử này không đẩy nội dung khác xung quanh. Tuy nhiên, nếu thay vì tạo ảnh động cho top hoặc left mà bạn tạo ảnh động transform:translateX() hoặc transform:translateY(), thì thao tác này sẽ không khiến trình duyệt cập nhật bố cục trang và do đó sẽ không tạo ra bất kỳ thay đổi nào về bố cục.
Việc ưu tiên ảnh động của các thuộc tính CSS có thể cập nhật được trên luồng trình tổng hợp của trình duyệt từ lâu đã là phương pháp hay nhất về hiệu suất vì hoạt động này di chuyển hoạt động trên GPU và ra ngoài luồng chính. Ngoài việc là một phương pháp hay nhất về hiệu suất chung, quy trình này cũng có thể giúp cải thiện CLS (Mức thay đổi bố cục tích luỹ).
Theo nguyên tắc chung, đừng bao giờ tạo ảnh động hoặc chuyển đổi bất kỳ thuộc tính CSS nào yêu cầu trình duyệt cập nhật bố cục trang, trừ phi bạn thực hiện việc này để phản hồi thao tác nhấn hoặc nhấn phím của người dùng (mặc dù không phải hover). Và bất cứ khi nào có thể, hãy ưu tiên chuyển đổi và ảnh động bằng thuộc tính transform CSS.
Kiểm tra Lighthouse Tránh các ảnh động không được tổng hợp sẽ cảnh báo khi một trang tạo ảnh động cho các thuộc tính CSS có khả năng bị chậm.
Thời gian phản hồi lần tương tác đầu tiên (FID)
Bộ đề xuất cuối cùng của chúng tôi là về Độ trễ đầu vào lần đầu (FID), chỉ số này để đo lường khả năng phản hồi của trang đối với tương tác của người dùng. Mặc dù hầu hết các trang web trên web hiện đạt điểm rất cao trên FID, nhưng chúng tôi đã ghi lại những điểm thiếu sót của chỉ số FID trước đây và chúng tôi tin rằng vẫn còn nhiều cơ hội để các trang web cải thiện khả năng phản hồi tổng thể của họ đối với tương tác của người dùng.
Chỉ số Lượt tương tác với nội dung hiển thị tiếp theo (INP) mới của chúng tôi có thể là chỉ số kế thừa cho FID, và tất cả những đề xuất dưới đây đều áp dụng hiệu quả như nhau cho cả FID và INP. Vì các trang web có hiệu suất kém hơn trên INP so với FID, đặc biệt là trên thiết bị di động, các nhà phát triển nên xem xét nghiêm túc các đề xuất về khả năng phản hồi này, mặc dù FID có FID "tốt".
Tránh hoặc chia nhỏ các công việc dài
Tác vụ là bất kỳ phần công việc rời rạc nào do trình duyệt thực hiện. Các nhiệm vụ bao gồm hiển thị, bố cục, phân tích cú pháp, biên dịch và thực thi tập lệnh. Khi tác vụ trở thành tác vụ dài (tức là 50 mili giây trở lên) chúng sẽ chặn luồng chính phản hồi nhanh với hoạt động đầu vào của người dùng.
Theo Niên giám web, có nhiều bằng chứng cho thấy nhà phát triển có thể làm nhiều việc hơn để tránh hoặc chia nhỏ các công việc dài. Mặc dù việc chia nhỏ các công việc dài có thể không dễ dàng như các đề xuất khác trong bài viết này, nhưng sẽ dễ dàng hơn so với các kỹ thuật khác không có trong bài viết này.
Mặc dù bạn phải luôn cố gắng thực hiện ít thao tác nhất có thể trong JavaScript, nhưng bạn có thể giúp luồng chính khá nhiều bằng cách chia các tác vụ dài thành các tác vụ nhỏ hơn. Bạn có thể thực hiện việc này bằng cách tạo chuỗi chính thường xuyên để việc hiển thị nội dung cập nhật và các hoạt động tương tác khác của người dùng có thể diễn ra nhanh hơn.
Một lựa chọn khác là cân nhắc sử dụng các API như isInputPending và Scheduler API (API Trình lập lịch biểu). isInputPending là một hàm trả về một giá trị boolean cho biết liệu hoạt động đầu vào của người dùng có đang chờ xử lý hay không. Nếu hàm này trả về true, bạn có thể tạo luồng chính để luồng chính xử lý hoạt động đầu vào đang chờ xử lý của người dùng.
API Trình lập lịch biểu là một phương pháp nâng cao hơn, cho phép bạn lên lịch công việc dựa trên hệ thống mức độ ưu tiên, có tính đến việc liệu công việc đang được thực hiện sẽ hiển thị cho người dùng hay ở chế độ nền.
Bằng cách chia nhỏ các tác vụ dài, bạn mang lại cho trình duyệt nhiều cơ hội hơn để thực hiện công việc quan trọng mà người dùng có thể nhìn thấy, chẳng hạn như xử lý các tương tác và bất kỳ cập nhật hiển thị nào.
Tránh JavaScript không cần thiết
Chắc chắn về điều này: các trang web đang gửi nhiều JavaScript hơn bao giờ hết và có vẻ như xu hướng này sẽ sớm thay đổi. Khi gửi quá nhiều JavaScript, bạn sẽ tạo ra một môi trường trong đó các tác vụ đang cạnh tranh để giành sự chú ý của luồng chính. Điều này chắc chắn có thể ảnh hưởng đến khả năng phản hồi của trang web, đặc biệt là trong giai đoạn khởi động quan trọng đó.
Tuy nhiên, đây không phải là bài toán không thể giải quyết. Bạn có một số lựa chọn như sau:
- Sử dụng công cụ quản lý mức độ phù hợp trong Công cụ của Chrome cho nhà phát triển để tìm mã không dùng đến trong tài nguyên của trang web. Bằng cách giảm kích thước tài nguyên cần thiết trong quá trình khởi động, bạn có thể đảm bảo trang web của mình mất ít thời gian hơn để phân tích cú pháp và biên dịch mã, nhờ đó mang lại trải nghiệm ban đầu mượt mà hơn cho người dùng.
- Đôi khi, mã không sử dụng mà bạn tìm thấy bằng công cụ xác định mức độ sử dụng được đánh dấu là "không sử dụng" vì không được thực thi trong quá trình khởi động, nhưng vẫn cần thiết cho một số chức năng trong tương lai. Đây là mã mà bạn có thể chuyển sang một gói riêng thông qua tính năng phân tách mã.
- Nếu bạn đang sử dụng trình quản lý thẻ, hãy nhớ kiểm tra định kỳ thẻ để đảm bảo thẻ được tối ưu hoá hoặc ngay cả khi thẻ vẫn đang được sử dụng. Bạn có thể xóa các thẻ cũ hơn có mã không sử dụng để làm cho JavaScript của trình quản lý thẻ nhỏ hơn và hiệu quả hơn.
Tránh các bản cập nhật kết xuất lớn
JavaScript không phải là yếu tố duy nhất có thể ảnh hưởng đến khả năng phản hồi của trang web. Bản thân hiển thị có thể là một loại công việc tốn kém và khi quá trình cập nhật kết xuất trên quy mô lớn xảy ra, chúng có thể ảnh hưởng đến khả năng phản hồi hoạt động đầu vào của người dùng trên trang web của bạn.
Tối ưu hoá công việc kết xuất không phải là một quá trình đơn giản và thường phụ thuộc vào mục tiêu bạn đang cố gắng đạt được. Mặc dù vậy, có một số việc bạn có thể làm để đảm bảo cập nhật kết xuất của mình là hợp lý và không kéo dài thành các tác vụ dài:
- Tránh sử dụng
requestAnimationFrame()để thực hiện các thao tác không liên quan đến hình ảnh. Các lệnh gọirequestAnimationFrame()được xử lý trong giai đoạn kết xuất của vòng lặp sự kiện. Khi bạn thực hiện quá nhiều thao tác ở bước này, quá trình cập nhật quá trình kết xuất có thể bị chậm trễ. Điều quan trọng là mọi tác vụ bạn đang thực hiện vớirequestAnimationFrame()đều phải được dành riêng cho các tác vụ liên quan đến việc hiển thị nội dung cập nhật. - Duy trì kích thước DOM ở mức nhỏ. Kích thước DOM và cường độ của công việc bố cục có mối tương quan với nhau. Khi trình kết xuất phải cập nhật bố cục cho một DOM rất lớn, lượng công việc cần thiết để tính toán lại bố cục của nó có thể tăng đáng kể.
- Sử dụng vùng chứa CSS. Vùng chứa CSS dựa vào thuộc tính CSS
contain, đưa ra hướng dẫn cho trình duyệt về cách bố trí bố cục cho vùng chứa mà thuộc tínhcontainđược đặt, bao gồm cả việc tách biệt phạm vi của bố cục và hiển thị đến một gốc cụ thể trong DOM. Đây không phải lúc nào cũng là một quá trình dễ dàng, nhưng bằng cách tách biệt các khu vực chứa bố cục phức tạp, bạn có thể tránh thực hiện công việc bố cục và kết xuất không cần thiết cho các khu vực này.
Kết luận
Việc cải thiện hiệu suất trang có vẻ là một nhiệm vụ khó khăn, đặc biệt là khi có hàng núi hướng dẫn trên web cần xem xét. Tuy nhiên, bằng cách tập trung vào những đề xuất này, bạn có thể tiếp cận vấn đề một cách có trọng tâm và có mục đích, đồng thời hy vọng có thể cải thiện các chỉ số quan trọng chính của trang web.
Mặc dù các đề xuất được nêu ở đây hoàn toàn chưa đầy đủ, nhưng chúng tôi tin rằng (dựa trên phân tích kỹ lưỡng về tình trạng của trang web) rằng những đề xuất này là cách hiệu quả nhất để các trang web có thể cải thiện hiệu suất của Chỉ số quan trọng chính của trang web trong năm 2023.
Nếu bạn không muốn làm nhiều hơn những đề xuất được liệt kê ở đây, hãy xem các hướng dẫn tối ưu hoá sau để biết thêm thông tin:
Xin chào một năm mới và một môi trường web nhanh hơn cho tất cả mọi người! Mong rằng trang web của bạn sẽ hoạt động nhanh đối với người dùng theo mọi cách quan trọng nhất.
Ảnh của Devin Avery