Những cách hiệu quả nhất để cải thiện Chỉ số quan trọng chính của trang web

Qua nhiều năm, cộng đồng web đã tích luỹ được nhiều kiến thức về việc tối ưu hoá hiệu suất web. Mặc dù một phương pháp tối ưu hoá có thể cải thiện hiệu suất cho nhiều trang web, nhưng việc áp dụng tất cả các phương pháp cùng một lúc có thể khiến bạn cảm thấy choáng ngợp. Thực tế là chỉ một số phương pháp mới có thể áp dụng cho một trang web cụ thể.

Trừ phi bạn làm việc chuyên về hiệu suất web, có thể bạn sẽ không biết rõ những biện pháp tối ưu hoá nào sẽ tác động nhiều nhất đến trang web của mình. Bạn có thể sẽ không có thời gian để tập trung vào tất cả các tính năng này. Vì vậy, hãy tự hỏi những phương pháp tối ưu hoá có tác động mạnh mẽ nhất mà bạn có thể chọn để cải thiện hiệu suất cho người dùng là gì?

Sau đây là sự thật về việc tối ưu hoá hiệu suất: bạn không thể chỉ đánh giá các biện pháp tối ưu hoá dựa trên giá trị kỹ thuật của chúng. Bạn cũng cần xem xét các yếu tố con người và tổ chức ảnh hưởng đến khả năng bạn có thể triển khai bất kỳ phương pháp tối ưu hoá nào. Một số biện pháp cải thiện hiệu suất có thể mang lại tác động rất lớn về mặt lý thuyết, nhưng trên thực tế, ít nhà phát triển có thời gian hoặc tài nguyên để triển khai các biện pháp đó. Mặt khác, có thể có những phương pháp hay nhất giúp nâng cao hiệu suất cực kỳ hiệu quả mà mọi người đang áp dụng. Hướng dẫn này xác định các phương pháp tối ưu hoá hiệu suất web:

  • Có tác động lớn nhất ngoài đời thực
  • Phù hợp và có thể áp dụng cho hầu hết các trang web
  • Tính thực tế đối với hầu hết các nhà phát triển khi triển khai

Nhìn chung, đây là những cách thực tế và có tác động nhất để bạn cải thiện các chỉ số Chỉ số quan trọng chính của trang web. Nếu bạn mới làm quen với hiệu suất web hoặc nếu bạn vẫn đang quyết định xem yếu tố nào sẽ mang lại lợi tức đầu tư lớn nhất, thì đây là nơi tốt nhất để bắt đầu.

Lượt tương tác đến nội dung hiển thị tiếp theo (INP)

Là chỉ số mới nhất trong Chỉ số quan trọng chính của trang web, Lượt tương tác đến nội dung hiển thị tiếp theo (INP) có một số cơ hội cải thiện lớn nhất. Tuy nhiên, vì có ít trang web vượt qua ngưỡng để có trải nghiệm "tốt" hơn so với tiền thân không còn được dùng nữa, nên có thể bạn là một trong số nhiều nhà phát triển lần đầu tiên tìm hiểu cách tối ưu hoá khả năng phản hồi tương tác. Hãy bắt đầu bằng những kỹ thuật cần biết này để biết cách hiệu quả nhất để cải thiện INP.

1. Hiệu suất thường xuyên để chia nhỏ các công việc dài

Tác vụ là bất kỳ công việc riêng biệt nào mà trình duyệt thực hiện, bao gồm cả việc hiển thị, bố cục, phân tích cú pháp, biên dịch hoặc thực thi tập lệnh. Khi thời lượng của một tác vụ vượt quá 50 mili giây, tác vụ đó sẽ trở thành tác vụ dài. Các tác vụ dài gây ra vấn đề vì chúng có thể chặn luồng chính phản hồi nhanh các hoạt động tương tác của người dùng.

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 bằng cách chia nhỏ các tác vụ dài. Bạn có thể thực hiện việc này bằng cách thường xuyên chuyển đến luồng chính để 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 sớm hơn.

