Câu trả lời cho những câu hỏi thường gặp về SPA, Core Web Vitals và cách Core Web Vitals xử lý những chỉ số này.
Xuất bản: ngày 14 tháng 9 năm 2021, Cập nhật lần gần đây nhất: ngày 11 tháng 8 năm 2026
Kể từ khi ra mắt sáng kiến Web Vitals 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à ý 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 Core Web Vitals trong ứng dụng một trang (SPA), cũng như cách cấu trúc SPA ảnh hưởng đến điểm số Core Web Vitals.
Rất khó để trả lời những câu hỏi này 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, đồng thời 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 chi tiết, bạn cần lưu ý rằng Google không ưu tiên bất kỳ cấu trúc hoặc công nghệ nào được dùng để tạo một trang web. Chúng tôi tin rằng cả ứng dụng một trang (SPA) và ứng dụng nhiều trang (MPA) đều có khả năng mang lại trải nghiệm chất lượng cao cho người dùng. Mục đích của chúng tôi khi triển khai sáng kiến Các chỉ số quan trọng về trang web là cung cấp các chỉ số đo lường trải nghiệm độc lập với công nghệ.
Câu hỏi thường gặp
Sau đây là một số câu hỏi thường gặp nhất mà chúng tôi nhận được về chủ đề này. Chúng tôi rất sẵn lòng tiếp nhận ý kiến phản hồi để bổ sung vào phần Câu hỏi thường gặp này tại nhóm phản hồi của chúng tôi hoặc bằng cách báo cáo vấn đề.
Chỉ số Core Web Vitals có bao gồm các lượt chuyển đổi tuyến đường SPA không?
Khi mới ra mắt, mỗi chỉ số trong Core Web Vitals đều được đo lường tương ứng với hoạt động điều hướng trang cấp cao nhất hiện tại. Nếu một trang tải động 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ố quan trọng chính của trang web.
Giá trị chỉ số không được đặt lại và URL được liên kết với mỗi phép đo chỉ số là URL mà người dùng đã chuyển đến để bắt đầu tải trang.
Chrome 151 ra mắt các API mới cho phép đo lường Core Web Vitals trong quá trình chuyển đổi tuyến đường SPA. Tại thời điểm viết bài này (tháng 8 năm 2026), các API này mới bắt đầu được sử dụng trong các thư viện đo lường như web-vitals, các giải pháp RUM và các công cụ như Chrome DevTools. Chrome chưa công bố khung thời gian tích hợp các chỉ số này vào Báo cáo trải nghiệm người dùng trên Chrome (CrUX). Ngoài ra, các công cụ trình duyệt khác hiện chưa hỗ trợ những API mới này, do đó, Core Web Vitals chỉ có thể được đo lường trên toàn bộ lượt tải trang cho những trình duyệt đó.
Tại sao đây là một vấn đề khó giải quyết?
Hiện không có cách tiêu chuẩn nào để tạo SPA và ngay cả trong số các SPA và thư viện định tuyến phổ biến, trải nghiệm người dùng có thể khác nhau giữa các ứng dụng:
- Một số SPA chỉ cập nhật URL khi tải nội dung "toàn trang" mới, 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ỉ thay đổi trạng thái giao diện người dùng.
- Một số SPA cập nhật URL bằng History API, trong khi những SPA khác sử dụng các thay đổi về hàm băm để hỗ trợ các trình duyệt cũ (và những SPA 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 những 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 một lúc, đồng bộ, trong một tác vụ JavaScript duy nhất, trong khi những 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 những SPA khác tải trước tất cả nội dung để các thay đổi về tuyến đường 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à nhận dạng những yếu tố tạo nên một thay đổi về tuyến đường SPA, hoặc thậm chí là chính SPA, trở nên 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 đường SPA về mặt logic giống hệt với việc tải trang MPA và trong những trường hợp như vậy, sẽ rất tốt nếu bạn có thể áp dụng các chỉ số hiện có về Core Web Vitals.
Tuy nhiên, nếu không có các phương pháp phỏng đoán chắc chắn để xác định một cách đáng tin cậy những thay đổi về tuyến đường "thực" so với tất cả những thay đổi khác về URL, 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 những quá trình chuyển đổi như vậy, thì việc báo cáo các chỉ số quan trọng chính của trang web trong những trường hợp này sẽ làm sai lệch dữ liệu và khiến dữ liệu trở nên ít hữu ích hoặc ít đại diện cho trải nghiệm thực tế của người dùng trên trang web.
Công việc Điều hướng mềm đã cung cấp một giải pháp cho vấn đề này bằng 2 API hiệu suất mới:
PerformanceSoftNavigationđo lường thời điểm một lượt tương tác của người dùng dẫn đến cả một thao tác hiển thị và một thay đổi về URL. Sự kết hợp của 3 yếu tố này cung cấp một định nghĩa tiêu chuẩn về "thao tác điều hướng mềm" bất kể khung được sử dụng và một số điểm khác biệt đã đề cập trước đó. Điều này cho phép chia dòng thời gian hiệu suất thành các "thao tác điều hướng" riêng biệt, cho phép đo lường CLS và INP cho từng thao tác điều hướng.InteractionContentfulPaintđo lường "lượt hiển thị có nội dung" sau một lượt tương tác, cho phép đo lường FCP và LCP cho những lượt điều hướng mềm này.
Việc kết hợp hai API này cho phép đo lường Core Web Vitals trên cả lượt tải trang đầy đủ và lượt điều hướng mềm.
Việc thay đổi tuyến đường SPA có giống với việc tải toàn bộ trang đối với Core Web Vitals không?
Không, vẫn có nhiều điểm khác biệt giữa các loại thao tác điều hướng này, có thể dẫn đến các chỉ số quan trọng chính của trang web khác nhau.
Thao tác điều hướng mềm có nội dung trên trang và đang cập nhật một phần hoặc toàn bộ nội dung đó để hiển thị "trang" mới. Theo nhiều cách, điều này tương tự như sự khác biệt giữa một lần tải trang đầy đủ chưa được lưu vào bộ nhớ đệm so với một lần tải trang khi một số hoặc tất cả tài nguyên trang được lưu vào bộ nhớ đệm, nhưng ở trạng thái cực đoan hơn vì một số nội dung có thể vẫn được hiển thị.
Về lý thuyết, điểm khác biệt chính sẽ là khả năng điều hướng mềm nhanh hơn nhiều. Tuy nhiên, vẫn có những điểm khác biệt khác tinh tế hơn.
Các API điều hướng linh hoạt mới chỉ xem xét nội dung mới. Vì vậy, một trang cập nhật <h1> và nội dung văn bản, nhưng vẫn giữ nguyên hình ảnh chính giữa các trang sẽ không coi hình ảnh chính là một ứng cử viên LCP nếu hình ảnh đó không vẽ lại. Điều này sẽ dẫn đến sự khác biệt về những phần tử được dùng để tính thời gian LCP dựa trên việc trang đó được tải dưới dạng một lượt tải trang đầy đủ hay dưới dạng một thao tác điều hướng mềm từ một trang hiện có khác.
Tương tự, INP có thể thấp hơn đối với các thao tác điều hướng mềm vì nhiều JavaScript cần thiết để chạy trang web sẽ được tải sẵn. Tương tự, một thao tác điều hướng mềm có thể có ít (hoặc nhiều hơn!) CLS nếu cùng một nội dung gây ra CLS khi tải toàn bộ trang nhưng không cần được tải hoặc kết xuất lại trong một thao tác điều hướng mềm.
Ngoài ra, có một số điểm khác biệt nhỏ về thời điểm đo lường trong quá trình tải toàn bộ trang (được đo lường từ sau khi xử lý tương tác điều hướng) so với điều hướng mềm (được đo lường từ thời gian bắt đầu tương tác).
Như đã đề cập trước đó, nhiều điểm khác biệt trong số này tương tự như các trang chưa lưu vào bộ nhớ đệm so với các trang đã lưu vào bộ nhớ đệm và khái niệm về những gì Core Web Vitals cố gắng đo lường vẫn được áp dụng. Tuy nhiên, bạn nên hiểu rõ những điểm tinh tế này khi điều tra các vấn đề về Chỉ số quan trọng chính của trang web.
Liệu các trang ứng dụng một trang (SPA) có khó đạt được Core Web Vitals hơn các trang ứng dụng nhiều trang (MPA) không?
Không có yếu tố nào trong cấu trúc SPA có thể ngăn một trang trong SPA tải nhanh như một trang tương tự trong MPA và đạt điểm cao như vậy trên tất cả các chỉ số Core Web Vitals.
Tuy nhiên, các MPA được tối ưu hoá đúng cách có một số lợi thế trong việc đáp ứng ngưỡng Các chỉ số quan trọng chính của trang web mà các SPA không có. Vấn đề này phần lớn đã được giảm thiểu nhờ công việc điều hướng linh hoạt mà chúng ta đã thảo luận trước đó, nhưng vẫn có thể xảy ra khi các API mới này chưa được sử dụng. Lý do là vì với cấu trúc MPA, mỗi "trang" được tải dưới dạng một thao tác đ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à người dùng truy cập vào một MPA có nhiều khả năng tải nhiều trang từ trang web hơn. Do đó, một tỷ lệ phần trăm lớn hơn trong phân phối tất cả các lượt tải trang cho một MPA sẽ liên quan đến một số hoặc tất cả các tài nguyên phụ được lưu vào bộ nhớ đệm.
Tất nhiên, để MPA hoạt động hiệu quả hơn về các chỉ số Core Web Vitals so với SPA, bạn cần đảm bảo một số điều sau:
- MPA cần có tính năng lưu vào bộ nhớ đệm tài nguyên phụ được tối ưu hoá để đảm bảo các lượt tải trang cùng nguồn thực sự nhanh hơn các lượt tải trang khác nguồn gốc ở phân vị thứ 75.
- Người dùng truy cập vào MPA cần phải truy cập vào nhiều trang để trang web nhận được lợi ích từ việc lưu vào bộ nhớ đệm, giúp trang tải nhanh hơn.
Vì các hoạt động đánh giá Core Web Vitals của trang web xem xét phân vị thứ 75 của 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ả 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 bản phân phối 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 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 từ trang web hoặc nguồn 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 riêng lẻ có tốc độ tải nhanh có thể cải thiện phân vị thứ 75 cho nguồn gốc nói chung. Tuy nhiên, khi tổng hợp theo từng trang, điểm số của một trang sẽ không ảnh hưởng đến điểm số của trang tiếp theo. Nói cách khác, khi tổng hợp điểm số của một MPA theo trang, các lượt tải bộ nhớ đệm nhanh xuất hiện trên trang thanh toán sẽ không cải thiện điểm số của các lượt tải ban đầu chậm xuất hiện 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 Báo cáo trải nghiệm người dùng trên Chrome API. API này 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ố Core Web Vitals là đối với những chỉ số xem xét toàn bộ thời gian tồn tạ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ắt khe hơn đối với SPA so với MPA.
Với tính năng điều hướng mềm, chúng tôi tin rằng SPA sẽ không gặp bất lợi nào về cách đo lường Core Web Vitals. Tuy nhiên, việc tích hợp đầy đủ các API này trên tất cả các giải pháp báo cáo và công cụ sẽ mất thời gian.
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ó nên được phản ánh trong các chỉ số không?
Có, nên như vậy. 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 ở quy mô lớn, vì có rất nhiều cách triển khai SPA trên web hiện nay. Giờ đây, chúng tôi đã có giải pháp cho vấn đề đo lường và khi bạn sử dụng các API mới này, mọi điểm cải thiện khi chuyển sang SPA sẽ được phản ánh trong các chỉ số.
Sự thật là ngành hiệu suất web (bao gồm cả Google) trước đây đã không đầu tư nhiều thời gian và công sức vào việc phát triển các chỉ số lấy người dùng làm trung tâm cho hiệu suất sau khi tải của một trang như đối với 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à vì trải nghiệm người dùng và hoạt động tương tác sau khi tải đa dạng hơn nhiều và ít được xác định rõ ràng hơn, khiến bạn khó thiết kế các chỉ số cho những yếu tố này.
Nhưng ngay cả khi có nhiều chỉ số sau tải để đo lường hiệu suất 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 tải đã tốt hơn.
Một trong những mục tiêu của sáng kiến Web Vitals 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 nhất có thể khi tải và sử dụng một trang web. Chúng tôi không muốn khuyến khích những trường hợp mà trải nghiệm kém được biện minh nếu bạn có thể có đủ trải nghiệm tốt để bù đắp cho những trải nghiệm kém đó. Người dùng muốn các trang tải nhanh và chuyển đổi sang nội dung mới một cách nhanh chóng. Vì vậy, chúng tôi đã cố gắng thiết kế các chỉ số có lợi cho những loại trải nghiệm đó.
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 xuống. Điều đó có nằm trong dự kiến 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ượng tải bộ nhớ đệm nóng có thể giải thích cho một số thay đổi.
Một cách nhanh chóng để kiểm tra là thử nghiệm 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 ở bất kỳ chỉ số nào trong số Các chỉ số quan trọng chính của trang web cho phiên bản SPA, thì có khả năng 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 chính của trang web không?
Thường 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.
Với công việc điều hướng mềm, chúng tôi tin rằng mình đã giải quyết các vấn đề về đo lường, vì vậy, việc di chuyển chỉ vì lý do đó là không hợp lý.
Tuy nhiên, nếu bạn có lý do để cho thấy hiệu suất sẽ cải thiện, thay vì chỉ các chỉ số đo lường cải thiện, thì đó có thể là lý do để chuyển từ SPA sang MPA (hoặc ngược lại!).
Nếu điểm Các chỉ số quan trọng chính của trang web chỉ được báo cáo cho các trang đích của SPA, thì làm cách nào để gỡ lỗi các vấn đề xảy ra trên "các trang" sau khi chuyển đổi tuyến đường?
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 của trang web (chẳng hạn 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). 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).
Chúng tôi đang nỗ lực cho phép CrUX đưa dữ liệu theo tuyến đường SPA vào dữ liệu tổng hợp. Tuy nhiên, giờ đây, với tư cách là chủ sở hữu trang web, bạn có thể sử dụng các API mới để đo lường Core Web Vitals theo tuyến SPA trước khi có thay đổi này để biết điểm số của bạn có thể thay đổi như thế nào.
Để biết thêm thông tin chi tiết và các phương pháp hay nhất về vấn đề này, hãy xem bài viết: Đo lường thao tác điều hướng mềm.
Google đang làm gì để đảm bảo rằng MPA không có lợi thế bất công so với SPA?
Như đã đề cập trước đó, với tính năng điều hướng mềm, chúng tôi tin rằng những việc chúng tôi đã thực hiện hiện tại có nghĩa là sẽ không có bất lợi nào cho SPA về vấn đề này, mặc dù việc tích hợp đầy đủ trên tất cả các giải pháp báo cáo và công cụ sẽ mất thời gian.
Đánh giá riêng lượt truy cập trang khác nguồn gốc và cùng nguồn
Hiện tại, các chỉ số quan trọng về trang web 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 quay lại, 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 độ quan trọng khác nhau cho các loại lượt truy cập khác nhau, thậm chí có thể có đề xuất ngưỡng hoàn toàn khác.
Mặc dù chắc chắn muốn khen thưởng những cách triển khai bộ nhớ đệm hiệu quả, nhưng chúng tôi không muốn các thao tác điều hướng nhanh trong trang web có thể che đậy các lần 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ố chỉ số.
Bằng cách đánh giá riêng biệt lượt truy cập trang từ nhiều nguồn và cùng nguồn, 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 sự phân phối của bất kỳ chỉ số cụ thể nào.
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 những 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 tại vẫn có sự chênh lệch về kết quả đo lường. Giờ đây, các chỉ số có thể bao gồm các quá trình chuyển đổi tuyến đường SPA, giải quyết một trong những khoảng trống chính.
Chúng tôi cũng tin rằng những API mới này (đặc biệt là InteractionContentfulPaint) có thêm nhiều mục đích sử dụng và lợi ích tiềm năng ngoài việc đo lường Core Web Vitals cho các thao tác điều hướng mềm. Chúng tôi rất hào hứng khi tiếp tục phát triển những tính năng này vì lý do chính khiến chúng tôi ra mắt các tính năng này đã được giải quyết.
Tôi hy vọng bài đăng này đã giúp bạn hiểu rõ hơn về chủ đề phức tạp và tinh tế này. Như thường lệ, nếu bạn có ý kiến phản hồi về Các chỉ số quan trọng hiện tại hoặc trong tương lai về trang web, hãy gửi email đến web-vitals-feedback@googlegroups.com.