Ảnh chụp trang tài liệu PageSpeed Insights của Google, nơi giải thích dữ liệu lab mô phỏng và dữ liệu thực địa, trình bày trên nền navy

Điểm PageSpeed trên điện thoại thấp hơn máy tính vì Lighthouse chạy hai bài đo khác nhau: điện thoại bị giả lập CPU chậm 4 lần, mạng 1,6 Mbps và độ trễ 150 ms. Trang chủ netsolutions.vn tải cùng 126 request, 2,44 MiB ở cả hai khung, nhưng được 26 điểm trên điện thoại và 46 điểm trên máy tính. Phần chênh gần như hoàn toàn đến từ JavaScript chặn luồng chính.

Hai phép đo khác nhau ngay từ thiết kế

Điểm điện thoại thấp hơn vì Lighthouse không đo hai khung ở cùng một điều kiện. Khung điện thoại giả lập một máy tầm trung trên mạng chậm: độ trễ 150 ms, băng thông 1,6 Mbps. Khung máy tính nhẹ tay hơn nhiều: độ trễ 40 ms, băng thông 10 Mbps, CPU không bị bóp. Tài liệu của Lighthouse mô tả việc bóp CPU như sau.

By default, Lighthouse uses a constant 4x CPU multiplier which moves a typical run in the high-end desktop bracket somewhere into the mid-tier mobile bracket.

— Lighthouse, tài liệu Throttling (mục Calibrating the CPU slowdown), 17/10/2026

Hai hạn chế cộng dồn. Mạng chậm kéo dài thời gian tải từng tệp. CPU chậm kéo dài thời gian chạy từng đoạn JavaScript. Trang nặng script chịu thiệt nhiều nhất ở khung điện thoại, vì cả hai hạn chế đều đánh vào nó.

Ảnh chụp tài liệu Throttling của Lighthouse trên GitHub, nơi mô tả thiết lập mạng của khung điện thoại: độ trễ 150 ms, băng thông 1,6 Mbps
Tài liệu Throttling của Lighthouse: thiết lập mạng của khung điện thoại, độ trễ 150 ms và băng thông 1,6 Mbps.
Thông số Điện thoại Máy tính
Kích thước màn hình giả lập 412×823 1350×940
Độ trễ mạng (RTT) 150 ms 40 ms
Băng thông 1.638,4 Kbps 10.240 Kbps
Hệ số bóp CPU ×4 ×1
Thiết bị khai trong user agent moto g power (2022) Macintosh (máy tính)

Nguồn: phần configSettings trong hai báo cáo Lighthouse 12.8.2 của netsolutions.vn, đo ngày 10/10/2026.

Tên máy giả lập cũng đổi theo phiên bản. Tài liệu Lighthouse lấy Moto G4 làm thiết bị mẫu cho nhóm tầm trung, còn báo cáo 12.8.2 của chúng tôi ghi moto g power (2022). Bài hướng dẫn cũ nhắc tên máy nào thì đừng coi đó là cấu hình hiện hành. Hãy mở phần configSettings của chính báo cáo bạn đo.

Số đo thật: cùng trang, cùng dung lượng, khác điểm

Cùng một trang chủ, cùng 126 request, cùng 2,44 MiB truyền về, điện thoại được 26 điểm còn máy tính được 46 điểm. Dung lượng không phải thủ phạm: hai khung tải lệch nhau chưa tới 100 byte. Thứ khác nhau là thời gian trình duyệt phải bỏ ra để chạy những gì đã tải.

Chỉ số Điện thoại Máy tính Điện thoại so với máy tính
Điểm Performance 26 46 −20 điểm
Số request 126 126 bằng nhau
Dung lượng truyền 2.562.183 B 2.562.222 B bằng nhau
First Contentful Paint 3,4 s 1,2 s gấp 2,8 lần
Largest Contentful Paint 6,6 s 4,5 s gấp 1,5 lần
Total Blocking Time 10.613 ms 249 ms gấp 43 lần
Speed Index 13,0 s 3,4 s gấp 3,8 lần
CLS 0,137 0,243 máy tính tệ hơn
Thời gian luồng chính 30,54 s 3,69 s gấp 8,3 lần

Nguồn: hai báo cáo Lighthouse 12.8.2 của trang chủ netsolutions.vn, mỗi khung một lượt, đo ngày 10/10/2026.