Hỗ trợ trình duyệt

  • Chrome: 129.
  • Cạnh: 129.
  • Firefox: không được hỗ trợ.
  • Safari: không được hỗ trợ.

Nguồn

Scheduler API cho phép bạn xếp hàng công việc bằng cách sử dụng hệ thống ưu tiên. Cụ thể, API scheduler.yield() chia nhỏ các công việc dài trong khi vẫn đảm bảo có thể xử lý các hoạt động tương tác mà không bị từ bỏ vị trí của chúng trong hàng đợi tác vụ.

Bằng cách chia nhỏ các tác vụ dài, bạn đang tạo cơ hội cho trình duyệt thực hiện các tác vụ quan trọng, chặn người dùng.

2. Tránh sử dụng JavaScript không cần thiết

Các trang web đang gửi nhiều JavaScript hơn bao giờ hết và xu hướng này có vẻ như không 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 có thể ảnh hưởng đến khả năng phản hồi của trang web, đặc biệt là trong khoảng thời gian khởi động quan trọng đó.

Tuy nhiên, đây không phải là vấn đề không thể giải quyết được và bạn có các lựa chọn sau:

  • Sử dụng các tính năng Cơ sở của nền tảng web có sẵn rộng rãi thay vì các phương thức triển khai thừa dựa trên JavaScript.
  • Sử dụng công cụ che phủ trong Công cụ của Chrome cho nhà phát triển để tìm mã không dùng đến trong tập lệnh của bạn. 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 rằng các trang 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 người dùng ban đầu mượt mà hơn.
  • Sử dụng tính năng phân tách mã để tạo một gói riêng cho mã không cần thiết cho quá trình kết xuất ban đầu nhưng vẫn sẽ được sử dụng sau này.
  • Nếu bạn đang sử dụng trình quản lý thẻ, hãy định kỳ tối ưu hoá thẻ. Bạn có thể xoá các thẻ cũ có mã không dùng đến để giảm mức sử dụng JavaScript của trình quản lý thẻ.

3. Tránh các bản cập nhật kết xuất lớn

Thực thi JavaScript chỉ là một yếu tố ảnh hưởng đến khả năng phản hồi của trang web. Việc kết xuất là một loại công việc tốn kém và trong quá trình cập nhật kết xuất lớn, trang web của bạn có thể phản hồi các hoạt động tương tác của người dùng chậm hơn nữa.

Quá trình tối ưu hoá công việc kết xuất không đơn giản và phụ thuộc vào mục tiêu bạn đang cố gắng đạt được. Tuy nhiên, sau đây là một số việc bạn có thể làm để đảm bảo rằng các tác vụ kết xuất không trở thành tác vụ dài:

  • Sắp xếp lại các hoạt động đọc và ghi DOM trong mã JavaScript để tránh bố cục bắt buộcbố cục bị xáo trộn.
  • Giữ 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, công việc cần thiết để tính toán lại bố cục của trình kết xuất có thể tăng lên đáng kể.
  • Sử dụng tính năng chứa CSS để hiển thị từng phần nội dung DOM ngoài màn hình. Việc này không phải lúc nào cũng đơn giản, 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 được công việc bố cục và kết xuất không cần thiết.

Thời gian hiển thị nội dung lớn nhất (LCP)

Nội dung lớn nhất hiển thị (LCP) là Chỉ số quan trọng chính của trang web mà nhà phát triển thường gặp khó khăn khi gặp phải nhiều vấn đề nhất – 40% trang web trong Báo cáo trải nghiệm người dùng của Chrome không đáp ứng ngưỡng LCP được đề xuất để mang lại trải nghiệm tốt cho người dùng. Nhóm Chrome đề xuất các kỹ thuật sau đây là những cách hiệu quả nhất để cải thiện LCP.

