Ảnh hưởng của cấu trúc SPA đến Các chỉ số quan trọng về trang web

Câu trả lời cho các câu hỏi thường gặp về SPA, Các chỉ số quan trọng về trang web và kế hoạch của Google để giải quyết các hạn chế hiện tại về việc đo lường.

Kể từ lần đầu tiên ra mắt sáng kiến Các chỉ số quan trọng về trang web vào tháng 5 năm 2020, nhóm Chrome đã nhận được rất nhiều câu hỏi và ý kiến phản hồi hữu ích về chương trình này.

Có lẽ chủ đề mà chúng tôi nhận được nhiều câu hỏi nhất, cũng là câu hỏi khó trả lời nhất, là cách đo lường Các chỉ số quan trọng về trang web trong một ứng dụng một trang (SPA), cũng như cách cấu trúc SPA ảnh hưởng đến điểm số Các chỉ số quan trọng về trang web.

Những câu hỏi này rất khó trả lời vì vấn đề này khá phức tạp. Vì vậy, trong bài đăng này, chúng tôi sẽ cố gắng hết sức để trả lời những câu hỏi thường gặp nhất, cung cấp nhiều thông tin chi tiết và bối cảnh nhất có thể.

Tuy nhiên, trước khi đi sâu vào thông tin cụ thể, điều quan trọng là phải nêu rõ rằng Google không có bất kỳ ưu tiên nào về cấu trúc hoặc công nghệ dùng để xây dựng trang web. Chúng tôi tin rằng cả SPA và ứng dụng nhiều trang (MPA) đều có thể mang lại trải nghiệm chất lượng cao cho người dùng. Ý định của chúng tôi với sáng kiến Web Vitals là cung cấp các chỉ số đo lường trải nghiệm độc lập với công nghệ. Mặc dù hiện tại không thể thực hiện việc này trong mọi trường hợp (do các giới hạn trong nền tảng web), nhưng chúng tôi đang tích cực nỗ lực để thu hẹp những khoảng trống đó.

Câu hỏi thường gặp

Các chỉ số về Core Web Vitals có bao gồm quá trình chuyển đổi tuyến SPA không?

Không. Mỗi chỉ số trong Core Web Vitals được đo lường tương ứng với thao tác điều hướng trang cấp cao nhất hiện tại. Nếu một trang tự động tải nội dung mới và cập nhật URL của trang trong thanh địa chỉ, thì điều này sẽ không ảnh hưởng đến cách đo lường các chỉ số Core Web Vitals. Giá trị chỉ số không được đặt lại và URL liên kết với mỗi phép đo lường chỉ số là URL mà người dùng đã chuyển đến để bắt đầu tải trang.

Các chỉ số Core Web Vitals có thể coi các thay đổi về tuyến SPA giống như lượt tải trang truyền thống không?

Rất tiếc là không. Dù sao thì vẫn chưa có.

Hiện nay, không có cách thức chuẩn hoá nào để xây dựng một SPA, và ngay cả trong các thư viện SPA và định tuyến phổ biến, trải nghiệm người dùng có thể khác nhau khá nhiều giữa các ứng dụng:

  • Một số SPA chỉ cập nhật URL khi tải nội dung "trang đầy đủ" mới, trong khi các trang web khác cập nhật URL cho các thay đổi nhỏ về nội dung hoặc thậm chí chỉ thay đổi trạng thái giao diện người dùng.
  • Một số SPA cập nhật URL bằng API Nhật ký, trong khi một số khác sử dụng các thay đổi về hàm băm để hỗ trợ các trình duyệt cũ (và một số khác hoàn toàn không cập nhật URL).
  • Một số SPA tải nội dung rồi cập nhật URL, trong khi một số khác cập nhật URL trước khi tải nội dung.
  • Một số SPA tải nội dung cùng một lúc, đồng bộ, trong một tác vụ JavaScript duy nhất, trong khi một số SPA khác chuyển đổi nội dung không đồng bộ trên nhiều tác vụ (không có sự kiện kết thúc chuyển đổi rõ ràng).
  • Một số SPA luôn tải nội dung từ mạng, trong khi một số SPA khác tải trước tất cả nội dung để các thay đổi về tuyến tải ngay lập tức từ bộ nhớ.