Hệ số bóp CPU chỉ là 4, nhưng thời gian luồng chính tăng 8,3 lần và TBT tăng 43 lần. TBT chỉ cộng phần vượt quá 50 ms của mỗi tác vụ, nên một tác vụ dài bị phóng đại nhanh hơn hệ số CPU. Đó là lý do một trang ổn ở máy tính có thể rớt mạnh ở điện thoại.

Điểm tổng là tổng có trọng số của năm chỉ số. Tách điểm theo từng chỉ số cho thấy chênh lệch nằm ở đâu.

Chỉ số Trọng số Điểm đóng góp: điện thoại Điểm đóng góp: máy tính Chênh
First Contentful Paint 10% 3,7 7,4 −3,7
Largest Contentful Paint 25% 2,0 3,0 −1,0
Total Blocking Time 30% 0,0 20,7 −20,7
CLS 25% 19,8 12,8 +7,0
Speed Index 10% 0,2 1,8 −1,6
Tổng 100% 25,6 45,6 −20,0

Điểm đóng góp = điểm từng chỉ số trong báo cáo × trọng số của Lighthouse 12. Điểm từng chỉ số trong báo cáo đã làm tròn hai chữ số, nên tổng lệch dưới 0,5 so với điểm hiển thị (26 và 46). Đo ngày 10/10/2026.

Gần như toàn bộ 20 điểm chênh nằm ở TBT: điện thoại mất trắng 20,7 điểm mà máy tính còn giữ. CLS lại bù ngược chiều 7,0 điểm cho điện thoại, vì CLS của khung máy tính tệ hơn (0,243 so với 0,137). Cách đọc từng chỉ số có trong bài cải thiện Core Web Vitals.

Một lượt đo chỉ là một mẫuMỗi khung chúng tôi chạy một lượt, bằng Lighthouse không giao diện chứ không phải pagespeed.web.dev. Đây là số mô phỏng, TBT dao động theo từng lượt vì chỉ cần một tác vụ dài thêm hoặc bớt là điểm đổi. Hãy xem các con số trên như minh hoạ cho cách đọc báo cáo, không phải kết quả cố định của trang.

Chênh bao nhiêu điểm là bình thường?

Không có mức chênh chuẩn. Trong tài liệu Lighthouse và PageSpeed Insights chúng tôi đã đọc, không có con số nào nói điện thoại được phép thấp hơn máy tính bao nhiêu điểm. Vì vậy đừng tin bài nào quả quyết "chênh trên 30 là bất thường". Hãy so từng chỉ số thay vì so điểm tổng.

Dấu hiệu trong báo cáo Thường có nghĩa là
TBT và LCP của điện thoại gấp nhiều lần máy tính JavaScript nặng hoặc phần tử lớn nạp muộn; đây là chỗ cần sửa
Chỉ FCP và Speed Index lệch vừa phải chủ yếu do phép đo: mạng chậm và CPU bóp
Cả hai khung đều thấp vấn đề nằm ở trang, không phải ở chế độ điện thoại
Máy tính tệ hơn ở một chỉ số lỗi riêng của khung rộng, ví dụ CLS của trang chủ chúng tôi

Cách đọc của Net Solutions, đối chiếu với số đo ở mục trước; không phải ngưỡng do Google công bố.

Với trang chủ netsolutions.vn, FCP gấp 2,8 lần là phần phép đo gây ra. TBT gấp 43 lần thì không. Con số đó vượt xa mọi hệ số của bộ giả lập, nên nguyên nhân nằm ở mã chạy trên trang. Về tác động của tốc độ lên SEO, xem website chậm ảnh hưởng SEO ra sao.

Điểm lab khác dữ liệu người dùng thật

Điểm Performance bạn thấy ở đầu báo cáo là dữ liệu lab, đo trong môi trường giả lập. PageSpeed Insights còn có dữ liệu thực địa, lấy từ người dùng Chrome thật. Google nói rõ hai loại này có thể khác nhau.

The lab data is based on a simulated load of a page on a single device and fixed set of network conditions.

— PageSpeed Insights, tài liệu About (v5), 17/10/2026

Điểm lab từ 90 trở lên được xem là tốt, 50 đến 89 cần cải thiện, dưới 50 là kém. Đánh giá Core Web Vitals thì không dùng điểm này. Nó dựa trên dữ liệu thật: trang đạt khi phân vị 75 của cả ba chỉ số đều ở mức Tốt.

Xem dữ liệu thật trước điểm labMở Search Console, mục Core Web Vitals, trước khi sửa. Nếu dữ liệu thật đã xanh, một điểm lab thấp chưa chắc là vấn đề của người dùng. Chi tiết xem bài website chậm ảnh hưởng SEO về chuyện PSI báo đỏ mà Search Console vẫn xanh.

