01/10/2026

Dịch vụ tối ưu tốc độ website: 28 ngày mới nghiệm thu

Dịch vụ tối ưu tốc độ website nên nghiệm thu bằng dữ liệu thực địa: bách phân vị 75, cửa sổ 28 ngày của CrUX, không bằng ảnh chụp điểm PageSpeed.

Dịch vụ tối ưu tốc độ website là việc thuê bên ngoài sửa mã nguồn, hình ảnh và máy chủ để trang tải nhanh và phản hồi nhanh hơn với người dùng thật. Kết quả nên được nghiệm thu bằng dữ liệu thực địa, không bằng ảnh chụp điểm PageSpeed. Dữ liệu thực địa trong PageSpeed Insights gom lượt truy cập của 28 ngày gần nhất, theo tài liệu PageSpeed Insights của Google năm 2024. Vì vậy số thật để nghiệm thu chỉ có khi cả 28 ngày đều nằm sau lần sửa cuối, tức khoảng ngày thứ 30.

Dịch vụ tối ưu tốc độ website gồm những việc gì?

Một gói tối ưu tốc độ gồm ba nhóm việc, ứng với ba chỉ số Core Web Vitals. Đó là rút ngắn thời gian hiện nội dung chính (LCP), giảm độ trễ khi người dùng bấm (INP) và giữ bố cục không xô lệch (CLS). Riêng LCP được chia thành 4 chặng, theo hướng dẫn tối ưu LCP của web.dev năm 2025. Bốn chặng là máy chủ phản hồi, chờ tải tài nguyên, tải tài nguyên và chờ hiển thị. Báo giá nên ghi rõ đầu việc nào nhắm vào chỉ số nào và chặng nào.

  • Việc cho LCP: nén và đổi định dạng ảnh, tải trước ảnh chính, bật bộ nhớ đệm, dùng CDN, rút ngắn thời gian máy chủ phản hồi.
  • Việc cho INP: cắt bớt JavaScript, chia nhỏ tác vụ dài, hoãn mã của bên thứ ba như khung trò chuyện hay quảng cáo.
  • Việc cho CLS: khai báo kích thước ảnh và khung quảng cáo, tải phông chữ sao cho chữ không nhảy dòng.
  • Ở trang đã tối ưu tốt, máy chủ phản hồi và tải tài nguyên mỗi chặng chiếm khoảng 40% thời gian LCP; hai chặng chờ mỗi chặng dưới 10%.
  • Bảng giá MOMD năm 2026 không có mục lẻ cho tối ưu tốc độ. Core Web Vitals là một nhóm kiểm trong bản audit kỹ thuật 60+ điểm của MOMD và là một hạng mục của gói SEO E-commerce.

Dữ liệu thực địa và dữ liệu phòng thí nghiệm khác nhau thế nào?

Dữ liệu thực địa là số đo từ người dùng Chrome thật, còn dữ liệu phòng thí nghiệm là một lần tải trang mô phỏng. PageSpeed Insights hiện cả hai trên cùng một trang kết quả. Phần thực địa lấy từ Báo cáo trải nghiệm người dùng Chrome (CrUX) và cập nhật mỗi ngày, theo tài liệu PageSpeed Insights của Google năm 2024. Phần phòng thí nghiệm do Lighthouse chạy từ trung tâm dữ liệu của Google ở một trong 3 khu vực. Ở chế độ di động, Lighthouse mô phỏng một điện thoại tầm trung trên mạng di động.

  • Dữ liệu phòng thí nghiệm có ngay sau mỗi lần chạy, hợp để tìm lỗi và thử từng thay đổi.
  • Dữ liệu thực địa phản ánh máy thật và mạng thật của khách, nên chậm đổi hơn nhưng sát thực tế hơn.
  • CrUX chỉ gồm người dùng Chrome đã bật chia sẻ thống kê sử dụng và đồng bộ lịch sử duyệt; Chrome trên iOS và các trình duyệt khác không có trong số này.
  • Báo cáo Core Web Vitals trong Search Console cũng dùng dữ liệu thực địa của CrUX.
  • Hai loại số lệch nhau là chuyện bình thường; hợp đồng cần ghi rõ nghiệm thu bằng loại nào.

Khi nào một trang được coi là đạt Core Web Vitals?