Những điểm khác biệt này khiến việc xác định và xác định những gì tạo nên một thay đổi về tuyến đường của SPA hoặc thậm chí là chính SPA rất khó thực hiện ở quy mô lớn.

Trong một số trường hợp, việc thay đổi tuyến SPA về mặt logic giống với việc tải trang MPA. Trong những trường hợp như vậy, bạn nên áp dụng các chỉ số hiện có của Chỉ số quan trọng chính của trang web.

Tuy nhiên, nếu không có phương pháp phỏng đoán chắc chắn để xác định một cách đáng tin cậy các thay đổi "thực" về tuyến đường từ tất cả các thay đổi URL khác, cũng như các tín hiệu rõ ràng đánh dấu điểm bắt đầu và kết thúc của các quá trình chuyển đổi đó, thì việc báo cáo các chỉ số Core Web Vitals trong những trường hợp này sẽ làm rối dữ liệu và khiến dữ liệu trở nên ít hữu ích hoặc không thể hiện đúng trải nghiệm thực tế của người dùng trên trang web.

SPA khó đạt được điểm số cao về Chỉ số quan trọng chính của trang web hơn MPA phải không?

Không có gì trong cấu trúc SPA ngăn cản một trang trong một SPA tải nhanh như vậy và đạt điểm cao như vậy trên tất cả các chỉ số về Các chỉ số quan trọng về trang web như một trang tương tự trong MPA.

Tuy nhiên, MPA được tối ưu hoá đúng cách có một số lợi thế trong việc đáp ứng các ngưỡng của Chỉ số quan trọng chính của trang web mà SPA hiện không có. Lý do là do với cấu trúc MPA, mỗi "trang" được tải dưới dạng điều hướng toàn trang (thay vì tìm nạp nội dung một cách linh động và chèn nội dung đó vào trang hiện có). Điều này có nghĩa là những người dùng truy cập vào MPA có nhiều khả năng tải nhiều trang từ trang web hơn. Do đó, tỷ lệ phần trăm lớn hơn của việc phân phối tất cả các lượt tải trang cho MPA sẽ liên quan đến một số hoặc tất cả tài nguyên phụ đang được lưu vào bộ nhớ đệm.

Đúng là để MPA hoạt động hiệu quả hơn SPA về các chỉ số Core Web Vitals, một số điều sau đây phải đúng:

  • MPA cần tối ưu hoá việc lưu các tài nguyên phụ vào bộ nhớ đệm để đảm bảo rằng việc tải trang cùng nguồn gốc thực sự nhanh hơn so với việc tải trang trên nhiều nguồn gốc ở phân vị thứ 75.
  • Người dùng truy cập vào MPA cần truy cập vào nhiều trang để trang web có thể nhận được các lợi ích của việc lưu vào bộ nhớ đệm, giúp tải trang nhanh hơn.

Vì các hoạt động đánh giá Chỉ số quan trọng chính của trang web xem xét phân vị thứ 75 của số lượt truy cập trang, nên việc có nhiều lượt truy cập trang hoạt động hiệu quả hơn trong tập dữ liệu sẽ làm tăng khả năng lượt truy cập ở phân vị thứ 75 của phân phối sẽ nằm trong ngưỡng được đề xuất.

Xin lưu ý rằng một điều quan trọng cần cân nhắc khi so sánh điểm số Các chỉ số quan trọng về trang web là cách dữ liệu được tổng hợp, tức là liệu tập dữ liệu trong bản phân phối có bao gồm tất cả các trang trên trang web hoặc nguồn gốc của bạn hay chỉ tải trang cho một URL trang cụ thể.