1. Đảm bảo tài nguyên LCP có thể được phát hiện từ nguồn HTML và được ưu tiên

Nhóm Chrome đã nhận thấy những điều sau đây liên quan đến LCP trên web:

  • Theo Almanac Web 2022 của Lưu trữ HTTP, 72% trang dành cho thiết bị di động có hình ảnh làm phần tử LCP.
  • Phân tích dữ liệu người dùng thực tế từ Chrome cho thấy rằng phần lớn các nguồn gốc có LCP kém dành dưới 10% thời gian LCP p75 để tải hình ảnh LCP xuống.
  • Trong số các trang có LCP kém, việc tải hình ảnh LCP bị trễ trên máy khách 1.290 mili giây ở phân vị thứ 75 – tức là hơn một nửa ngân sách để có trải nghiệm nhanh.
  • Trong số các trang mà phần tử LCP là hình ảnh, 39% trong số các hình ảnh đó có URL nguồn không thể tìm thấy trong phản hồi HTML ban đầu (chẳng hạn như <img src="..."> hoặc <link rel="preload" href="...">). Điều này sẽ cho phép trình quét tải trước của trình duyệt phát hiện các URL này sớm nhất có thể.
  • Theo Web Almanac, chỉ 0,03% số trang đủ điều kiện mới tận dụng thuộc tính HTML fetchpriority để ưu tiên cao hơn cho các tài nguyên, bao gồm cả những tài nguyên có thể cải thiện LCP của trang mà không tốn nhiều công sức.

Những số liệu thống kê này cho thấy rằng các nhà phát triển có một cơ hội lớn để giảm cả độ trễ tải tài nguyênthời lượng tải tài nguyên cho hình ảnh LCP.

Hỗ trợ trình duyệt

  • Chrome: 102.
  • Edge: 102.
  • Firefox: 132.
  • Safari: 17.2.

Nguồn

Trong trường hợp độ trễ tải tài nguyên là vấn đề, bạn cần nhớ rằng có thể đã quá muộn để đạt được LCP tốt nếu một trang cần phải đợi CSS hoặc JavaScript được tải đầy đủ trước khi hình ảnh có thể bắt đầu tải. Ngoài ra, bạn có thể giảm thời lượng tải tài nguyên của hình ảnh LCP bằng cách ưu tiên lại hình ảnh đó để hình ảnh nhận được nhiều băng thông hơn và do đó tải nhanh hơn bằng cách sử dụng thuộc tính HTML fetchpriority.

Nếu phần tử LCP của bạn là hình ảnh, thì URL của hình ảnh phải được phát hiện trong phản hồi HTML để giảm độ trễ tải tài nguyên. Sau đây là một số mẹo giúp bạn làm được điều đó:

  • Tải hình ảnh bằng phần tử <img> có thuộc tính src hoặc srcset. Đừng sử dụng các thuộc tính không chuẩn như data-src yêu cầu JavaScript để hiển thị, vì việc này 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 sau data-src.
  • Ưu tiên kết xuất phía máy chủ (SSR) hơn kết xuất phía máy khách (CSR), vì SSR ngụ ý rằng toàn bộ mã đánh dấu trang (bao gồm cả hình ảnh) đều 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 cần tham chiếu hình ảnh 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 bằng 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 bằng các kiểu nội tuyến. Vì vậy, mặc dù hình ảnh được tìm thấy trong nguồn HTML, nhưng việc phát hiện hình ảnh vẫn có thể bị chặn khi tải các tài nguyên khác. Do đó, tính năng tải trước có thể hữu ích trong những trường hợp này.