Một trang đạt Core Web Vitals khi bách phân vị 75 của cả ba chỉ số LCP, INP và CLS đều ở mức tốt. Bách phân vị 75 nghĩa là ít nhất 3 trong 4 lượt truy cập có trải nghiệm bằng hoặc tốt hơn con số ấy. Mốc này được chọn để phần lớn lượt truy cập đạt ngưỡng mà ít bị lượt đo bất thường kéo lệch, theo bài «Defining the Core Web Vitals thresholds» của web.dev năm 2020. Số trung bình hay số của một lần đo không được dùng để xếp loại.

  • Một chỉ số chưa tốt là cả trang không đạt, dù hai chỉ số kia rất tốt.
  • Mức tốt là LCP trong 2,5 giây, INP dưới 200 mili giây và CLS dưới 0,1, theo tài liệu Core Web Vitals của Google Search Central năm 2025. Ba ngưỡng này được giải thích ở bài về các loại dịch vụ SEO.
  • Khi trang chưa đủ dữ liệu INP, PageSpeed Insights xét đạt nếu LCP và CLS đều tốt.
  • Di động và máy tính được báo cáo riêng, nhưng dùng cùng một bộ ngưỡng.
  • Khi một URL chưa đủ dữ liệu, PageSpeed Insights hiện số gộp của cả website để thay thế. Hợp đồng nên ghi rõ nghiệm thu trên URL nào và trên loại thiết bị nào.

Vì sao ảnh chụp điểm PageSpeed chưa phải bằng chứng nghiệm thu?

Ảnh chụp điểm PageSpeed chưa phải bằng chứng vì con số 0–100 ấy là điểm hiệu suất của Lighthouse, tính từ một lần tải trang mô phỏng. Điểm từ 90 trở lên được coi là tốt, nhưng điểm tốt không có nghĩa trải nghiệm của người dùng thật cũng tốt, theo tài liệu PageSpeed Insights của Google năm 2024. Theo tài liệu chấm điểm của Lighthouse, bản Lighthouse 10 tính điểm này từ 5 chỉ số, trong đó tổng thời gian chặn (TBT) nặng nhất với 30%. INP không nằm trong 5 chỉ số đó.

  • Điểm đổi giữa các lần chạy vì quảng cáo, thử nghiệm A/B, đường truyền và phần mềm trên máy đo.
  • Ảnh chụp không cho biết đã đo URL nào, ở chế độ di động hay máy tính, vào lúc nào.
  • Điểm cao ở trang chủ không nói gì về trang sản phẩm hay trang bài viết, vốn dùng mẫu trang khác.
  • Ngay sau khi sửa, phần dữ liệu thực địa trên cùng trang kết quả vẫn gồm chủ yếu lượt truy cập cũ.
  • Điểm phòng thí nghiệm vẫn có ích để so trước và sau trên cùng một cấu hình đo.

Khi nào là mốc sớm nhất để nghiệm thu bằng số thật?

Mốc sớm nhất để nghiệm thu bằng số thật là khoảng ngày thứ 30 sau lần sửa cuối. Cần 28 ngày để cửa sổ dữ liệu chỉ còn lượt truy cập sau khi sửa, cộng khoảng 2 ngày dữ liệu về chậm. Mốc này là phép tính từ hai con số ấy, không phải mốc do Google công bố. Bấm nút bắt đầu theo dõi (Start Tracking) trong báo cáo Core Web Vitals sẽ mở một phiên giám sát 28 ngày, theo trợ giúp Search Console của Google năm 2026. Biên bản ký trước mốc ấy chỉ dựa được vào số phòng thí nghiệm hoặc số do hai bên tự thu.

  • API của CrUX cập nhật mỗi ngày nhưng chậm khoảng hai ngày so với ngày hiện tại, vì vậy nên hẹn nghiệm thu từ ngày thứ 30.
  • Cửa sổ dữ liệu trượt từng ngày, nên sau 14 ngày vẫn còn ít nhất một nửa số ngày trong cửa sổ thuộc về trước khi sửa. Trong lúc chờ, có thể xem bách phân vị 75 dịch dần từng tuần; đó là số pha trộn cũ và mới, chỉ nên ký sớm khi số pha trộn ấy đã ở mức tốt.
  • Sửa thành nhiều đợt thì thời gian chờ tính lại từ đợt cuối.
  • Hãy đề nghị nghiệm thu hai bước: bước kỹ thuật ngay sau khi sửa, bước kết quả khi đã đủ cửa sổ dữ liệu.
  • Số ghi trong biên bản nên là bách phân vị 75 trên di động của từng URL đã thống nhất từ đầu.

Website ít truy cập, không có dữ liệu thực địa thì nghiệm thu bằng gì?