Khi tổng hợp điểm số của tất cả các trang trong một nguồn gốc, các trang tải nhanh riêng lẻ có thể cải thiện phân vị thứ 75 cho toàn bộ nguồn gốc. Tuy nhiên, khi tổng hợp theo từng trang riêng lẻ, điểm của một trang sẽ không ảnh hưởng đến điểm của trang tiếp theo. Nói cách khác, khi tổng hợp điểm MPA theo trang, việc tải nhanh từ bộ nhớ đệm trên trang thanh toán sẽ không cải thiện điểm tải chậm ban đầu trên trang đích của trang web.

Bạn có thể kiểm tra điểm số của trang web cho nhiều phương pháp tổng hợp bằng cách sử dụng PageSpeed Insights hoặc API Báo cáo trải nghiệm người dùng của Chrome. API này sẽ báo cáo điểm số cho cả URL của từng trang và toàn bộ nguồn gốc.

Một cách khác mà cấu trúc SPA có thể ảnh hưởng đến điểm số Các chỉ số quan trọng về trang web là đối với các chỉ số xem xét toàn bộ vòng đời của một trang. Vì người dùng truy cập vào SPA có xu hướng ở lại cùng một "trang" trong toàn bộ phiên, nên các chỉ số tích luỹ theo thời gian có thể khắc nghiệt hơn đối với SPA so với MPA.

Vào tháng 4 năm 2021, chúng tôi đã thông báo về những thay đổi đối với chỉ số CLS giúp giải quyết một phần vấn đề này. Trước đây, CLS sẽ tích luỹ trong toàn bộ thời gian tồn tại của trang, nhưng hiện tại, chỉ số này chỉ tích luỹ trong một khoảng thời gian cụ thể, về cơ bản là khoảng thời gian có nhiều thay đổi bố cục nhất trên một trang nhất định.

Tuy nhiên, ngay cả với định nghĩa CLS mới, SPA vẫn gặp bất lợi vì giá trị CLS không "đặt lại" sau khi chuyển đổi tuyến như khi tải toàn bộ trang trong MPA. Điều này cũng có thể gây nhầm lẫn vì các thay đổi về bố cục xảy ra sau khi chuyển đổi tuyến sẽ được phân bổ cho URL của trang khi trang được tải, chứ không phải URL trong thanh địa chỉ tại thời điểm thay đổi (thông tin chi tiết hơn bên dưới).

Nếu cấu trúc SPA cải thiện trải nghiệm người dùng, thì sự cải thiện đó có được phản ánh trong các chỉ số không?

Có, bạn nên làm vậy. Tuy nhiên, như đã đề cập trước đó, việc định lượng mức độ cải thiện của trải nghiệm là rất khó thực hiện trên quy mô lớn, do tất cả các cách triển khai SPA trên web hiện nay.

Sự thật là ngành hiệu suất web (bao gồm cả Google) trước đây chưa đầu tư nhiều thời gian và công sức vào việc phát triển các chỉ số tập trung vào người dùng cho hiệu suất sau khi tải của một trang như đã đầu tư cho chính quá trình tải trang. Điều này không phải vì hiệu suất sau khi tải không quan trọng, mà là do trải nghiệm người dùng và hoạt động tương tác sau khi tải rất đa dạng và khó xác định hơn, khiến việc thiết kế chỉ số cho chúng trở nên khó khăn.

Tuy nhiên, ngay cả khi đã xác định rõ các chỉ số sau khi tải để đo lường hiệu suất của SPA, chúng ta cũng không nên bỏ qua trải nghiệm tải chỉ vì trải nghiệm sau khi tải đã tốt hơn.