Ngoài ra, bạn có thể rút ngắn thời gian tải của tài nguyên bằng cách đảm bảo rằng tài nguyên LCP được tải sớm và ở mức độ ưu tiên cao:

  • Thêm thuộc tính fetchpriority="high" vào thẻ <img> hoặc <link rel="preload"> của hình ảnh LCP. Điều này làm tăng mức độ ưu tiên của tài nguyên hình ảnh để tài nguyên này có thể bắt đầu tải sớm hơn.
  • Xoá thuộc tính loading="lazy" khỏi thẻ <img> của hình ảnh LCP. Điều này giúp tránh tình trạng chậm tải do xác nhận rằng hình ảnh xuất hiện trong hoặc gần khung nhìn.
  • Trì hoãn các tài nguyên không quan trọng khi có thể. Việc di chuyển các tài nguyên này đến cuối tài liệu của bạn, hình ảnh tải từng phần hoặc iframe hoặc tải chúng không đồng bộ bằng JavaScript sẽ giúp dọn đường cho các tài nguyên quan trọng hơn như hình ảnh LCP tải nhanh hơn.

2. Nhắm đến điều hướng tức thì

Trải nghiệm người dùng lý tưởng là không bao giờ phải đợi trang tải. Các phương pháp tối ưu hoá LCP như khả năng phát hiện và ưu tiên tài nguyên có hiệu quả trong việc giảm thời gian người dùng chờ tải và hiển thị phần tử LCP. Tuy nhiên, có một giới hạn vật lý về tốc độ tải và hiển thị các byte đó trên mạng. Trước khi bạn đạt đến giới hạn đó, bạn cần phải nỗ lực rất nhiều để chỉ giảm được vài mili giây. Vì vậy, để đạt được tính năng điều hướng tức thì, chúng ta cần sử dụng một phương pháp hoàn toàn khác.

Tính năng điều hướng tức thì cố gắng tải và hiển thị trang trước khi người dùng bắt đầu chuyển đến đó. Bằng cách này, trang được kết xuất trước có thể hiển thị ngay lập tức với LCP gần bằng 0. Khôi phục và suy đoán là hai cách để thực hiện việc này. Khi người dùng quay lại hoặc tiến tới một trang đã truy cập trước đó, trang này có thể được khôi phục nhanh chóng từ bộ nhớ đệm của bộ nhớ và xuất hiện chính xác như người dùng đã thoát. Ngoài ra, các ứng dụng web có thể cố gắng dự đoán nơi người dùng sẽ chuyển đến tiếp theo. Khi dự đoán chính xác, trang tiếp theo sẽ được tải và hiển thị trước khi người dùng chuyển đến đó.

Bạn có thể khôi phục các trang đã truy cập trước đó bằng bộ nhớ đệm cho thao tác tiến/lùi (bfcache). Để sử dụng tính năng này, bạn phải đảm bảo rằng các trang của mình đáp ứng các tiêu chí sử dụng bfcache. Có một số lý do phổ biến khiến các trang không đủ điều kiện sử dụng bfcache, chẳng hạn như các trang được phân phát bằng lệnh lưu vào bộ nhớ đệm no-store hoặc có trình nghe sự kiện unload.

Việc khôi phục các trang được kết xuất đầy đủ không chỉ cải thiện hiệu suất tải mà còn cải thiện độ ổn định của bố cục. Bạn có thể tìm hiểu thêm về bfcache và mức độ hiệu quả của bfcache trong việc cải thiện CLS trong phần Đảm bảo các trang đủ điều kiện sử dụng bfcache.

Hỗ trợ trình duyệt

  • Chrome: 109.
  • Edge: 109.
  • Firefox: không được hỗ trợ.
  • Safari: không được hỗ trợ.

Việc kết xuất trước trang tiếp theo mà người dùng truy cập là một cách hiệu quả khác để cải thiện đáng kể hiệu suất LCP. Bạn có thể thực hiện việc này thông qua API Quy tắc dự đoán. Tuy nhiên, để đạt được những lợi ích này, hãy đảm bảo rằng các trang chính xác được kết xuất trước. Thông tin suy đoán không chính xác sẽ lãng phí tài nguyên trên cả máy chủ và máy khách, điều này có thể làm giảm hiệu suất. Vì vậy, bạn càng ít tự tin về trang tiếp theo thì bạn càng phải thận trọng hơn khi kết xuất trước trang đó. Nếu nghi ngờ, dữ liệu phân tích có thể giúp bạn tự tin kết xuất trước các trang một cách háo hức với xác suất được truy cập tiếp theo cao nhất.