Cách tăng điểm điện thoại, theo thứ tự nên làm

Sửa theo chỉ số đang mất nhiều điểm nhất, không sửa theo danh sách mười mẹo. Ở trang chủ của chúng tôi, TBT nặng 30% trọng số mà điện thoại được 0 điểm, nên đó là chỗ bắt đầu.

Triệu chứng Nguyên nhân thường gặp Việc sửa Rủi ro cần để ý
TBT cao, nhiều tác vụ dài JavaScript của plugin, slider, popup, chat, đo lường chạy trên luồng chính Gỡ hoặc nạp trì hoãn script không cần ở màn hình đầu; thay slider nặng bằng ảnh tĩnh Mất hiệu ứng; script đo lường nạp muộn có thể làm lệch số liệu
Có mục chặn hiển thị CSS và JS nằm trong head, trình duyệt phải đợi Tách CSS cần cho màn hình đầu, hoãn phần còn lại Giao diện nháy nếu tách sai
LCP cao Ảnh hoặc khối lớn nhất nạp muộn hoặc quá nặng Ưu tiên nạp đúng phần tử LCP, nén và đổi cỡ ảnh Ưu tiên nhầm phần tử làm chậm phần khác
CLS cao Ảnh, banner, font không khai trước kích thước Khai width, height và chừa sẵn chỗ cho banner Thấp; cần kiểm lại bố cục trên nhiều cỡ màn hình
Máy chủ trả trang đầu chậm Không có cache trang, hosting yếu, PHP nặng Bật cache trang, xem lại gói hosting Cache có thể giữ bản cũ với người đang đăng nhập

Tổng hợp của Net Solutions từ báo cáo Lighthouse của netsolutions.vn (10/10/2026) và hướng dẫn tối ưu của web.dev. Đọc ngày 17/10/2026.

Trang chủ của chúng tôi là ví dụ. Báo cáo ghi 20 tác vụ dài, tổng 13.126 ms. Plugin slider chiếm 9.443 ms, tức 72%, riêng một tác vụ của nó dài 7.867 ms. Lighthouse còn báo hai tệp CSS chặn hiển thị, ước tính tiết kiệm khoảng 970 ms ở khung điện thoại. Máy chủ trả trang đầu trong khoảng 140 ms, nên không phải nút thắt. Khi đo, chúng tôi chưa sửa phần này. Đó là chỗ chúng tôi sẽ sửa đầu tiên, và sẽ đo lại theo cách ở mục sau.

Nếu trang của bạn có cùng triệu chứng, việc nên làm trước tiên là tìm tác vụ dài nhất rồi lần ngược về tệp gây ra nó. Bạn có thể xem thêm bài tại sao website chậm để đối chiếu các nguyên nhân khác.

Đo lại đúng cách: ba lượt, lấy trung vị

Đo một lượt rồi kết luận là lỗi phổ biến nhất. Hãy chạy ba lượt cùng khung, cùng trang, cùng công cụ, rồi lấy trung vị. Ghi ngày đo và đừng so điểm của PageSpeed Insights với điểm của Lighthouse trên máy bạn như thể cùng một phép đo. Lighthouse chạy dòng lệnh mặc định ở khung điện thoại. Muốn đo khung máy tính, thêm cờ --preset=desktop theo hướng dẫn trong README của Lighthouse.

Python · đọc trung vị từ ba báo cáo Lighthouse (định dạng JSON)
import json, statistics

tep = ["lan1.json", "lan2.json", "lan3.json"]  # ba báo cáo Lighthouse cùng trang, cùng khung
diem, tbt = [], []
for t in tep:
    bc = json.load(open(t, encoding="utf-8"))
    diem.append(bc["categories"]["performance"]["score"] * 100)
    tbt.append(bc["audits"]["total-blocking-time"]["numericValue"])
cpu = bc["configSettings"]["throttling"]["cpuSlowdownMultiplier"]
print("CPU x", cpu, "| điểm trung vị:", statistics.median(diem), "| TBT trung vị:", round(statistics.median(tbt)), "ms")

Sau khi sửa, điểm lab đổi ngay. Dữ liệu thực địa thì không. Báo cáo thực địa của Chrome gom theo cửa sổ 28 ngày, nên hãy chờ khoảng bốn tuần rồi mới kết luận Core Web Vitals đã cải thiện. Nhớ dùng đúng một công cụ cho cả lần đo trước và lần đo sau.