Một trong những mục tiêu của sáng kiến Các chỉ số quan trọng về trang web là thúc đẩy và khuyến khích trải nghiệm người dùng tốt trên nhiều khía cạnh của việc tải và sử dụng trang web nhất có thể. Chúng tôi không muốn khuyến khích các tình huống mà trải nghiệm không tốt được coi là hợp lý nếu bạn có đủ trải nghiệm tốt để bù đắp cho những trải nghiệm không tốt đó. Người dùng muốn các trang tải nhanh chuyển đổi nhanh sang nội dung mới. Vì vậy, chúng tôi đã cố gắng thiết kế các chỉ số phù hợp với những loại trải nghiệm đó.

Vì vậy, mặc dù phiên bản MPA của một trang web có thể hoạt động tốt hơn trên các chỉ số Chỉ số quan trọng chính của trang web ở phân vị thứ 75 so với phiên bản SPA của chính trang web đó, nhưng phiên bản SPA vẫn phải cố gắng đạt ngưỡng "tốt". Nếu phiên bản SPA không đáp ứng ngưỡng "tốt" đối với hầu hết người dùng, thì trải nghiệm tải ban đầu có thể vẫn không được coi là tốt, ngay cả khi trải nghiệm điều hướng trong trang sau đó rất tuyệt vời.

Trong tương lai, chúng tôi dự định phát triển các chỉ số khuyến khích trải nghiệm tuyệt vời sau khi tải. Chúng tôi tin rằng đây là cách tốt nhất để khuyến khích các SPA chất lượng cao mà không làm ảnh hưởng đến trải nghiệm tải ban đầu. Chúng tôi đã cung cấp một chỉ số mới có tên là Lượt tương tác đến nội dung hiển thị tiếp theo (INP). Chỉ số này đo lường độ trễ tương tác trong toàn bộ vòng đời của trang. Ngoài ra, chúng tôi cũng đang tích cực nghiên cứu các chỉ số khác sau khi tải, bao gồm cả các chỉ số đo lường quá trình chuyển đổi tuyến SPA (xem bên dưới).

Chúng tôi đã chuyển trang web của mình từ MPA sang SPA và điểm số của chúng tôi đã giảm. Có phải như vậy không?

Còn tùy. Có một số lý do khiến điểm số của bạn có thể thay đổi sau khi di chuyển cấu trúc chính, nhưng việc giảm số lần tải bộ nhớ đệm ấm có thể giải thích một số thay đổi.

Một cách nhanh chóng để kiểm tra là kiểm tra cả phiên bản MPA và SPA của một trong các trang đích bằng Lighthouse. Nếu điểm Lighthouse thấp hơn trên bất kỳ chỉ số nào của Chỉ số quan trọng chính của trang web cho phiên bản SPA, thì có thể trải nghiệm tải đã trở nên tệ hơn sau khi cập nhật.

Tôi có nên chuyển trang web của mình từ SPA sang MPA để đạt điểm cao hơn về Các chỉ số quan trọng về trang web không?

Có thể là không. Bạn chỉ nên chuyển từ SPA sang MPA nếu không hài lòng với ngăn xếp SPA và có lý do để tin rằng MPA sẽ mang lại trải nghiệm người dùng tốt hơn.

Theo thời gian, khi các chỉ số Core Web Vitals cải thiện và bao quát nhiều hơn trải nghiệm duyệt web đầy đủ, các nhóm có SPA được xây dựng tốt và mang lại trải nghiệm người dùng tuyệt vời sẽ thấy điểm số Core Web Vitals phản ánh điều đó.

Nếu điểm số Chỉ số quan trọng chính của trang web chỉ được báo cáo cho trang đích của SPA, thì làm cách nào để gỡ lỗi các vấn đề xảy ra trên "trang" sau khi chuyển đổi tuyến?

Các công cụ của Google báo cáo dữ liệu thực tế cho chỉ số Các chỉ số quan trọng chính về trang web (như Search Console và PageSpeed Insights) lấy dữ liệu từ Báo cáo trải nghiệm người dùng trên Chrome (CrUX). Ngoài ra, CrUX tổng hợp dữ liệu theo nguồn gốc hoặc theo URL trang (tức là URL trang tại thời điểm tải).