3. Sử dụng CDN để tối ưu hoá TTFB

Đề xuất trước đây tập trung vào các thao tác điều hướng tức thì, nhằm mang lại trải nghiệm tốt nhất có thể cho người dùng, nhưng có thể có một số trường hợp không thể áp dụng kỹ thuật bfcache và tải theo suy đoán. Hãy xem xét việc người dùng đi theo một đường liên kết nhiều nguồn gốc đến trang web của bạn, nơi phản hồi ban đầu của tài liệu HTML có thể chặn LCP một cách hiệu quả. 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. Quá trình này càng diễn ra sớm thì mọi thứ khác càng có thể bắt đầu sớm.

Khoảng thời gian này được gọi là Thời gian cho byte đầu tiên (TTFB). 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 với người dùng nhất có thể.
  • Lưu nội dung đó vào bộ nhớ đệm để có thể phân phát nhanh chóng nếu nội dung đó được yêu cầu lại trong tương lai gần.

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ủ biên trên toàn cầu, nhờ đó giới hạn khoảng cách mà các tài nguyên đó phải di chuyể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ề bộ nhớ đệm có thể được điều chỉnh cho phù hợp với nhu cầu của trang web.

CDN cũng có thể phân phát và lưu tài liệu HTML vào bộ nhớ đệm, nhưng theo Web Almanac, chỉ 29% yêu cầu tài liệu HTML được phân phát từ CDN. Điều đó có nghĩa là các trang web có cơ hội đáng kể để tiết kiệm thêm.

Sau đây là một số mẹo để định cấu hình CDN:

  • Lưu tài liệu HTML tĩnh vào bộ nhớ đệm ngay cả trong một thời gian ngắn. Ví dụ: Nội dung phải luôn mới mẻ có quan trọng không? Hoặc nó có thể cũ vài phút không?
  • Hãy tìm hiểu xem bạn có thể di chuyển logic động đang chạy trên máy chủ gốc sang cạnh hay không. Đây là một tính năng của hầu hết các CDN hiện đại.

Bất cứ lúc nào bạn có thể phân phát nội dung trực tiếp từ các ứng dụng biên và tránh bị chuyển tới máy chủ gốc của mình đều mang lại hiệu suất cao. Ngay cả trong trường hợp bạn phải phải di chuyển đến tận nguồn gốc, CDN thường được tối ưu hoá để làm việc đó nhanh hơn, 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)

Điểm số tổng hợp về mức thay đổi bố cục (CLS) là chỉ số đo lường độ ổn định của hình ảnh của một trang web. Mặc dù CLS là chỉ số mà hầu hết các trang web đều có xu hướng đạt điểm cao, nhưng khoảng một phần tư trong số đó vẫn không đáp ứng ngưỡng đề xuất. Vì vậy, nhiều trang web vẫn có cơ hội lớn để cải thiện trải nghiệm người dùng.

1. Đặt kích thước rõ ràng cho mọi nội dung được tải từ trang

Sự thay đổi bố cục thường xảy ra khi nội dung hiện tại di chuyển sau khi nội dung khác tải xong. Cách chính để cải thiện CLS là đặt trước không gian cần thiết càng nhiều càng tốt.