Khi nào chưa cần sửa

Không phải trang nào có điểm lab thấp cũng cần sửa ngay. Nếu dữ liệu thật trong Search Console đã đạt, người dùng đang có trải nghiệm tốt và điểm lab chỉ là con số mô phỏng. Nếu trang ít lượt truy cập, chi phí sửa có thể lớn hơn lợi ích. Nếu bạn sửa chỉ để điểm lên mà trải nghiệm không đổi, đó là chạy theo con số.

Chúng tôi cũng không bán gói "đạt 90 điểm". Điểm Performance đổi theo phiên bản Lighthouse, theo lượt đo và theo script bên thứ ba bạn thêm sau này. Chúng tôi không cam kết điểm, không cam kết thứ hạng. Thứ chúng tôi cam kết là quy trình: đo, tìm nguyên nhân, sửa, đo lại, và ghi số trước sau.

Net Solutions làm gì cho điểm tốc độ

Chúng tôi bắt đầu từ dữ liệu thật trong Search Console, sau đó tìm phần tử gây chậm, sửa một nguyên nhân mỗi lần và đo lại sau 28 ngày. Làm kiểu này chậm hơn gỡ hàng loạt plugin, nhưng mỗi thay đổi đều có số đo trước sau để kiểm. Việc này nằm trong dịch vụ chăm sóc website. Nếu bạn cần soi cả nội dung, thẻ và cấu trúc, xem dịch vụ SEO audit chuyên sâu. Gọi hoặc nhắn Zalo 0906.207.001 để gửi địa chỉ trang cần xem.

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

Điểm PageSpeed bao nhiêu là tốt? Theo tài liệu PageSpeed Insights, điểm từ 90 trở lên là tốt, 50 đến 89 cần cải thiện và dưới 50 là kém. Đó là điểm lab. Việc trang có đạt Core Web Vitals hay không còn phụ thuộc dữ liệu người dùng thật ở phân vị 75, nên hãy xem cả hai.

Mobile hay desktop quan trọng hơn? Google lập chỉ mục và xếp hạng dựa trên bản di động của nội dung, theo tài liệu mobile-first indexing của Search Central. Vì vậy bản điện thoại nên được ưu tiên khi chỉ có thời gian sửa một khung. Hãy xem tỷ lệ thiết bị trong GA4 của bạn để biết khách thật vào bằng gì.

Vì sao mỗi lần đo ra một điểm khác nhau? Lighthouse mô phỏng việc tải trang, còn trang thật có biến thiên: máy chủ lúc nhanh lúc chậm, script bên thứ ba nạp lệch thời điểm. TBT dao động nhiều nhất vì chỉ cần một tác vụ vượt 50 ms thêm hoặc bớt là điểm đổi. Vì thế nên đo ba lượt rồi lấy trung vị.

PSI báo đỏ mà Search Console xanh thì sao? Hai nơi đo hai thứ khác nhau. PSI hiển thị điểm lab mô phỏng, Search Console dùng dữ liệu người dùng thật. Nếu dữ liệu thật đã đạt, người dùng đang ổn và việc sửa có thể chờ. Bài về website chậm và SEO giải thích kỹ hơn cách đọc hai nguồn này.

Có nên cố đạt 100 điểm trên điện thoại? Thường là không. Từ mức điểm khá trở lên, mỗi điểm thêm đòi hỏi nhiều công hơn hẳn mà người dùng khó nhận ra. Hãy đặt mục tiêu là các chỉ số thực địa đạt mức Tốt và trang dùng được mượt trên máy tầm trung, rồi dừng khi mục tiêu đó xong.

Tắt giả lập chậm thì điểm có cao hơn không? Thường cao hơn, vì máy của bạn mạnh hơn thiết bị giả lập. Nhưng điểm đó chỉ phản ánh máy của bạn, không phản ánh khách dùng điện thoại tầm trung. Bạn có thể dùng cách này để dò nguyên nhân, nhưng đừng dùng nó để báo cáo điểm.

Muốn biết điều gì đang kéo điểm trang của bạn xuống?

Gửi địa chỉ trang, chúng tôi đọc báo cáo, chỉ ra tác vụ gây chậm và đề xuất thứ tự sửa kèm cách đo lại.

Xem dịch vụ chăm sóc websiteNhắn ZaloHotline 0906.207.001

Cập nhật 21/10/2026 bởi Công ty TNHH Net Solutions.

Gọi ngay Chat Zalo Messenger Facebook Hỗ trợ qua Email