Website ít truy cập có thể không có dữ liệu thực địa, vì CrUX chỉ gồm những trang và website đủ phổ biến. Google không công bố số lượt truy cập tối thiểu, theo tài liệu phương pháp của CrUX năm 2024. Khi đó hai bên nghiệm thu bằng số phòng thí nghiệm, với quy trình đo ghi sẵn trong hợp đồng. Tài liệu Lighthouse ghi nhận trung vị của 5 lần chạy ổn định gấp đôi một lần chạy đơn lẻ.

  • Ghi cố định danh sách URL theo từng mẫu trang, chế độ di động, công cụ đo và số lần chạy.
  • So trung vị trước và sau khi sửa, không so lần chạy đẹp nhất.
  • Có thể tự thu số của người dùng thật bằng thư viện web-vitals của nhóm Chrome, rồi tính bách phân vị 75.
  • Số tự thu chỉ so được khi mã đo được cài từ trước lúc sửa.
  • Trạng thái thiếu dữ liệu trong PageSpeed Insights không phải là lỗi của website.

Tối ưu tốc độ website có giúp tăng thứ hạng Google không?

Tối ưu tốc độ có thể hỗ trợ thứ hạng nhưng không bảo đảm thứ hạng. Google xác nhận hệ thống xếp hạng có dùng Core Web Vitals. Nhưng chỉ số tốt không bảo đảm vị trí đầu, theo tài liệu về trải nghiệm trang của Google Search Central năm 2026. Hiện chưa có số liệu nào được Google công bố về mức tăng thứ hạng khi trang chuyển sang đạt. Lợi ích có số đo nằm ở người dùng: website đạt ngưỡng có tỷ lệ bỏ dở lượt tải trang thấp hơn 24%, theo blog Chromium năm 2020.

  • Google cho biết vẫn ưu tiên nội dung phù hợp nhất, kể cả khi trải nghiệm trang chưa tốt.
  • Trải nghiệm trang góp phần rõ hơn khi nhiều trang cùng có nội dung hữu ích cho một truy vấn.
  • Con số 24% được đo với bộ ngưỡng của năm 2020, khi chỉ số phản hồi còn là FID chứ chưa phải INP.
  • Hợp đồng nên cam kết chỉ số tốc độ, không cam kết vị trí từ khoá; Google không nêu mức tăng thứ hạng nào để dựa vào.
  • Trang tải nhanh mà Google không thu thập hay lập chỉ mục được thì vẫn không có thứ hạng; hai việc ấy thuộc gói technical SEO.

Bảng 6 loại bằng chứng nghiệm thu tối ưu tốc độ website

Sáu loại bằng chứng hay gặp khi nghiệm thu khác nhau ở nguồn dữ liệu và thời điểm có số. Chỉ 2 loại có ngay sau khi sửa, và cả hai đều là số phòng thí nghiệm.

Bằng chứng Loại dữ liệu Có sớm nhất khi nào Chứng minh được gì Điểm yếu
Ảnh chụp điểm PageSpeed của một lần chạy Phòng thí nghiệm Ngay sau khi sửa Trang đã được thay đổi Điểm dao động giữa các lần chạy; không đo INP
Trung vị 5 lần chạy Lighthouse, cấu hình cố định Phòng thí nghiệm Ngay sau khi sửa Thay đổi có tác dụng trong điều kiện mô phỏng Không phải số của người dùng thật
Dữ liệu thực địa của URL trong PageSpeed Insights Thực địa, từ CrUX Khoảng ngày thứ 30 sau lần sửa cuối Người dùng thật của đúng trang đó đạt hay chưa URL ít truy cập không có số
Dữ liệu thực địa gộp của cả website Thực địa, từ CrUX Khoảng ngày thứ 30 sau lần sửa cuối Trải nghiệm chung của cả website Trang nhanh che mất trang chậm
Báo cáo Core Web Vitals trong Search Console Thực địa, gom theo nhóm URL Hết phiên giám sát 28 ngày Số URL chuyển từ kém sang tốt Chỉ hiện nhóm URL đủ dữ liệu; khó soi từng trang
Số tự thu bằng thư viện web-vitals Thực địa, tự đo Khi đủ số lượt truy cập hai bên thống nhất Trang ít truy cập vẫn có số của người dùng thật Phải cài trước khi sửa; hai bên phải thống nhất cách tính

Hạn chế của cách nghiệm thu này và khi nào không nên mua riêng

Nghiệm thu bằng dữ liệu thực địa có ba điểm yếu. Phải chờ đủ cửa sổ dữ liệu, nên đợt thanh toán cuối bị lùi lại. Website ít truy cập không có số để dùng. Số thực địa còn đổi theo thiết bị và đường truyền của khách, ngoài tầm kiểm soát của nhà cung cấp. Không nên mua riêng gói tối ưu tốc độ khi trang đã đạt Core Web Vitals, hoặc khi vấn đề chính là nội dung mỏng.

Mở PageSpeed Insights, dán URL quan trọng nhất và ghi lại phần dữ liệu thực địa trước khi ký hợp đồng. Sau đó gửi địa chỉ website qua trang Liên hệ của MOMD hoặc gọi 034 9324 993 để nhận bản audit miễn phí 30+ điểm trong 48 giờ.