Cách tốt nhất để khắc phục sự cố dịch chuyển bố cục do hình ảnh không có kích thước gây ra là thiết lập rõ ràng các thuộc tính widthheight hoặc các thuộc tính CSS tương đương. 72% số trang có ít nhất một hình ảnh chưa được định cỡ. Nếu không có kích thước rõ ràng, những hình ảnh này sẽ có chiều cao ban đầu là 0px. Điều này có thể khiến bố cục thay đổi khi những hình ảnh này tải và trình duyệt khám phá kích thước của chúng. Điều này mang đến một cơ hội rất lớn cho web tập thể và cơ hội đó đòi hỏi ít nỗ lực hơn so với một số đề xuất khác được đề xuất trong hướng dẫn này.

Hỗ trợ trình duyệt

  • Chrome: 88.
  • Edge: 88.
  • Firefox: 89.
  • Safari: 15.

Nguồn

Hình ảnh không phải là yếu tố duy nhất đóng góp vào CLS. Sự thay đổi bố cục có thể là do nội dung khác thường tải sau khi trang hiển thị ban đầ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 ích cho bạn trong trường hợp này. Đây là một tính năng CSS được cung cấp rộng rãi trên cơ sở, cho phép nhà phát triển đặt tỷ lệ khung hình rõ ràng cho cả hình ảnh lẫn các phần tử không phải hình ảnh. Điều này 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 thực hiện đối với hình ảnh có kích thước.

Tuy nhiên, không phải lúc nào cũng có thể biết kích thước chính xác của nội dung động. Ngay cả khi không biết kích thước chính xác, bạn vẫn có thể 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 so với 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à một cách khắc phục đơn giản, vì nó vẫn cho phép vùng chứa phát triển đến chiều cao của nội dung cuối cùng nếu cần – nó chỉ làm giảm mức tăng đó xuống một mức có thể chấp nhận được hơn.

2. Đảm bảo trang đủ điều kiện sử dụng bfcache

Như đã đề cập trước đó trong hướng dẫn này, bộ nhớ đệm cho thao tác tiến/lùi (bfcache) tải ngay lập tức một trang ở trước đó hoặc ở phần sau đó trong nhật ký duyệt web từ ảnh chụp nhanh bộ nhớ. Mặc dù bfcache là một tính năng tối ưu hoá hiệu suất đáng kể ở cấp trình duyệt giúp cải thiện LCP, nhưng tính năng này cũng loại bỏ hoàn toàn sự thay đổi bố cục. Trên thực tế, việc ra mắt bfcache vào năm 2022 đã giúp cải thiện đáng kể CLS mà chúng tôi thấy được trong năm đó.

Tuy nhiên, một số lượng đáng kể trang web không đủ điều kiện sử dụng bfcache, do đó, bỏ lỡ cơ hội cải thiện hiệu suất web miễn phí này. Trừ phi trang của bạn đang tải thông tin nhạy cảm mà bạn không muốn khôi phục từ bộ nhớ, hãy đảm bảo rằng các trang của bạn đủ điều kiện sử dụng bfcache.

Chủ sở hữu trang web nên kiểm tra xem các trang có đủ điều kiện sử dụng bfcache hay không và khắc phục mọi lý do khiến các trang đó không đủ điều kiện. Chrome có trình kiểm tra bfcache trong DevTools và bạn cũng có thể sử dụng API Lý do không khôi phục để phát hiện lý do không đủ điều kiện trong trường này.

3. Tránh sử dụng ảnh động và hiệu ứng chuyển đổi sử dụng các thuộc tính CSS gây ra bố cục

Một nguyên nhâ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 hiệu ứng ả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 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 các cơ sở lưu trú khác. Ví dụ: các trang tạo ảnh động có chiều rộng margin hoặc border có CLS "kém" ở mức gần gấp đôi tỷ lệ mà các trang tổng thể được đánh giá là kém.

