Đ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ó.

| 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.
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.
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.
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.