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 để thực hiện tất cả các phương pháp này. Vì vậy, điều quan trọng là bạn phải tự hỏi những phương pháp tối ưu hoá nào có tác động lớn nhất mà bạn có thể chọn để cải thiện hiệu suất cho người dùng?
Đâ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 về hiệu suất có tác động rất lớn mà hầu hết mọi người đều đ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 trong thực tế
- Phù hợp và áp dụng được cho hầu hết các trang web
- Thực tế đối với hầu hết các nhà phát triển để 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. Thường xuyên trả về để chia nhỏ các tác vụ 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ì 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 luôn phải cố gắng làm ít việ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 nhường quyền cho luồng chính để cập nhật kết xuấ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.
API Trình lập lịch biểu 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 các tác vụ dài thành nhiều phần, đồng thời đảm bảo có thể xử lý các lượt tương tác mà không cần 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 thêm cơ hội để trình duyệt thực hiện công việc 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 đang tạo ra một môi trường mà các tác vụ đang cạnh tranh để thu hút 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 và bạn có thể làm như 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 dư thừa dựa trên JavaScript.
- Sử dụng công cụ đo lường mức độ sử dụng trong Chrome DevTools để tìm mã không dùng đến trong tập lệnh. Bằng cách giảm kích thước của cá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 sẽ dành í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
Việc thực thi JavaScript chỉ là một yếu tố ảnh hưởng đến khả năng thích ứng 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.
Việc tối ưu hoá công việc kết xuất không phải là một quy trình đơ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ộc và bố cục bị xáo trộn.
- Giữ kích thước DOM nhỏ. Kích thước DOM và cường độ công việc bố cục có mối tương quan. 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à các nhà phát triển thường gặp khó khă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 2024 của HTTP Archive, 73% 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 có thành phần LCP là hình ảnh, 35% hình ảnh đó có URL nguồn không thể phát hiện được 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 đó sớm nhất có thể. - Theo Web Almanac, 15% số trang đủ điều kiện đang 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 nhà phát triển có cơ hội lớn để giảm cả độ trễ khi tải tài nguyên và thời lượng tải tài nguyên cho hình ảnh LCP.
Khi vấn đề là độ trễ tải tài nguyên, điều quan trọng là bạn phải nhớ có thể đã quá muộn để đạt được LCP tốt nếu một trang cần đợi CSS hoặc JavaScript tải xong 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ínhsrc
hoặcsrcset
. Đừ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. 7% số trang che khuất hình ảnh LCP của mình saudata-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 thì mới có thể phát hiện 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 một 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. Việc này làm tăng mức độ ưu tiên của tài nguyên hình ảnh để tài nguyên đó 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 xuống cuối tài liệu, tải hình ảnh theo kiểu tải lười hoặc iframe hoặc tải các tài nguyên đó không đồng bộ bằng JavaScript sẽ giúp các tài nguyên quan trọng hơn như hình ảnh LCP tải nhanh hơn.
2. Hướng đến việc đ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 biện pháp tối ưu hoá LCP như khả năng khám phá và ưu tiên tài nguyên giúp giảm thời gian người dùng chờ phần tử LCP tải và hiển thị. Tuy nhiên, có một giới hạn vật lý về tốc độ tải các byte đó qua mạng và hiển thị trên trang. 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.
Thao tác đ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 điều hướng đế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. Có hai cách để thực hiện việc này là khôi phục và suy đoán. Khi người dùng quay lại hoặc chuyển đến một trang đã truy cập trước đó, trang đó có thể được khôi phục nhanh chóng từ bộ nhớ đệm trong bộ nhớ, xuất hiện giống hệt như khi người dùng rời khỏi trang. 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.
Browser Support
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 đó. Khi không chắc chắn, dữ liệu phân tích có thể giúp bạn tự tin hơn trong việc kết xuất trước những trang có nhiều khả năng được truy cập tiếp theo nhất.
3. Sử dụng CDN để tối ưu hoá TTFB
Đề xuất trước đó tập trung vào tính năng điều hướng tức thì, giúp mang lại trải nghiệm tốt nhất có thể cho người dùng. Tuy nhiên, có thể có những trường hợp không áp dụng được bfcache và các kỹ thuật tải dự đoán. Hãy cân nhắc trường hợp người dùng truy cập vào trang web của bạn qua một đường liên kết nhiều nguồn gốc, trong đó phản hồi tài liệu HTML ban đầu chặn hiệu quả LCP. 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). Những 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 để thực hiện 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 các tài liệu HTML vào bộ nhớ đệm, nhưng theo Web Almanac, chỉ 33% số 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? Hay có thể chậm vài phút?
- 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ứ khi nào bạn có thể phân phát nội dung trực tiếp từ điểm cuối và tránh phải chuyển đến máy chủ gốc, đó đều là một chiến thắng về hiệu suất. Ngay cả trong trường hợp bạn phải thực hiện toàn bộ hành trình đến nguồn gốc, CDN thường được tối ưu hoá để thực hiện việc đó nhanh hơn, vì vậy, dù thế nào đi nữa, bạn cũng sẽ thắng.
Điểm số tổng hợp về mức thay đổi bố cục (CLS)
Mức thay đổi bố cục tích luỹ (CLS) là chỉ số đo lường độ ổn định của hình ảnh trên 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 width
và height
hoặc các thuộc tính CSS tương đương. 66% 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, các hình ảnh này có chiều cao ban đầu là 0px
, điều này có thể khiến bố cục thay đổi khi các hình ảnh này tải và trình duyệt khám phá kích thước của chúng. Đây là một cơ hội 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ì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ơ sở được cung cấp rộng rãi cho phép nhà phát triển đặt rõ ràng tỷ lệ khung hình trên hình ảnh cũng như 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à trình duyệt sẽ tự động tính toán chiều cao thích hợp, tương tự như cách trình duyệt tính toán cho hình ảnh có kích thước.
Tuy nhiên, không phải lúc nào bạn cũng 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ư đã nêu trước đó trong hướng dẫn này, bộ nhớ đệm cho thao tác tiến/lùi (bfcache) sẽ tải tức thì một trang từ trước hoặc 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 cá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 góp phần làm tăng CLS. Điều này đặc biệt gây ra vấn đề khi các biểu ngữ này đẩy nội dung khác ra ngoài, nhưng ngay cả khi không, việc tạo ảnh động cho các biểu ngữ này vẫn có thể ảnh hưởng đến CLS.
Mặc dù dữ liệu của Bản lưu trữ HTTP không thể kết nối chắc chắn ảnh động với các thay đổi về bố cục, nhưng dữ liệu này cho thấy rằng những 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 có ít khả năng có CLS "tốt" hơn 15% so với tổng thể các trang. Một số tài sản có chỉ số CLS thấp hơn so với các tài sản 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 tạo bố cục nào, điều này sẽ dẫn đến sự thay đổi bố cục. Nếu những thay đổi bố cục đó không nằm trong khoảng 500 mili giây kể từ khi người dùng tương tác, thì chúng sẽ ảnh hưởng đến CLS.
Đ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 chung về hiệu suất, 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 của người dùng hoặc nhấn phím (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.
Quy trình kiểm tra Lighthouse Tránh dùng các ảnh động không được ghép sẽ cảnh báo khi một trang tạo ảnh động cho các thuộc tính CSS có thể làm chậm trang.
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 năm 2024
Bản 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 đã thay đổi đề xuất sử dụng API
isInputPending
trong quá trình 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á tác vụ dài.
- LCP
- Chúng tôi đã kết hợp các đề xuất về khả năng được phát hiện và mức độ ưu tiên thành một đề xuất.
- Chúng tôi đã thêm một đề xuất mới để hướng đến việc điều hướng tức thì.
Tháng 1 năm 2023
Dưới đây là danh sách đề 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
- Đặt kích thước rõ ràng cho mọi nội dung được tải từ trang
- Đảm bảo trang đủ điều kiện sử dụng bfcache
- 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
- FID
- Tránh hoặc chia nhỏ các tác vụ dài
- Tránh sử dụng 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 2023 này để xem video tóm tắt.