Điều này có lẽ không có gì đá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 bố cục. Nếu những thay đổi về bố cục đó không xảy ra trong vòng 500 mili giây kể từ 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 có thể gây ngạc nhiên cho một số nhà phát triển là điều này đúng ngay cả trong trường hợp phần tử được lấy ra ngoài luồng tài liệu thông thường. Ví dụ: các phần tử được định vị tuyệt đối tạo ảnh động top hoặc left sẽ gây ra sự thay đổi bố cục, ngay cả khi các phần tử đó không đẩy nội dung khác xung quanh. Tuy nhiên, nếu thay vì tạo ảnh động top hoặc left, bạn tạo ảnh động transform:translateX() hoặc transform:translateY(), thì trình duyệt sẽ không cập nhật bố cục trang, do đó tránh được việc thay đổi bố cục.

Việc ưu tiên ảnh động của các thuộc tính CSS có thể được cập nhật trên luồng trình kết 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 công việc đó ra khỏi luồng chính sang GPU. Ngoài việc là một phương pháp hay nhất về hiệu suất chung, việc này cũng có thể giúp cải thiện CLS.

Theo nguyên tắc chung, đừng bao giờ tạo ảnh động hoặc chuyển đổi các thuộc tính CSS yêu cầu trình duyệt cập nhật bố cục trang, trừ phi bạn đang 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). Bất cứ khi nào có thể, hãy ưu tiên sử dụng hiệu ứng 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 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.

Kết luận

Việc cải thiện hiệu suất trang có vẻ như rất khó khăn, đặc biệt là khi có hàng núi hướng dẫn trên web để bạn cân nhắc. Tuy nhiên, bằng cách tập trung vào danh sách ngắn gồm các phương pháp hay nhất và hiệu quả nhất này, bạn có thể tiếp cận vấn đề với một tâm thế mới mẻ và hy vọng cải thiện Chỉ số quan trọng chính của trang web.

Nếu bạn muốn tìm hiểu thêm các phương pháp tối ưu hoá ngoài những phương pháp được liệt kê ở đây, hãy đọc các hướng dẫn sau để biết thêm thông tin:

Phụ lục: Nhật ký thay đổi

Các thay đổi lớn đối với tài liệu này sẽ được theo dõi tại đây để giúp giải thích thời điểm và lý do các đề xuất hàng đầu thay đổi.

Tháng 10/2024

Nội dung cập nhật năm 2024:

  • INP
    • Chúng tôi đã chuyển đổi chỉ số này từ FID sang INP theo sự ra mắt của INP dưới dạng chỉ số Core Web Vital và đặt chỉ số này làm chỉ số hàng đầu trong danh sách.
    • Chúng tôi đã huỷ bỏ đề xuất sử dụng API isInputPending như một phần của việc chia nhỏ các tác vụ dài. Bạn có thể tìm hiểu thêm về lý do của chúng tôi trong bài viết Tối ưu hoá các tác vụ dài.
  • LCP
    • Chúng tôi đã kết hợp các đề xuất về khả năng được tìm thấy và mức độ ưu tiên thành một đề xuất.
    • Chúng tôi đã thêm một đề xuất mới để điều hướng tức thì.

Tháng 1 năm 2023

Dưới đây là danh sách các đề xuất ban đầu:

  • LCP
    • Đảm bảo tài nguyên LCP có thể được phát hiện từ nguồn HTML
    • Đảm bảo tài nguyên LCP được ưu tiên
    • Sử dụng CDN để tối ưu hoá TTFB của tài liệu và tài nguyên
  • CLS (Mức thay đổi bố cục tích luỹ)
    • Đặt kích thước rõ ràng cho mọi nội dung được tải từ trang
    • Đảm bảo các trang đủ điều kiện dùng bfcache
    • Tránh các ảnh động và hiệu ứng chuyển tiếp sử dụng thuộc tính CSS tạo bố cục
  • FID
    • Tránh hoặc chia nhỏ các tác vụ dài
    • Tránh JavaScript không cần thiết
    • Tránh các bản cập nhật kết xuất lớn

Bạn cũng có thể xem bản trình bày tại Google I/O năm 2023 để xem bản tóm tắt video.