Vì tất cả lý do nêu trên, CrUX không thể tổng hợp dữ liệu theo tuyến SPA. Tuy nhiên, với tư cách là chủ sở hữu trang web và đã quen thuộc với cấu trúc của riêng mình, bạn có thể tự đo lường điều này. Ngoài ra, nhiều công cụ phân tích cho phép bạn báo hiệu khi có thay đổi về tuyến SPA và cập nhật dữ liệu đo lường cho phù hợp.

Khi đo lường các chỉ số Web Vitals bằng một công cụ phân tích, hãy đảm bảo bạn đo lường cả URL tuyến hiện tại cũng như URL trang ban đầu. Điều này sẽ cho phép bạn vừa gỡ lỗi từng vấn đề xảy ra trong suốt vòng đời của trang vừa tổng hợp theo URL trang ban đầu để khớp với cách các công cụ của Google đo lường và báo cáo về các chỉ số.

Để biết thêm thông tin chi tiết và các phương pháp hay nhất về chủ đề này, hãy xem bài viết: Gỡ lỗi hiệu suất trong trường.

Google đang làm gì để đảm bảo MPA không có lợi thế không công bằng so với SPA?

Như đã đề cập ở trên, trong một số trường hợp, MPA được tối ưu hoá đúng cách có thể báo cáo điểm số Core Web Vitals tốt hơn ở phân vị thứ 75 do MPA có thể có tỷ lệ phần trăm lượt truy cập trang được lưu vào bộ nhớ đệm cao hơn. Ngược lại, các chỉ số quan trọng chính của trang web hiện không ghi nhận được những điểm cải tiến thực sự về trải nghiệm người dùng trong các SPA được tối ưu hoá đúng cách.

Tại Google, chúng tôi nhận thấy rằng điều này tạo ra các khoản khuyến khích không hoàn toàn phù hợp với mục tiêu của sáng kiến Web Vitals. Chúng tôi đang tích cực tìm cách khắc phục vấn đề này. Hiện tại, chúng tôi đang tìm hiểu hai giải pháp tiềm năng, một giải pháp ngắn hạn và một giải pháp dài hạn:

  1. Đánh giá riêng lượt truy cập trang trên nhiều nguồn gốc và lượt truy cập trang trên cùng một nguồn gốc.
  2. Thiết kế các API mới cho phép đo lường SPA hiệu quả hơn.

Đánh giá riêng lượt truy cập trang trên nhiều nguồn gốc và lượt truy cập trang trên cùng một nguồn gốc

Hiện tại, các chỉ số Core Web Vitals tổng hợp tất cả lượt truy cập trang vào một nhóm duy nhất. Các chỉ số này không phân biệt giữa lượt truy cập mới và lượt truy cập cũ, trang đích và trang thanh toán hoặc bất kỳ loại tổng hợp nào khác mà trạng thái bộ nhớ đệm có thể ảnh hưởng đến hiệu suất.

Một cách để chuẩn hoá sự khác biệt giữa hiệu suất của SPA và MPA là áp dụng các mức trọng số khác nhau cho các loại lượt truy cập, thậm chí có thể là với các đề xuất ngưỡng hoàn toàn khác nhau.

Mặc dù chúng tôi chắc chắn muốn thưởng cho việc triển khai bộ nhớ đệm hiệu quả, nhưng chúng tôi không muốn việc điều hướng nhanh trong trang web có thể che giấu việc tải trang đích chậm. Chúng tôi cũng không muốn khuyến khích các trang web chia các trang dài thành một tập hợp các trang ngắn hơn chỉ để cải thiện điểm số của chỉ số.

