Tập hợp các phương pháp hay nhất mà nhóm Chrome DevRel tin là là những cách hiệu quả nhất để cải thiện hiệu suất của Các chỉ số quan trọng về trang web trong năm 2023.
Trong những năm qua, Google đã đưa ra rất 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ù mỗi đề xuất trong số này, riêng lẻ, có thể giúp cải thiện hiệu suất cho nhiều trang web, nhưng phải thừa nhận rằng một bộ đề xuất đầy đủ là quá nhiều và thực tế, không có cách nào một cá nhân hay trang web có thể tuân theo tất cả các đề xuất này.
Trừ khi hiệu suất web là công việc hằng ngày của bạn, thì có thể bạn sẽ không biết rõ đề xuất nào sẽ có tác động tích cực lớn nhất đến trang web của mình. Ví dụ: bạn có thể đã 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 hoá hình ảnh rất quan trọng. Nhưng nếu không có thời gian để làm cả hai việc, bạn sẽ làm cách nào để quyết định sẽ chọn cách nào?
Trong năm vừa qua, nhóm Chrome, chúng tôi đã cố gắng trả lời câu hỏi sau: những đề xuất quan trọng nhất mà chúng tôi có thể đưa ra cho nhà phát triển để giúp họ cải thiện hiệu suất cho người dùng là gì?
Để trả lời thoả đáng câu hỏi này, chúng tôi không chỉ cân nhắc giá trị kỹ thuật của một đề xuất nhất định, mà còn cả những yếu tố về mặt tổ chức và con người ảnh hưởng đến khả năng nhà phát triển thực sự áp dụng được những đề xuất đó. Nói cách khác, một số đề xuất có thể có tác động mạnh mẽ về mặt lý thuyết nhưng trên thực tế, rất ít trang web có thời gian hoặc nguồn lực để áp dụng những đề xuất này. Tương tự, một số đề xuất cũng rất quan trọng, nhưng hầu hết trang web đã áp dụng những phương pháp này.
Tóm lại, chúng tôi muốn danh sách các đề xuất giúp nâng cao hiệu suất web hàng đầu tập trung vào:
- Những đề xuất mà chúng tôi tin là sẽ có tác động lớn nhất trong thực tế
- Các đề xuất phù hợp và có thể áp dụng cho hầu hết các trang web
- Đề xuất thực tế đối với hầu hết các nhà phát triển nên triển khai
Năm qua, chúng tôi đã dành rất nhiều thời gian để kiểm tra toàn bộ đề xuất về hiệu suất mà chúng tôi đưa ra và đánh giá từng đề xuất (cả về định tính và định lượng) theo ba tiêu chí trên.
Bài đăng này trình bày những đề xuất hàng đầu để cải thiện hiệu suất cho từng chỉ số trong số Các chỉ số quan trọng về trang web. Nếu bạn mới sử dụng hiệu suất trang web hoặc nếu bạn đang cố gắng quyết định xem cách nào sẽ mang lại hiệu quả cao nhất cho bạn, chúng tôi cho rằng các đề xuất này là sự lựa chọn 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 dành cho Thời gian hiển thị nội dung lớn nhất (LCP). Đây là thước đo về hiệu suất tải. Trong 3 chỉ số Các chỉ số quan trọng về trang web, LCP là chỉ số mà nhiều trang web gặp phải nhất – chỉ khoảng một nửa trong số tất cả trang web trên web hiện nay đáp ứng ngưỡng đề xuất. Hãy cùng bắt đầu từ đây.
Đảm bảo tài nguyên LCP có thể phát hiện được từ 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ó phần tử LCP là hình ảnh. Điều này có nghĩa là hầu hết các trang web để tối ưu hoá LCP thì họ cần đảm bảo những hình ảnh đó có thể tải nhanh.
Một điều có thể không rõ ràng đối với nhiều nhà phát triển là thời gian để tải hình ảnh chỉ là một phần trong thách thức đó. Một yếu tố quan trọng khác là thời gian trước khi hình ảnh bắt đầu tải và dữ liệu Lưu trữ HTTP cho thấy đó thực sự là nơi mà nhiều trang web đã gặp sự cố.
Trên thực tế, trong số các trang có phần tử LCP là hình ảnh, 39% trong số các hình ảnh đó có URL nguồn không phát hiện được từ nguồn tài liệu HTML. Nói cách khác, chúng tôi 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 có thể cho phép trình duyệt nhanh chóng tìm thấy các URL này và bắt đầu tải ngay lập tức.
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ý hoàn toàn trước khi hình ảnh có thể bắt đầu tải, điều đó có thể đã quá muộn.
Theo nguyên 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 được từ nguồn HTML. Một số mẹo giúp bạn thực hiện việc này là:
Tải hình ảnh bằng phần tử
<img>có thuộc tínhsrchoặcsrcset. Đừng sử dụng các thuộc tính không chuẩn nhưdata-srcmà yêu cầu phải có JavaScript để hiển thị, vì các thuộc tính đó sẽ luôn chậm hơn. 9% số trang che khuất hình ảnh LCP của trang 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 phần đánh dấu toàn bộ trang (bao gồm cả hình ảnh) có trong nguồn HTML. Giải pháp CSR yêu cầu JavaScript chạy trước khi có thể phát hiện hình ảnh.
Nếu hình ảnh của bạn cần được tham chiếu từ một tệp CSS hoặc JS 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">. Xin lưu ý rằng trình quét tải trước của trình duyệt không thể phát hiện hình ảnh được tham chiếu theo kiểu cùng dòng, vì vậy, mặc dù được tìm thấy trong nguồn HTML, việc khám phá hình ảnh 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 nắm được liệu hình ảnh LCP của bạn có gặp vấn đề về khả năng phát hiện hay không, Lighthouse sẽ phát hành một quy trình 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 từ nguồn HTML có thể dẫn đến những điểm cải tiến có thể đo lường và cũng mở ra các cơ hội khác để ưu tiên tài nguyên. Đâ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ể tìm thấy tài nguyên LCP qua 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, nhưng một bước quan trọng khác là đảm bảo việc tải tài nguyên đó được ưu tiên và không bị xếp hàng sau nhiều 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 có trong nguồn HTML bằng thẻ <img> tiêu chuẩn, nếu trang của bạn có nhiều thẻ <script> trong <head> của tài liệu trước thẻ <img> đó, thì có thể phải mất một lúc tài nguyên hình ảnh mới bắt đầu tải.
Cách dễ nhất để giải quyết vấn đề này là gợi ý cho trình duyệt về những tài nguyên có mức độ ưu tiên cao nhất bằng cách đặt thuộc tính fetchpriority="high" mới vào thẻ <img> hoặc <link> tải hình ảnh LCP của bạn. Thao tác 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% trang đủ điều kiện đang tận dụng API mới này, có nghĩa là hầu hết các trang web trên web đều có rất nhiều cơ hội để cải thiện LCP mà không cần tố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 chỉ bỏ qua. Vì vậy, các nhà phát triển nên sử dụng thuộc tính này ngay bây giờ.
Đố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 đó ở phần trước của tài liệu. Hãy xem 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 rằng tài nguyên LCP của mình được ưu tiên trước 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 bên dưới <img> sau trong <body>. Mặc dù cách này hiệu quả nhưng sẽ ít hiệu quả hơn so với 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 hỗ trợ thêm.
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ứ điều gì khiến tài nguyên đó không được ưu tiên, chẳng hạn như thêm thuộc tính loading="lazy". Ngày nay, 10% số trang thực sự đặt loading="lazy" trên hình ảnh LCP của chúng. Cảnh giác với những 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 các hướng dẫn đó đưa ra cách ghi đè hành vi đó, hãy đảm bảo sử dụng cách đó cho hình ảnh LCP. Nếu bạn không chắc chắn hình ảnh nào sẽ là LCP, hãy thử dùng thông tin 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 hoãn lại một cách an toàn cho đến 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 (chẳng hạn như tài nguyên LCP) về 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 đó! - Tuyệt đối không đặt
loading="lazy"trên thẻ<img>của hình ảnh LCP. Việc này sẽ làm giảm mức độ ưu tiên của hình ảnh và độ trễ khi hình ảnh bắt đầu tải. - Trì hoãn các tài nguyên không quan trọng khi có thể. Bạn có thể di chuyển chúng xuống 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á TTFB tài liệu và tài nguyên
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à ưu tiên để tài nguyên có thể bắt đầu tải ngay lập tức. Phần cuối cùng của câu đố này là đảm bảo nhận được câu trả lời tài liệu ban đầu 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. Trình duyệt càng sớm thì mọi thứ khác cũng có thể bắt đầu càng sớm.
Thời gian này được gọi là Thời gian cho byte đầu tiên (TTFB) và cách tốt nhất để giảm TTFB là:
- Phân phối nội dung của bạn ở vị trí gần địa lý nhất có thể
- Lưu nội dung vào bộ nhớ đệm để nội dung 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 và các máy chủ này đượ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 di chuyển qua dây đến người dùng của bạn. 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ể tuỳ chỉnh và tối ưu hoá theo nhu cầu của trang web.
Nhiều nhà phát triển đã quen với việc sử dụng CDN để lưu trữ tài sản tĩnh, nhưng CDN cũng có thể phân phối 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 có nghĩa là các trang web có cơ hội đáng kể để yêu cầu tiết kiệm thêm.
Sau đây là một số mẹo để định cấu hình CDN:
- Cân nhắc tăng thời lượng lưu vào bộ nhớ đệm (ví dụ: nội dung có thật sự quan trọng hay không? Hoặc video có thể đã lỗi thời vài phút?).
- Bạn thậm chí có thể lưu nội dung vào bộ nhớ đệm vô thời hạn và sau đó xoá hoàn toàn bộ nhớ đệm nếu/khi bạn cập nhật.
- Tìm hiểu 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 cạnh (một tính năng của hầu hết các CDN hiện đại).
Nói chung, bất cứ khi nào bạn có thể phân phát nội dung trực tiếp từ bên cạnh (tránh phải truy cập vào máy chủ gốc), điều đó sẽ mang lại lợi ích về hiệu suất. Và ngay cả trong trường hợp bạn phải phải thực hiện toàn bộ quá trình quay lại máy chủ gốc, CDN thường được tối ưu hóa để thực hiện việc đó nhanh hơn nhiều, vì vậy cách này cũng mang lại lợi ích.
Điểm số tổng hợp về mức thay đổi bố cục (CLS)
Bộ đề xuất tiếp theo dành cho Điểm số tổng hợp về mức thay đổi bố cục (CLS). Đây là thước đo độ ổn định về hình ảnh trên các trang web. Mặc dù CLS đã cải thiện rất nhiều trên web từ năm 2020, nhưng có khoảng 1/4 số trang web vẫn không đáp ứng ngưỡng đề xuất. Do đó, nhiều trang web vẫn còn một 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 đối với 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 khoảng 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 việc thay đổi bố cục do hình ảnh không có kích thước là đặt 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 có 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 và có thể gây ra sự thay đổi đáng kể về bố cục khi hình ảnh cuối cùng được tải và tìm thấy kích thước. Đây là một cơ hội lớn cho web nói chung và 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.
Ngoài ra, 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 Điểm số tổng hợp về mức thay đổi bố cục (CLS). Sự thay đổi về bố cục có thể do những 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 thành phần không phải hình ảnh. Điều 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à yêu cầu trình duyệt tự động tính chiều cao phù hợp, giống như cách trình duyệt thực hiện đố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ì về bản chất, nội dung động là rất linh động. Tuy nhiên, ngay cả khi không biết chính xác kích thướ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 tốt hơn việc cho phép trình duyệt sử dụng chiều cao mặc định là 0px cho một 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. Mức tăng trưởng đó vừa giảm từ mức đầy đủ xuống mức có thể chấp nhận được.
Đảm bảo các trang đủ điều kiện dùng bộ nhớ đệm cho thao tác tiến/lùi
Các 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 đó vào nhật ký duyệt web ngay từ ảnh chụp nhanh bộ nhớ.
Bộ nhớ đệm bfcache là một cách tối ưu hoá hiệu suất quan trọng ở cấp trình duyệt và loại bỏ hoàn toàn sự thay đổi về bố cục trong quá trình tải trang. Đối với nhiều trang web, CLS là nơi diễn ra hầu hết các điểm CLS. Việc ra mắt bfcache đã tạo ra bước cải tiế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 lớn các trang web không đủ điều kiện cho bfcache nên bỏ lỡ cơ hội chiến thắng hiệu suất web miễn phí này cho một số lượng đáng kể các thao tác điều hướng. Bạn nên đảm bảo rằng các trang của mình đủ điều kiện, trừ phi trang đang tải thông tin nhạy cảm mà bạn không muốn được khôi phục từ bộ nhớ.
Chủ sở hữu trang web nên kiểm tra để đảm bảo các trang của họ đủ điều kiện sử dụng bfcache và tìm cách giải quyết vì sao các trang đó không đủ điều kiệ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 cải thiện công cụ tại đây bằng một bài kiểm tra Lighthouse mới thực hiện kiểm tra tương tự và một API để đo lường điều này trong hiện trường.
Mặc dù chúng tôi đã đưa bfcache vào mục CLS, nhưng khi chúng tôi nhận thấy những lợi ích lớn nhất từ trước đến nay, bfcache nhìn chung cũng sẽ cải thiện 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ó thể dùng để cải thiện đáng kể các thao tác điều hướng trang.
Tránh sử dụng các ảnh động/hiệu ứng chuyển đổi sử dụng các thuộc tính CSS tạo ra bố cục
Một nguồn phổ biến khác khiến bố cục thay đổi là khi các phần tử là ảnh động. Ví dụ: các biểu ngữ cookie hoặc các biểu ngữ thông báo khác trượt từ trên cùng hoặc dưới cùng thường là yếu tố góp phần tạo nên CLS. Điều này đặc biệt khó khăn khi những biểu ngữ này chèn nội dung khác sang bên ngoài, nhưng ngay cả khi không xuất hiện, thì việc tạo ảnh động cho chúng vẫn có thể ảnh hưởng đến CLS.
Mặc dù dữ liệu Lưu trữ HTTP không thể kết nối chắc chắn ảnh động với những thay đổi về bố cục, nhưng dữ liệu cho thấy rằng những trang tạo ảnh động bất kỳ thuộc tính CSS nào có thể ảnh hưởng đến bố cục có khả năng có CLS "tốt" thấp hơn 15% so với các trang tổng thể. Một số cơ sở lưu trú có điểm CLS kém hơn các cơ sở lưu trú khác. Ví dụ: những trang hoạt động với chiều rộng margin hoặc border có CLS "kém" với tốc độ gần gấp đôi tốc độ mà các trang tổng thể bị đánh giá là kém.
Điều này có lẽ không đáng ngạc nhiên 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 thay đổi về bố cục. Nếu những thay đổi về bố cục đó không trong vòng 500 mili giây tính từ lúc người dùng tương tác thì chúng sẽ ảnh hưởng đến CLS.
Một số nhà phát triển có thể ngạc nhiên vì điều này vẫn đúng ngay cả trong trường hợp phần tử được lấy ngoài quy trình 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ẽ làm thay đổi bố cục, ngay cả khi các phần tử này không đẩy nội dung khác. Tuy nhiên, nếu thay vì tạo ảnh động cho top hoặc left, bạn sẽ tạo ảnh động cho 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 làm thay đổi bố cục.
Việc ưu tiên ảnh động của các thuộc tính CSS mà có thể được cập nhật trên chuỗi 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ì nó di chuyển hoạt động trên GPU và ra khỏ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, tính năng này còn có thể giúp cải thiện CLS.
Theo quy tắc chung, bạn không được tạo ảnh động hoặc chuyển đổi cho bất kỳ thuộc tính CSS nào mà 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 khi người dùng nhấn hoặc nhấn phím (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 CSS transform.
Bài kiểm tra Lighthouse Tránh các ảnh động không được kết 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 dành cho Thời gian phản hồi lần tương tác đầu tiên (FID). Đây là chỉ số đo lường khả năng thích ứng của trang đối với hoạt động 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 về FID, nhưng chúng tôi đã ghi lại những thiếu sót của chỉ số FID trong quá khứ và chúng tôi tin rằng các trang web vẫn còn nhiều cơ hội để cải thiện khả năng phản hồi tổng thể đối với các 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ó thể kế thừa FID và tất cả đề xuất dưới đây đều áp dụng như nhau cho cả FID và INP. Do các trang web hoạt động kém hơn trên INP so với FID, đặc biệt là trên thiết bị di động, chúng tôi khuyến khích 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ù có FID "tốt".
Tránh hoặc chia nhỏ các tác vụ dài
Tác vụ là bất kỳ phần công việc riêng biệt nào mà 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 các 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 hoạt động đầu vào của người dùng.
Theo Web Almanac, có nhiều bằng chứng cho thấy nhà phát triển có thể làm được nhiều việc hơn để tránh hoặc chia nhỏ các nhiệm vụ dài. Mặc dù việc chia nhỏ các nhiệm vụ dài có thể không tốn nhiều công sức như những đề xuất khác trong bài viết này, nhưng lại tốn ít công sức hơn so với những kỹ thuật khác không được đề cập trong bài viết này.
Mặc dù bạn luôn phải cố gắng thực hiện ít tác vụ nhất có thể trong JavaScript, nhưng bạn cũng có thể giúp luồng chính một chút bằng cách chia tác vụ dài thành những tác vụ nhỏ hơn. Bạn có thể thực hiện việc này bằng cách nhường cho luồng chính thường xuyên để quá trình 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à API Bộ lập lịch. isInputPending là một hàm trả về một giá trị boolean cho biết hoạt động đầu vào của người dùng có đang chờ xử lý hay không. Nếu trả về true, bạn có thể chuyển đến luồng chính để luồng này có thể 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 công việc đang được thực hiện mà người dùng có thể nhìn thấy hay chạy ở chế độ nền.
Bằng cách chia nhỏ các tác vụ dài, bạn đang mang lại cho trình duyệt nhiều cơ hội hơn để xử lý các 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 lượt tương tác và bất kỳ cập nhật kết xuất nào.
Tránh JavaScript không cần thiết
Không còn nghi ngờ gì nữa về điều đó: các trang web đang vận chuyển JavaScript nhiều hơn bao giờ hết và xu hướng này có vẻ như sẽ không thay đổi sớm. Khi bạn gửi quá nhiều JavaScript, bạn đang tạo một môi trường mà các tác vụ đang cạnh tranh để được chú ý trong luồng chính. Điều này chắc chắn có thể ảnh hưởng đến khả năng thích ứng 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à vấn đề không thể giải quyết. Bạn có một số lựa chọn:
- Sử dụng công cụ mức độ phù hợp trong Công cụ của Chrome cho nhà phát triển để tìm đoạn 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 tốn ít thời gian hơn để phân tích cú pháp và biên dịch mã, nhờ đó mang đến trải nghiệm ban đầu suôn sẻ hơn cho người dùng.
- Đôi khi, mã không dùng đến mà bạn thấy khi sử dụng công cụ mức độ sử dụng được đánh dấu là "không sử dụng" vì mã này 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 bằng tính năng chia tách mã.
- Nếu bạn đang sử dụng trình quản lý thẻ, hãy nhớ kiểm tra thẻ của bạn định kỳ để đả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ể xoá các thẻ cũ có mã không được 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à thứ duy nhất có thể ảnh hưởng đến khả năng thích ứng của trang web. Hiển thị có thể là một loại công việc tiêu tốn nhiều tài nguyên — và khi các thay đổi lớn về kết xuất diễn ra, chúng có thể ảnh hưởng đến khả năng trang web phản hồi hoạt động đầu vào của người dùng.
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, mà thường phụ thuộc vào những gì 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 rằng các cập nhật kết xuất của bạn 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 những tác vụ không phải hình ảnh. Các lệnh gọirequestAnimationFrame()được xử lý trong giai đoạn hiển thị của vòng lặp sự kiện. Và khi có quá nhiều thao tác được thực hiện trong bước này, quá trình kết xuất thông tin cập nhật có thể bị trì hoãn. Mọi công việc bạn đang thực hiện vớirequestAnimationFrame()đều được dành riêng cho các tác vụ liên quan đến việc hiển thị bản cập nhật. - Giữ kích thước DOM nhỏ. Kích thước DOM và cường độ làm việc về 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, công việc cần thiết để tính toán lại bố cục có thể tăng lên đáng kể.
- Sử dụng vùng chứa CSS. Tính năng vùng chứa CSS dựa vào thuộc tính
containcủa CSS. Thuộc tính này đưa ra hướng dẫn cho trình duyệt về cách bố cục của vùng chứa mà thuộc tínhcontainđã đặt, bao gồm cả việc tách biệt phạm vi bố cục và hiển thị đến một thư mục gốc cụ thể trong DOM. Quá trình này không phải lúc nào cũng dễ dàng. Tuy nhiên, bạn có thể tách biệt các khu vực có chứa bố cục phức tạp để tránh thực hiện những thao tác bố cục và kết xuất không cần thiết cho những khu vực đó.
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 khi có rất nhiều hướng dẫn trên web cần xem xét. Tuy nhiên, nếu tập trung vào những đề xuất này, bạn có thể giải quyết vấn đề một cách tập trung và có mục đích cụ thể. Hy vọng rằng các chỉ số quan trọng về trang web sẽ trở thành kim chỉ nam cho trang web của bạn.
Mặc dù các đề xuất được nêu ở đây chắc chắn chưa đầy đủ, nhưng chúng tôi tin (dựa trên phân tích kỹ lưỡng về trạng thái web) rằng các đề 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 Các chỉ số quan trọng về trang web trong năm 2023.
Nếu bạn muốn biết thêm thông tin ngoài những đề xuất được liệt kê tại đây, hãy xem những hướng dẫn tối ưu hoá sau để biết thêm thông tin:
Chào đón năm mới và một Internet tốc độ cao hơn cho tất cả mọi người! Giúp trang web của bạn hoạt động nhanh cho người dùng theo mọi cách quan trọng nhất.
Ảnh của Devin Avery