Câu trả lời cho những câu hỏi thường gặp về chiến dịch quảng cáo ứng dụng toàn cầu (SPA), Các chỉ số quan trọng về trang web và kế hoạch của Google nhằm 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, chúng tôi Nhóm Chrome đã nhận được rất nhiều câu hỏi và phản hồi hữu ích về .
Có lẽ chủ đề mà chúng tôi nhận được nhiều câu hỏi nhất, cũng là có lẽ là câu hỏi khó trả lời nhất, đó là làm cách nào để đo lường Các chỉ số quan trọng về trang web trong một ứng dụng trang đơn (SPA), cũng như cách cấu trúc SPA ảnh hưởng đến điểm số Core Web Vitals.
Những câu hỏi này khó trả lời vì vấn đề khá phức tạp, do đó, trong bài đăng này, chúng tôi sẽ cố gắng hết sức để trả lời các câu hỏi phổ biến 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 vào các chi tiết cụ thể, bạn cần nói 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ệ được sử dụng để tạo một của bạn. Chúng tôi tin rằng cả hai ứng dụng SPA và nhiều trang (MPA) đều có khả năng về việc cung cấp trải nghiệm chất lượng cao cho người dùng và ý định của chúng tôi đối với môi trường Web Sáng kiến của Vitals là cung cấp những chỉ số đo lường trải nghiệm một cách độc lập của công nghệ. Mặc dù hiện nay chúng tôi không thể thực hiện được điều này trong mọi trường hợp (do hạn chế trong nền tảng web), chúng tôi đang tích cực làm việc để chấm dứt các .
Câu hỏi thường gặp
Các chỉ số Chỉ số quan trọng chính của trang web có bao gồm cả quá trình chuyển đổi lộ trình SPA không?
Không. Mỗi chỉ số trong Chỉ số quan trọng chính của trang web đều được đo lường tương ứng với điều hướng trang cấp cao nhất. Nếu một trang tự động tải trang mới nội dung và cập nhật URL của trang trong thanh địa chỉ, nó sẽ không có ảnh hưởng đến cách đo lường các chỉ số Chỉ số quan trọng chính của trang web. Giá trị của chỉ số không và URL được liên kết với mỗi phép đo chỉ số là URL mà người dùng đã điều hướng đến vị trí bắt đầu tải trang.
Các chỉ số Core Web Vitals có xử lý được những thay đổi về lộ trình SPA giống như các lượt tải trang truyền thống không?
Rất tiếc là không. Vẫn chưa.
Ngày nay, không có cách thức chuẩn hoá để xây dựng một SPA, và thậm chí trong SPA và các thư viện định tuyến phổ biến, trải nghiệm người dùng có thể khác nhau từ ứng dụng này sang ứng dụng khác:
- Một số SPA chỉ cập nhật URL khi tải "toàn bộ trang" mới nội dung, trong khi các trang web khác cập nhật URL cho những thay đổi nhỏ về nội dung hoặc thậm chí chỉ là trạng thái giao diện người dùng thay đổi.
- Một số SPA cập nhật URL bằng cách sử dụng API Lịch sử, trong khi các SPA khác sử dụng hàm băm các thay đổi để hỗ trợ các trình duyệt cũ (và các trình duyệt khác 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ố SPA 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 lúc một cách đồng bộ trong một JavaScript duy nhất nhiệm vụ, trong khi những tác vụ khác chuyển tiếp nội dung một cách không đồng bộ, trên nhiều nhiệm 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 những SPA khác tải trước tất cả để các thay đổi về định tuyến sẽ tải ngay lập tức từ bộ nhớ.
Những khác biệt này giúp việc xác định và nhận diện các yếu tố cấu thành lộ trình SPA thay đổi hay thậm chí là một SPA rất khó thực hiện trên quy mô lớn.
Trong một số trường hợp, việc thay đổi tuyến SPA giống về mặt logic với tải trang MPA, và trong những trường hợp như vậy, thật tuyệt nếu các Chỉ số quan trọng chính của trang web hiện có có thể được áp dụng.
Tuy nhiên, nếu không có các suy đoán chắc chắn để xác định một cách đáng tin cậy "thực" các thay đổi về tuyến đường từ tất cả các thay đổi khác về URL—cũng như những tín hiệu rõ ràng đánh dấu sự bắt đầu và kết thúc của quá trình chuyển đổi này, báo cáo các chỉ số Chỉ số quan trọng chính của trang web trong những trường hợp này sẽ rối mắt dữ liệu và làm cho dữ liệu đó kém hữu ích hơn hoặc không mô tả đúng trải nghiệm người dùng thực trên trang web.
Liệu các SPA có khó hoạt động hiệu quả trên Các chỉ số quan trọng về trang web hơn so với MPA không?
Không có gì vốn có trong kiến trúc SPA có thể ngăn một trang trong SPA tải nhanh như vậy—và ghi điểm tốt trên tất cả Các chỉ số Chỉ số quan trọng của 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 Core Web Các ngưỡng chỉ số quan trọng mà SPA hiện không đáp ứng. Lý do là vì với MPA cấu trúc, mỗi "trang" được tải dưới dạng thanh điều hướng toàn trang (thay vì tìm nạp động nội dung và chèn nội dung đó vào trang hiện có). có nghĩa là người dùng truy cập vào MPA có nhiều khả năng tải nhiều trang từ trang web, điều này có nghĩa là sẽ có tỷ lệ phần trăm lớn hơn trong việc phân phối tất cả thì mỗi lần tải trang cho MPA sẽ liên quan đến một số hoặc tất cả các tài nguyên phụ đang đã lưu vào bộ nhớ đệm.
Được chấp nhận, để một MPA hoạt động hiệu quả hơn đối với các chỉ số Core Web Vitals so với SPA cần đáp ứng một số điều sau:
- MPA cần phải tối ưu hoá việc lưu tài nguyên phụ vào bộ nhớ đệm để đảm bảo tải trang cùng nguồn gốc thực sự nhanh hơn so với tải trang trên nhiều nguồn gốc tại Phân vị thứ 75.
- Người dùng truy cập vào MPA cần truy cập nhiều trang để trang web được hưởng các lợi ích từ việc lưu vào bộ nhớ đệm giúp tải trang nhanh hơn.
Vì các bài đánh giá Core Web Vitals, hãy cân nhắc phiên bản 75 phân vị của trang thì khi có nhiều lượt truy cập trang hoạt động tốt hơn trong tập dữ liệu, khả năng lượt truy cập tại phân vị thứ 75 của mức phân phối sẽ trong ngưỡng đề 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ố Chỉ số quan trọng chính của trang web là cách dữ liệu được tổng hợp—tức là, liệu tập dữ liệu trong phân phối bao gồm tất cả các trang trên trang web hay nguồn gốc của bạn, hay chỉ tải trang cho một trang web URL của trang.
Khi tổng hợp điểm số của tất cả các trang trên một nguồn gốc, từng trang nhanh có thể cải thiện bách 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 số của một trang sẽ không ảnh hưởng đến điểm số của tiếp theo. Nói cách khác, khi tổng hợp điểm số của MPA theo trang, bộ nhớ đệm nhanh số lượt tải thấy trên trang thanh toán sẽ không cải thiện được điểm chậm trễ ban đầu tải trải nghiệm không rõ ràng trong trang đích .
Bạn có thể kiểm tra điểm số của trang web cho các phương thức tổng hợp khác nhau bằng cách sử dụng PageSpeed Insights hoặc báo cáo Trải nghiệm người dùng trên Chrome API, Báo cáo này báo cáo điểm số cho cả URL trang riêng lẻ 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ố Core Web Vitals là xem xét toàn bộ thời gian tồn tại của một trang. Từ khi có người dùng truy cập vào SPA có xu hướng ở trên cùng một "trang" cho toàn bộ phiên, các chỉ số tích luỹ theo thời gian có thể khiến SPA khắc nghiệt hơn MPA.
Vào tháng 4 năm 2021, chúng tôi đã công bố những thay đổi đối với chỉ số CLS đã giải quyết được một phần vấn đề này. CLS (Mức thay đổi bố cục tích luỹ) trước đây sẽ được tích luỹ trong toàn bộ thời gian hoạt động của trang, trong khi hiện tại trang chỉ tích luỹ qua một thời gian cụ thể thời gian – về cơ bản là đợt thay đổi bố cục tồi tệ nhất trên một trang nhất định.
Tuy nhiên, ngay cả khi được định nghĩa mới về CLS (Mức thay đổi bố cục tích luỹ), thì các SPA vẫn gặp nhiều bất lợi vì giá trị CLS không "đặt lại" sau khi chuyển đổi một tuyến đường như trước đây có tải toàn bộ trang ở định dạng MPA. Điều này cũng có thể dẫn đến nhầm lẫn vì bố cục những thay đổi xảy ra sau khi chuyển đổi tuyến đường sẽ được gán cho URL của trang khi trang được tải, không phải là URL trong thanh địa chỉ tại thời điểm chuyển (chi tiết khác bên dưới).
Nếu kiến 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ố hay không?
Có. Mặc dù như đã đề cập trước đó, việc định lượng mức độ trải nghiệm của bạn đã được cải thiện khó có thể thực hiện trên quy mô lớn, vì tất cả những 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 hề đã đầu tư gần nhiều thời gian và công sức vào việc phát triển giải pháp lấy người dùng làm trung tâm chỉ số về hiệu suất sau khi tải giống như đối với tải trang. Không phải là vì tính năng sau khi tải thì hiệu suất không quan trọng, đó là do trải nghiệm người dùng và các tương tác sau tải đa dạng hơn nhiều và ít được xác định rõ ràng hơn — gây khó khăn cho việc thiết kế các chỉ số cho chúng.
Nhưng ngay cả khi chúng ta đã xác định rõ các chỉ số sau tải để đo lường SPA nên chúng tôi không muốn bỏ qua trải nghiệm tải chỉ vì trải nghiệm tải bài đăng đã được cải thiện.
Một trong những mục tiêu của sáng kiến Chỉ số quan trọng của trang web là thúc đẩy và khuyến khích trải nghiệm người dùng trên nhiều khía cạnh khi tải và sử dụng trang web như nhất có thể. Chúng tôi không muốn khuyến khích các trường hợp có trải nghiệm không tốt là phù hợp nếu bạn có đủ trải nghiệm tốt để bù đắp cho họ. Số người dùng muốn các trang tải nhanh và chuyển đổi nhanh sang nội dung mới. Chúng tôi đã cố gắng chỉ số thiết kế ưu tiên các loại trải nghiệm đó.
Vì vậy, mặc dù đúng là phiên bản MPA của trang web có thể hoạt động hiệu quả hơn trên Core Web Các chỉ số Vitals ở bách phân vị thứ 75 so với phiên bản SPA của cùng một phiên bản trang web, phiên bản SPA vẫn cần phải cố gắng đáp ứng "những điều tốt đẹp" ngưỡng. Nếu Phiên bản SPA không đáp ứng yêu cầu "tốt" cho hầu hết người dùng, thì ngưỡng ban đầu trải nghiệm tải có thể vẫn chưa được coi là tốt—ngay cả khi trải nghiệm tiếp theo trải nghiệm điều hướng trong trang rất tốt.
Trong tương lai, chúng tôi dự định phát triển các chỉ số khuyến khích việc tải hiệu quả, trải nghiệm tốt nhất và chúng tôi tin rằng đây là cách tốt nhất để khuyến khích người dùng Đảm bảo không ảnh hưởng đến trải nghiệm tải ban đầu. Chúng ta có đã cung cấp chỉ số mới có tên Tương tác với 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, đồng thời chúng tôi đang tích cực nghiên cứu các chỉ số sau tải, bao gồm cả các chỉ số đo lường quá trình chuyển đổi tuyến đường 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 dần. Đó có phải là điều bình thường 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 giảm số lượt tải bộ nhớ đệm ấm có thể giải thích cho một số thay đổi.
Một cách kiểm tra nhanh là kiểm tra cả phiên bản MPA và SPA của một trong trang đích với Lighthouse. Nếu Điểm Lighthouse thấp hơn đối với bất kỳ chỉ số Chỉ số quan trọng chính của trang web nào cho SPA , thì có thể trải nghiệm tải sẽ 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 theo Chỉ số quan trọng chính của 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à bạn có lý do để tin rằng MPA sẽ mang lại trải nghiệm người dùng.
Theo thời gian, khi các chỉ số Core Web Vitals cải thiện và bao gồm nhiều thông tin trải nghiệm duyệt web, đội nhóm có SPA được thiết kế tốt mang lại trải nghiệm người dùng tuyệt vời chúng tôi dự kiến sẽ thấy điểm số Chỉ số quan trọng chính của trang web 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 để tôi có thể khắc phục các vấn đề xảy ra trên "trang" sau khi chuyển đổi tuyến đường?
Các công cụ của Google báo cáo dữ liệu trường cho chỉ số Core Web Vitals (chẳng hạn như Google Tìm kiếm Console và PageSpeed Insights) lấy dữ liệu từ Trải nghiệm người dùng Chrome Báo cáo (CrUX). Ngoài ra, CrUX tổng hợp dữ liệu theo nguồn gốc hoặc theo URL của trang (tức là URL trang tại thời điểm tải).
Vì tất cả những lý do đã liệt kê ở trên, CrUX không thể tổng hợp dữ liệu bằng Tuyến đường SPA. Tuy nhiên, là một chủ sở hữu trang web đã quen thuộc với kiến trúc của riêng mình, bạn có thể tự đo lường điều này và nhiều công cụ phân tích cho phép bạn tín hiệu khi có sự thay đổi về lộ trình SPA và chúng sẽ cập nhật kết quả đo lường của bạn dữ liệu tương ứng.
Khi đo lường các chỉ số Các chỉ số quan trọng về trang web bằng công cụ phân tích, hãy đảm bảo bạn đo lường cả URL của tuyến hiện tại và URL của trang gốc. Thao tác này sẽ cho phép bạn gỡ lỗi từng vấn đề riêng lẻ xảy ra trên trang vòng đời của trang web cũng như được tổng hợp theo URL trang gốc để phù hợp với cách đ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 về hiệu suất trong .
Google sẽ làm gì để đảm bảo rằng MPA không có lợi thế không công bằng so với các SPA?
Như đã đề cập ở trên, MPA được tối ưu hoá đúng cách trong một số trường hợp có thể báo cáo tốt hơn Các chỉ số quan trọng về trang web đạt điểm số tại bách phân vị thứ 75 do trên thực tế, chỉ số này 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, những cải tiến thực tế về trải nghiệm người dùng trong SPA được tối ưu hóa đúng cách hiện không được ghi lại theo bất kỳ chỉ số Core Web Vitals nào.
Tại Google, chúng tôi nhận thấy rằng chính sách này tạo ra các ưu đãi không hoàn toàn phù hợp với mục tiêu của sáng kiến Chỉ số quan trọng về trang web và chúng tôi đang tích cực xem xét các cách để khắc phục vấn đề này. Hiện tại, chúng tôi đang nghiên cứu hai giải pháp tiềm năng, một giải pháp ngắn hạn và một cụm từ dài hạn:
- Đánh giá riêng lượt truy cập vào trang trên nhiều nguồn gốc và lượt truy cập vào trang cùng nguồn gốc.
- 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 vào trang trên nhiều nguồn gốc và lượt truy cập vào trang cùng nguồn gốc
Hiện nay, các chỉ số Core Web Vitals tổng hợp tất cả lượt truy cập trang thành một nhóm – chúng không phân biệt giữa lượt truy cập mới và khách truy cập cũ hoặc trang đích trang so với trang thanh toán hoặc bất kỳ loại tổng hợp nào khác có 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 SPA và MPA là áp dụng trọng số khác nhau cho các loại lượt truy cập khác nhau, ngay cả khi ngưỡng khác biệt hoàn toàn các đề xuất khác.
Mặc dù chắc chắn chúng tôi muốn thưởng cho những triển khai bộ nhớ đệm hiệu quả, nhưng chúng tôi không muốn điều hướng nhanh trong trang web có thể bù đắp cho trang đích tải chậm tải. Chúng tôi cũng không muốn khuyến khích các trang web chia nhỏ các trang dài thành nhiều trang ngắn hơn chỉ nhằm mục đích cải thiện điểm của chỉ số.
Bằng cách đánh giá riêng lượt truy cập trang trên nhiều nguồn gốc và cùng 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 cho phép mức độ phổ biến của một loại trên một trang web nhất định làm lệch phân phối của bất kỳ chỉ số.
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 nghiên cứu (song song với các giải pháp nêu trên) là một API Lịch sử ứng dụng mới để giúp chuẩn hoá Các mẫu SPA và giúp đo lường cũng như hiểu được mức sử dụng SPA trên quy mô lớn một cách dễ dàng hơn.
App History API giới thiệu một giao diện mới
navigate sự kiện
có hai tính năng chính dành riêng cho việc đo lường SPA:
- Đáp
userInitiatedcờ này sẽ chỉ được đặt thành true nếu quá trình điều hướng được bắt đầu thông qua 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 tiến/lùi của trình duyệt. - Đáp
transitionWhile()là phương thức đảm bảo cho phép nhà phát triển đưa ra tín 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 bắt đầu về mặt ngữ nghĩa cho
chuyển đổi tuyến SPA, cho biết ý định rõ ràng của người dùng. transitionWhile()
hứa hẹn có thể giúp trình duyệt tạo ra được mối liên hệ với tuyến đường cụ thể
hiệu ứng chuyển đổi sao cho có thể xác định nội dung hiển thị lớn nhất
liên quan đến quá trình chuyển đổi đó.
Dựa trên ý tưởng đã trình bày trong phần trước, để tổng hợp thời gian chuyển đổi định tuyến SPA vào cùng một bộ chứa trang có cùng nguồn gốc tải trong một MPA. Điều này thật thú vị vì nó sẽ cho phép trang web chuyển từ MPA sang SPA để thực sự so sánh hiệu suất trước và sau đó.
Tất nhiên, cần nghiên cứu thêm trước khi biết liệu liệu chúng tôi có thể đưa ra các quyết định này. Nếu bạn có đề xuất hoặc phản hồi về những tính năng này đề xuất, vui lòng gửi email web-vitals-feedback@googlegroups.com.
Những chỉnh sửa cuối
Google cam kết sâu sắc trong việc cải thiện các chỉ số Các chỉ số quan trọng về trang web và đảm bảo họ đo lường và khuyến khích trải nghiệm chất lượng cao đóng vai trò quan trọng người dùng. Mặc dù vậy, chúng tôi hiểu rằng hiện nay vẫn còn thiếu hụt dữ liệu đo lường. Chiến lược phát hành đĩa đơn các chỉ số hiện tại 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 thu hẹp những lỗ hổng này.
Bất chấp những hạn chế hiện tại, chúng tôi tin rằng các lĩnh vực mà chỉ số hiện tại làm được chụp ảnh có ý nghĩa rất quan trọng đối với sự bền vững và sự thành công của trang web cũng như trong phạm vi rằng các trang web (bất kể cấu trúc là gì) không đáp ứng các ngưỡng được đề xuất, chúng tôi tin rằng có thể cải thiện.
Tôi hy vọng bài đăng này đã làm sáng tỏ phần nào đó về chủ đề phức tạp và tinh vi này. Như thường lệ, nếu bạn có ý kiến phản hồi về các chỉ số hiện tại hoặc trong tương lai, vui lòng gửi email web-vitals-feedback@googlegroups.com.