Bằng cách đánh giá riêng các lượt truy cập trang trên nhiều nguồn gốc và trên cùng một nguồn gốc, chúng tôi có thể giúp đảm bảo rằng cả hai loại trải nghiệm đều quan trọng mà không để mức độ phổ biến tương đối của một loại trên một trang web nhất định làm sai lệch việc phân phối bất kỳ chỉ số cụ thể nào.

Thiết kế các API mới cho phép đo lường SPA hiệu quả hơn

Một giải pháp khác đang được tích cực triển khai (song song với giải pháp trên) là App History API (API nhật ký ứng dụng) mới. API này sẽ giúp chuẩn hoá các mẫu SPA hiện tại và giúp bạn dễ dàng đo lường và hiểu rõ hơn về việc sử dụng SPA trên quy mô lớn.

API Nhật ký ứng dụng giới thiệu một sự kiện navigate mới, có hai tính năng chính dành riêng cho việc đo lường SPA:

  • Cờ userInitiated sẽ chỉ được đặt thành true nếu thao tác điều hướng được bắt đầu thông qua một lượt nhấp vào đường liên kết, gửi biểu mẫu hoặc giao diện người dùng quay lại hoặc chuyển tiếp của trình duyệt.
  • Phương thức transitionWhile(), thực hiện một lời hứa cho phép nhà phát triển báo hiệu khi công việc mà họ đã bắt đầu để thực hiện thao tác điều hướng hoàn tất.

Bạn có thể dùng cờ userInitiated để xác định điểm xuất phát ngữ nghĩa cho quá trình chuyển đổi tuyến SPA, cho biết rõ ý định của người dùng. Việc phân giải lời hứa transitionWhile() có thể giúp trình duyệt liên kết các lượt vẽ với quá trình chuyển đổi tuyến đường cụ thể, nhờ đó, trình duyệt có thể xác định lượt vẽ nội dung lớn nhất liên quan đến quá trình chuyển đổi đó.

Dựa trên ý tưởng được trình bày trong phần trước, bạn thậm chí có thể tổng hợp thời gian chuyển đổi tuyến SPA vào cùng một nhóm với lượt tải trang cùng nguồn gốc trong MPA. Điều này thật thú vị vì nó cho phép một trang web di chuyển từ MPA sang SPA để thực sự so sánh hiệu suất trước và sau khi di chuyển.

Tất nhiên, chúng ta cần nghiên cứu thêm trước khi biết liệu có thể xác định chính xác những điều này hay không. Nếu bạn có đề xuất hoặc ý kiến phản hồi về các đề xuất này, vui lòng gửi email đến web-vitals-feedback@googlegroups.com.

Những chỉnh sửa cuối

Google cam kết cải thiện các chỉ số Web Vitals và đảm bảo rằng các chỉ số này đo lường và khuyến khích trải nghiệm chất lượng cao quan trọng đối với người dùng. Tuy nhiên, chúng tôi cũng thừa nhận rằng hiện vẫn có sự chênh lệch về kết quả đo lường. Các chỉ số này hiện không bao gồm mọi khía cạnh của trải nghiệm người dùng, nhưng chúng tôi đang tích cực nỗ lực để khắc phục những thiếu sót này.

Mặc dù có những hạn chế hiện tại, nhưng chúng tôi tin rằng các khía cạnh mà các chỉ số hiện tại ghi nhận là rất quan trọng đối với tình trạng và sự thành công của web. Ngoài ra, chúng tôi tin rằng các trang web (bất kể cấu trúc) vẫn có thể cải thiện nếu không đáp ứng các ngưỡng được đề xuất.

Tôi hy vọng bài đăng này đã giúp làm sáng tỏ một số khía cạnh phức tạp và tinh tế của chủ đề này. Như thường lệ, nếu bạn có ý kiến phản hồi về các chỉ số Web Vitals hiện tại hoặc trong tương lai, vui lòng gửi email đến web-vitals-feedback@googlegroups.com.