Tài nguyên được tối ưu hoá tốt nhất và nhanh nhất là tài nguyên không được gửi. Bạn nên loại bỏ các tài nguyên không cần thiết khỏi ứng dụng của mình. Bạn nên đặt câu hỏi và định kỳ xem lại các giả định ngụ ý và rõ ràng với nhóm của mình. Dưới đây là một số ví dụ:
- Bạn luôn đưa tài nguyên X vào các trang của mình, nhưng chi phí tải xuống và hiển thị tài nguyên đó có bù trừ giá trị mà nó mang lại cho người dùng không? Bạn có thể đo lường và chứng minh giá trị của nó không?
- Tài nguyên đó (đặc biệt nếu đó là tài nguyên của bên thứ ba) có mang lại hiệu suất ổn định không? Tài nguyên này có nằm trên lộ trình quan trọng hay cần nằm trong lộ trình quan trọng không? Nếu tài nguyên nằm trên đường dẫn quan trọng, nó có thể là điểm gây lỗi duy nhất cho trang web không? Tức là nếu tài nguyên không có sẵn, thì nó có ảnh hưởng đến hiệu suất và trải nghiệm người dùng trên trang của bạn không?
- Tài nguyên này có cần hoặc có SLA không? Tài nguyên này có tuân theo các phương pháp hay nhất về hiệu suất: nén, lưu vào bộ nhớ đệm, v.v. không?
Thông thường, các trang chứa các tài nguyên không cần thiết hoặc tệ hơn là cản trở hiệu suất của trang mà không mang lại nhiều giá trị cho khách truy cập hoặc trang web mà trang lưu trữ. Điều này cũng áp dụng như nhau cho các tài nguyên và tiện ích của bên thứ nhất và bên thứ ba:
- Trang web A đã quyết định hiển thị băng chuyền hình ảnh trên trang chủ để cho phép khách truy cập xem trước nhiều hình ảnh chỉ bằng một nhấp chuột nhanh. Tất cả ảnh đều được tải khi trang được tải và người dùng tiến qua các ảnh.
- Câu hỏi: Bạn đã đo lường bao nhiêu người dùng xem nhiều ảnh trong băng chuyền chưa? Bạn có thể phải chịu chi phí cao do tải xuống các tài nguyên mà hầu hết khách truy cập không bao giờ xem.
- Trang web B đã quyết định cài đặt một tiện ích của bên thứ ba để hiển thị nội dung có liên quan, cải thiện mức độ tương tác trên mạng xã hội hoặc cung cấp một số dịch vụ khác.
- Câu hỏi: Bạn đã theo dõi có bao nhiêu khách truy cập sử dụng tiện ích con hoặc nhấp qua nội dung mà tiện ích con cung cấp chưa? Mức độ tương tác mà tiện ích này tạo ra có đủ để biện minh cho chi phí của nó không? Hơn nữa, bạn có thể sử dụng chiến lược tải để đảm bảo tập lệnh không được tải cho đến khi cần không?
Việc xác định xem có nên loại bỏ các tệp tải xuống không cần thiết hay không thường đòi hỏi bạn phải suy nghĩ và đo lường cẩn thận. Để có kết quả tốt nhất, hãy kiểm tra định kỳ và xem lại những câu hỏi này cho từng thành phần trên các trang của bạn.
Ảnh hưởng đến Các chỉ số quan trọng về trang web
Google giới thiệu Các chỉ số quan trọng về trang web để cung cấp một bộ chỉ số phản ánh những gì người dùng đang gặp phải khi họ sử dụng web. Mặc dù có nhiều chiến lược tối ưu hoá cho Các chỉ số quan trọng về trang web, nhưng việc đặt câu hỏi liệu có nên tải một tài nguyên cụ thể trên một trang hay không, có thể giúp bạn cải thiện các chỉ số này trên trang web của mình. Dưới đây là một vài ví dụ mà bạn nên cân nhắc (được nhóm theo từng Chỉ số quan trọng chính của trang web). Mặc dù đây không phải là danh sách đầy đủ các ví dụ (và có rất nhiều ví dụ!), nhưng hãy đọc kỹ những ví dụ này để bạn có thể cân nhắc.
Thời gian hiển thị nội dung lớn nhất (LCP)
Thời gian hiển thị nội dung lớn nhất (LCP) đo lường thời điểm nội dung lớn nhất (ví dụ: hình ảnh chính hoặc dòng tiêu đề) được tải. Đây được xem là một chỉ số cảm nhận quan trọng, mang lại cho người dùng ấn tượng rằng một trang web đang tải nhanh.
Nói chung, việc tải ít tài nguyên xuống hơn đồng nghĩa với việc băng thông mà người dùng có sẽ được phân bổ cho ít tài nguyên hơn, và có thể dẫn đến cải thiện LCP. Một ví dụ điển hình là tải từng phần, trong đó, những hình ảnh bên ngoài khung nhìn trong khi tải trang sẽ không được tải xuống cho đến khi trình duyệt đã xác định rằng người dùng có nhiều khả năng nhìn thấy các hình ảnh đó hơn. Nếu bạn có một thư viện hình thu nhỏ lớn, chẳng hạn như 50 hình ảnh, tải từng phần, tất cả 10 hình ảnh trên cùng có nghĩa là trình duyệt có thể sử dụng băng thông có sẵn hiệu quả hơn và những hình ảnh đầu tiên người dùng nhìn thấy sẽ tải nhanh hơn.
Tuy nhiên, không chỉ cần tải ít hình ảnh hơn. Trình duyệt có một giao thức ưu tiên nội bộ xác định lượng băng thông mà mỗi tài nguyên sẽ nhận được. Tuy nhiên, ngay cả với tất cả các tài nguyên này, đặc biệt là những tài nguyên được tải xuống ở mức độ ưu tiên cao, vẫn có khả năng thiếu tài nguyên phụ thuộc của phần tử LCP tiềm năng. Điều này đặc biệt đúng trên các kết nối mạng chậm. Tài nguyên phụ thuộc đó có thể là tệp hình ảnh đại diện cho phần tử LCP của trang, nhưng cũng có thể là tài nguyên phông chữ web mà trình duyệt cần để hiển thị nút văn bản có thể được xác định là phần tử LCP của trang.
Nếu trang web của bạn có nhiều văn bản, thì đây có thể là trường hợp phần tử LCP của trang là nút văn bản. Mặc dù có nhiều chiến lược tải và tối ưu hoá phông chữ hiệu quả, nhưng bạn vẫn nên xem xét liệu phông chữ hệ thống có đủ cho nhu cầu của trang web hay không, để các phần tử LCP là nút văn bản có thể tải mà không phụ thuộc vào tài nguyên phông chữ trên web và hiển thị gần như ngay lập tức khi CSS và HTML đến từ máy chủ.
Điểm số tổng hợp về mức thay đổi bố cục (CLS)
Mỗi tài nguyên bạn tải đều có thể đóng góp vào Điểm số tổng hợp về mức thay đổi bố cục (CLS) của một trang, đặc biệt là khi chưa tải xuống xong trước thời điểm hiển thị ban đầu. Đối với hình ảnh, hãy tránh sử dụng CLS những phương pháp như đặt kích thước rõ ràng. Đối với phông chữ, việc quản lý hoạt động tải phông chữ và khả năng so khớp phông chữ dự phòng có thể giảm thiểu sự thay đổi trong khoảng thời gian hoán đổi của phông chữ trên web. Đối với JavaScript, nó có thể quản lý cách tập lệnh đó thao túng DOM để thay đổi bố cục giảm xuống mức có thể chấp nhận được.
Mọi tài nguyên đóng góp vào CLS (Điểm số tổng hợp về mức thay đổi bố cục) của một trang đều cần phải thực hiện một số thao tác để đảm bảo bố cục trang đủ ổn định. Khi đặt câu hỏi xem liệu bạn có cần một tài nguyên cụ thể hay không, bạn không chỉ tăng tốc độ tải trang mà còn giảm thiểu nỗ lực nhận thức cần thiết để duy trì độ ổn định của bố cục. Điều đó không chỉ giúp người dùng có trải nghiệm ít phiền toái hơn mà còn ít gây phiền toái hơn cho nhà phát triển, vì bạn sẽ có nhiều thời gian hơn để theo đuổi các mục tiêu khác trong dự án của mình.
Hoạt động tương tác với nội dung hiển thị tiếp theo (INP) và Thời gian phản hồi lần tương tác đầu tiên (FID)
Lượt tương tác với thời gian hiển thị tiếp theo (INP) và Thời gian phản hồi lần tương tác đầu tiên (FID) là những chỉ số đo lường khả năng phản hồi đối với hoạt động đầu vào của người dùng. Mặc dù INP dự kiến sẽ thay thế FID làm Chỉ số quan trọng chính của trang web vào tháng 3 năm 2024, nhưng các chiến lược tối ưu hoá cho FID cũng có xu hướng áp dụng cho INP. Hơn nữa, INP thường khó tối ưu hoá hơn so với FID vì FID theo dõi toàn bộ độ trễ tương tác cho tất cả lượt tương tác trên trang, chứ không chỉ độ trễ đầu vào của lượt tương tác đầu tiên như FID đo lường.
INP và FID có xu hướng bị ảnh hưởng nhiều nhất bởi JavaScript, vì JavaScript là yếu tố thúc đẩy hầu hết tính tương tác của một trải nghiệm trên web. Đối với cả INP và FID, lượng tài nguyên tập lệnh được tải xuống trong quá trình tải trang sẽ kích hoạt các công việc có thể tốn kém liên quan đến việc đánh giá và biên dịch tập lệnh. Bạn càng tải ít JavaScript trong quá trình khởi động, thì trình duyệt càng phải thực hiện ít công việc tại thời điểm quan trọng đó trong trải nghiệm trên trang.
Tuy có một số chiến lược giúp giảm kích thước của tài nguyên JavaScript được tải xuống trong quá trình khởi động (chẳng hạn như chia tách mã và rung cây), nhưng bạn vẫn nên kiểm tra các gói bạn sử dụng trong dự án để xem chúng có cần thiết hay không. Ví dụ: lodash có nhiều phương thức vẫn hữu ích hiện nay nhưng đi kèm với các phương thức mà trình duyệt cung cấp ngay từ đầu, chẳng hạn như các hàm dành riêng cho Array để ánh xạ, giảm thiểu và lọc cũng như nhiều phương thức khác.
Tính năng nâng cao tăng dần cũng là một phương pháp hữu ích đối với JavaScript, vì tính năng này cho phép bạn cung cấp trải nghiệm cơ sở (nhưng vẫn đầy đủ chức năng) cho người dùng mà bạn có thể thêm cho những người dùng có thiết bị mạnh mẽ hơn và kết nối mạng nhanh hơn. Cho dù bạn có tuân thủ nguyên tắc cải tiến tăng dần hay không thì vấn đề vẫn còn: Mọi tài nguyên JavaScript bạn có thể tránh tải xuống đều có thể dẫn đến trải nghiệm phản hồi nhanh hơn đối với tương tác của người dùng, đây là một khía cạnh quan trọng của hiệu suất web.
Kết luận
Việc kiểm tra trang web để tìm nội dung tải xuống không cần thiết có thể chỉ là một khía cạnh trong việc cung cấp trải nghiệm người dùng nhanh, nhưng đó là một khía cạnh có khả năng mang lại tác động lớn. Tóm lại:
- Kiểm kê tài sản của riêng bạn và tài sản của bên thứ ba trên các trang của bạn.
- Đo lường hiệu suất của từng nội dung: giá trị và hiệu suất kỹ thuật của nội dung.
- Xác định xem các tài nguyên có mang lại đầy đủ giá trị hay không.
- Hiểu được tác động của những lượt tải xuống không cần thiết đối với Các chỉ số quan trọng về trang web và các chỉ số hỗ trợ.
Khi tối ưu hoá hiệu quả của nội dung theo cách này, bạn không chỉ cải thiện hiệu suất tổng thể mà còn chú ý không làm lãng phí băng thông của người dùng, cũng như có khả năng cải thiện các chỉ số tập trung vào người dùng và mang lại trải nghiệm tốt hơn cho người dùng.