Đo tốc độ
Năm trang chính được đo trên điện thoại bằng số thật và số phòng thí nghiệm, ghi sổ có ngày để so lại sau.
ONMATE / TỐI ƯU TỐC ĐỘ
Tối ưu tốc độ
Giúp khách xem nội dung và thao tác nhanh hơn trên website.
ONMATE đo hiệu suất website, xác định các yếu tố làm chậm và ưu tiên cải thiện theo mức ảnh hưởng đến người dùng. Kết quả được đo lại trong điều kiện tương đương, kết hợp dữ liệu thực tế khi có.
HÀNH TRÌNH TRÊN TỐI ƯU TỐC ĐỘ
Tối ưu tốc độ là đo trước, sửa theo tác động, đặt ngưỡng để website không chậm lại.
Một đợt tối ưu đi qua nhiều chặng, từ đo tới theo dõi. Chọn một chặng để xem việc ở đó.
Xử lý ảnh
Ảnh đổi cỡ, nén sang WebP, tải theo vị trí: ảnh đầu trang tải trước, ảnh bên dưới tải khi khách cuộn gần.
Gọn CSS và JavaScript
Tệp không dùng được gỡ, JavaScript hoãn, CSS màn hình đầu nằm trong trang. Menu, giỏ hàng, form thử lại sau mỗi lần sửa.
Máy chủ và bộ nhớ đệm
Tệp tĩnh giữ lâu ở trình duyệt, trang chung dựng sẵn ở máy chủ, trang riêng của khách không lưu, văn bản được nén.
Mã bên thứ ba
Mỗi mã đo, khung chat, video, phông chữ có người phụ trách và cách tải riêng: giữ, hoãn hoặc tự lưu.
Theo dõi
Ngân sách LCP, TBT, CLS và dung lượng có người phụ trách, kiểm tra hằng tuần, ghi nhật ký để website không chậm lại.
Sáu chặng quay quanh một điểm. Chọn một chặng để đọc chi tiết.
TỐI ƯU TỐC ĐỘ WEBSITE
SÁU PHẦN VIỆCChọn một phần việc để xem
Chọn một phần việc để xem
toàn bộ cách làm.
Mỗi phần việc có màn hình làm việc, đầu vào và cách đo riêng.
Chạm vào một thẻ để đổi nội dung bên dưới.
Đang xemĐo tốc độ trước khi sửaNội dung của thẻ Đo tốc độ trước khi sửaChọn thẻ khác
01
TRÔNG NHƯ THẾ NÀO
Đo tốc độ trông như thế nào.
Ba màn hình: báo cáo PageSpeed, số người dùng thật, biểu đồ thác DevTools. Bấm từng mục để xem.
PageSpeed Insights trang Danh mục nến
Trên: số thật 28 ngày: LCP 4,6 s, INP 310 ms, CLS 0,18, chưa đạt. Dưới: phòng thí nghiệm, điểm 58, LCP 5,1 s, TBT 420 ms.
Đọc tiếp
Số thật và số phòng thí nghiệm lệch nhau là bình thường. Số thật cho biết khách gặp gì; số phòng thí nghiệm để đo lại sau sửa.
MÔ PHỎNG · SỐ MẪU
pagespeed.web.dev
https://nhathom.example/nen-thomPhân tích
Thiết bị di độngMáy tính
Trải nghiệm thực của người dùng (28 ngày qua)
Chưa đạt đánh giá Core Web Vitals
LCP14,6 s
INP310 ms
CLS20,18
Kiểm tra trong phòng thí nghiệm
58Hiệu suất86Khả năng truy cập92Phương pháp hay nhất100SEO
Chỉ số
- First Contentful Paint2,8 s
- Largest Contentful Paint5,1 s
- Total Blocking Time420 ms
- Cumulative Layout Shift0,18
- Speed Index4,7 s
Cơ hội cải thiện3
- Giảm kích thước ảnh và dùng định dạng WebPTiết kiệm khoảng 2,1 s
- Hoãn tải ảnh nằm dưới màn hình đầuTiết kiệm khoảng 0,9 s
- Dành chỗ cố định cho ảnh và bannerGiảm xô lệch bố cục
- 1LCP: thời gian để phần nội dung lớn nhất hiện ra. Trên 4 giây là chậm.
- 2CLS: mức nhảy bố cục khi tải. Trên 0,1 là khó chịu khi bấm.
- 3Cơ hội cải thiện: PageSpeed tự gợi ý việc nên làm, xếp theo thời gian tiết kiệm được.
Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.
Số người dùng thật, tách thiết bị
Điện thoại: LCP 4,6 s, INP 310 ms, CLS 0,18; chỉ 44% lượt tải đạt LCP tốt. Máy tính tốt hơn: LCP 2,9 s, INP 120 ms.
Đọc tiếp
Hai nhóm khác nhau nhiều nên đo riêng. Đo trên máy tính ở văn phòng thấy website ổn, trong khi khách trên điện thoại chờ gần 5 giây.
MÔ PHỎNG · SỐ MẪU
cruxvis.withgoogle.com
https://nhathom.exampleCả website
Dữ liệu từ người dùng Chrome thật, 28 ngày tới 02/08/2026. Số lớn là giá trị p75: 75% lượt tải bằng hoặc nhanh hơn số này.
Điện thoại1
- LCP4,6 s44% tốt2
- INP310 ms70% tốt
- CLS0,1852% tốt
- FCP3,1 s38% tốt
- TTFB1,4 s41% tốt
Máy tính3
- LCP2,9 s66% tốt
- INP120 ms93% tốt
- CLS0,0684% tốt
- FCP1,6 s78% tốt
- TTFB0,9 s58% tốt
TốtCần cải thiệnKém
- 1Điện thoại: xem trước vì phần lớn khách vào bằng điện thoại. Số lớn là p75: 75% lượt tải bằng hoặc nhanh hơn.
- 2LCP 4,6 s, chỉ 44% lượt tải tốt. Hơn một phần tư lượt tải kém (thanh đỏ), nên chưa đạt Core Web Vitals.
- 3Máy tính: LCP 2,9 s, gần đạt. Cùng một website nhưng số hai loại thiết bị khác nhau, nên luôn đo riêng.
Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.
Biểu đồ thác DevTools: mỗi tệp một dòng
42 yêu cầu, 6,8 MB, mạng giả lập Fast 4G: DOMContentLoaded 2,10 s, tải xong 5,92 s. Dòng chọn: banner-nen-thom.jpg 1,84 MB, tải 3,7 s.
Đọc tiếp
Biểu đồ thác trả lời “chậm ở đâu”: tệp nào lớn, chặn, hay bắt đầu muộn. Điểm cho biết có chậm, biểu đồ cho biết vì sao.
MÔ PHỎNG · SỐ MẪU
nhathom.example/nen-thom
Phần tửBảng điều khiểnNguồnMạngHiệu suấtBộ nhớỨng dụngLighthouse
LọcTất cảTài liệuCSSJSẢnhPhôngFast 4G ▾1
TênTrạng tháiLoạiKích thướcThời gian01 s2 s3 s4 s5 s6 s
- nen-thom200document62 KB1,35 s
- nha-thom.css3200stylesheet118 KB0,82 s
- bieu-mau.css200stylesheet41 KB0,48 s
- main.min.js200script212 KB1,05 s
- slider.min.js200script188 KB0,94 s
- gtm.js?id=GTM-XXXXXXX200script96 KB0,66 s
- sdk.js200script71 KB0,72 s
- BeVietnamPro-Regular.ttf200font104 KB0,78 s
- banner-nen-thom.jpg2200jpeg1,84 MB3,70 s
- nen-nap-go-200g.jpg200jpeg318 KB2,10 s
- nen-ly-su-300g.jpg200jpeg296 KB2,30 s
- logo-nha-thom.png200png168 KB1,05 s
42 yêu cầu (hiển thị 12 dòng) · 6,8 MB đã truyền · DOMContentLoaded: 2,10 s · Tải xong: 5,92 s
- 1Giả lập “Fast 4G”: đo như mạng di động trung bình, không phải mạng văn phòng. Trước và sau dùng cùng mức mạng.
- 2banner-nen-thom.jpg nặng 1,84 MB, tải mất 3,7 s: tệp lớn nhất và cũng là phần tử LCP, nên kéo chậm cả trang.
- 3nha-thom.css chặn hiển thị: phải tải xong CSS mới vẽ trang. Đường xanh DOMContentLoaded 2,10 s, đường đỏ tải xong 5,92 s.
Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.
Tài liệu tham khảo:PageSpeed Insights: dữ liệu thực tế và phòng thí nghiệm ↗Chrome UX Report: dữ liệu người dùng thật ↗Chrome DevTools: tham khảo bảng Mạng ↗
02
LÀM NHƯ THẾ NÀO
Năm bước đo tốc độ.
Đo trước, sửa sau, đo lại cùng cách. Thiếu số trước thì chỉ còn cảm giác.
- 01Chọn 5 trang (chủ, danh mục, sản phẩm, giỏ hàng, liên hệ), cố định điện thoại và mạng 4G.
- 02Đọc số người dùng thật trước (Search Console, PageSpeed): LCP, INP, CLS ở phân vị 75 trên điện thoại.
- 03Đo phòng thí nghiệm bằng PageSpeed và biểu đồ thác DevTools: tệp nào chậm, nặng, chặn.
- 04Ghi sổ đo: mỗi trang một dòng (điểm, LCP, TBT, CLS, dung lượng, số yêu cầu), kèm ngày đo.
- 05Xếp việc theo tác động: tệp lớn nhất và LCP trước, rồi mã chặn, bên thứ ba, máy chủ.
Bạn đưa vào
- Địa chỉ website và 5 trang đại diện
- Quyền xem Search Console
- Thiết bị và mạng dùng để đo
- Ngày bắt đầu và mục tiêu
Số thật, số phòng thí nghiệm, sổ đoONMATE cùng doanh nghiệp
Bạn nhận lại
- Sổ đo trước khi sửa của 5 trang, nguyên nhân chậm từng trang, thứ tự việc kèm mục tiêu.
Tài liệu tham khảo:web.dev: Core Web Vitals ↗web.dev: khác biệt giữa dữ liệu thật và dữ liệu phòng thí nghiệm ↗Lighthouse: tổng quan ↗
03
CẦN CHUẨN BỊ GÌ
Cần chuẩn bị gì để đo tốc độ.
Cần địa chỉ website, vài trang quan trọng và (nếu có) quyền xem Search Console.
NGUYÊN TẮC
Sổ đo là bảng ngắn: mỗi trang một dòng, có điểm, LCP, TBT, CLS, dung lượng, ngày đo. Mọi lần đo cùng thiết bị, cùng mạng.
SỔ ĐO · SỐ MẪU
docs.google.com/spreadsheets
nhathom-so-do-toc-doTệp Chỉnh sửa Xem Chèn Định dạng Dữ liệu
| A | B | C | D | E | F | |
|---|---|---|---|---|---|---|
| 1 | Trang | Điểm | LCP | TBT | CLS | Dung lượng |
| 2 | Trang chủ | 61 | 4,7 s | 380 ms | 0,12 | 5,9 MB |
| 3 | Danh mục nến | 58 | 5,1 s1 | 420 ms | 0,18 | 6,8 MB2 |
| 4 | Trang sản phẩm | 64 | 4,4 s | 340 ms | 0,15 | 4,6 MB |
| 5 | Giỏ hàng | 72 | 3,6 s | 290 ms | 0,05 | 2,4 MB |
| 6 | Liên hệ | 803 | 2,9 s | 180 ms | 0,02 | 1,6 MB |
Trước khi sửaMục tiêu
- 1LCP 5,1 s ở trang Danh mục nến: chậm nhất và khách vào nhiều nhất, nên làm đầu tiên.
- 2Dung lượng 6,8 MB: gần 7 MB trên điện thoại là quá nặng. Ghi đủ 5 trang để biết trang nào nặng.
- 3Liên hệ 80 điểm: trang nhẹ nhất nên làm sau. Có số từng trang để xếp việc theo tác động, không dàn trải.
Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.
Đo trên điện thoại
Đa số khách dùng điện thoạiĐo năm trang, không chỉ trang chủ
Trang chậm hay là trang khácCùng thiết bị, cùng mạng
Trước và sau mới so đượcGhi ngày đo
Số đo đổi theo thời gianBộ tài nguyên4 mục
- KháchTrang nào quan trọng nhấtTrang đem lại đơn hoặc liên hệ.
- TệpQuyền xem Search ConsoleQuyền chỉ đọc, lấy số người dùng thật.
- ẢnhẢnh chụp báo cáo đang cóBáo cáo cũ, để đo lại cùng cách.
- BảngMã và tính năng đang gắnPlugin, mã đo, chat, bản đồ, video.
Xem đủ thông số và ghi chú
- Nguồn
- Ngưỡng “tốt” của Core Web Vitals web.dev nêu ngưỡng tốt tính ở phân vị 75 của lượt truy cập: LCP không quá 2,5 giây, INP không quá 200 ms, CLS không quá 0,1.
- Nguồn
- Số thật và số phòng thí nghiệm khác nhau web.dev giải thích dữ liệu thật đến từ người dùng với nhiều thiết bị và mạng khác nhau, còn dữ liệu phòng thí nghiệm đo trong điều kiện cố định, nên hai số thường lệch nhau và cả hai đều cần.
- Lưu ý
- Một lần đo chỉ là một con số PageSpeed chạy lại sẽ cho số hơi khác vì mạng và máy chủ thay đổi. Đo ba lần và ghi số ở giữa thay vì chọn lần đẹp nhất.
Tài liệu tham khảo:web.dev: Core Web Vitals ↗web.dev: khác biệt giữa dữ liệu thật và dữ liệu phòng thí nghiệm ↗Search Console: giới thiệu ↗
04
ĐO ĐIỀU GÌ
Đo bằng sổ so sánh trước và sau.
Sổ ghi cùng chỉ số trước và sau sửa, kèm số người dùng thật. Số phòng thí nghiệm cho biết ngay.
CẦN ĐO
Đọc LCP phòng thí nghiệm cạnh LCP thực tế. Chỉ kết luận sau 28 ngày.
SỔ SO SÁNH · SỐ MẪU
docs.google.com/spreadsheets
nhathom-so-sanh-truoc-sauTệp Chỉnh sửa Xem Chèn Định dạng Dữ liệu
| A | B | C | D | E | |
|---|---|---|---|---|---|
| 1 | Chỉ số | Trước 03/08 | Sau 31/08 | Thay đổi | Đánh giá |
| 2 | Điểm hiệu suất | 58 | 91 | +33 | Tốt |
| 3 | LCP (phòng thí nghiệm) | 5,1 s | 2,0 s | −3,1 s1 | Đạt |
| 4 | TBT | 420 ms | 90 ms | −330 ms | Đạt |
| 5 | CLS | 0,18 | 0,03 | −0,15 | Đạt |
| 6 | Dung lượng trang | 6,8 MB | 0,77 MB | −6,0 MB2 | Nhẹ |
| 7 | Số yêu cầu | 42 | 21 | −21 | Ít hơn |
| 8 | LCP thực tế (p75) | 4,6 s | 3,4 s | −1,2 s | Đang giảm3 |
Trang Danh mụcMọi trang
- 1LCP phòng thí nghiệm 5,1 → 2,0 s: đo lại được ngay sau khi sửa, cùng thiết bị và mạng giả lập.
- 2Dung lượng 6,8 → 0,77 MB, yêu cầu 42 → 21: phần lớn do ảnh. Khách cảm nhận rõ trên mạng di động.
- 3LCP thực tế 4,6 → 3,4 s, “Đang giảm”: dữ liệu thật là trung bình 28 ngày, chờ đủ 28 ngày mới chốt.
Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.
Cách đọc số · số mẫu
| Chỉ số | Cho biết | Cần xem lại khi |
|---|---|---|
| Điểm và LCP | Đo lại cùng thiết bị, cùng mạng | So với số đo trên thiết bị khác |
| Dung lượng, số yêu cầu | Giảm rõ ở lần tải đầu | Chỉ nhìn điểm số |
| LCP thực tế (p75) | Giảm dần, chốt sau 28 ngày | Kết luận sau vài ngày |
| Các trang | Có số của cả 5 trang | Chỉ đo trang chủ |
CÁCH ĐỌC
Mở sổ, đọc từ điểm xuống LCP thực tế.
Đọc tiếp
Ba dòng đầu cho biết sửa có tác dụng không; dòng cuối cho biết khách đã thấy chưa.
LƯU Ý
PageSpeed đổi nhẹ giữa các lần chạy.
Đọc tiếp
Đo ba lần, ghi số ở giữa. Số trong hình là số mẫu.
Tài liệu tham khảo:web.dev: khác biệt giữa dữ liệu thật và dữ liệu phòng thí nghiệm ↗Chrome UX Report: dữ liệu người dùng thật ↗web.dev: ngân sách hiệu suất ↗
05
CÁCH TRIỂN KHAI
Cách xử lý các tình huống thường gặp.
Số trong bảng là số mẫu để minh họa cách đọc, không phải kết quả dự kiến.
Chưa từng đo, chỉ cảm thấy chậm
Bắt đầu bằng PageSpeed cho 5 trang và ghi sổ đo trước khi chạm vào bất cứ thứ gì.
- Chọn 5 trang đại diện
- Chạy PageSpeed trên điện thoại, 3 lần mỗi trang
- Giả lập Fast 4G trong DevTools, ghi dung lượng và số yêu cầu
- Ghi sổ đo kèm ngày
Điểm cao nhưng khách vẫn kêu chậm
Xem số của người dùng thật theo thiết bị.
Đọc tiếp
Điểm phòng thí nghiệm cao không có nghĩa là khách trên mạng yếu thấy nhanh.
- Mở báo cáo Core Web Vitals trong Search Console
- Xem riêng điện thoại và so với máy tính
- Mở biểu đồ thác ở mạng chậm
- Ghi trang và thiết bị có số kém nhất
Đã sửa nhưng chưa biết có hiệu quả
Đo lại đúng cách đo ban đầu rồi so với sổ, thay vì đo bằng cách khác.
- Mở sổ đo trước khi sửa
- Đo lại cùng thiết bị, mạng và trang
- Ghi cột sau và cột thay đổi
- Chờ 28 ngày rồi đọc số thật
DẤU HIỆU
Điểm PageSpeed tốt nhưng Search Console vẫn báo kém
| Chỉ số | Giá trị |
|---|---|
| Điểm PageSpeed trang chính | 91, tốt |
| Nhóm URL bị báo | LCP trên 4 giây trên điện thoại |
| Việc cần làm | Đo từng trang trong nhóm rồi sửa theo nhóm |
Dữ liệu thật là trung bình 28 ngày và tính theo nhóm URL, nên có thể kém hơn số phòng thí nghiệm của một trang.
Đọc tiếp
Xem nhóm URL bị báo và đo từng trang trong nhóm.
DẤU HIỆU
Mỗi lần đo ra một số khác
| Chỉ số | Giá trị |
|---|---|
| Điểm của 3 lần đo | 88, 91, 84 |
| Số ghi vào sổ | 88 (số ở giữa) |
| Việc cần làm | Ghi cả ba số và số ở giữa |
Mạng và máy chủ thay đổi giữa các lần chạy.
Đọc tiếp
Đo ba lần, lấy số ở giữa, và luôn giữ cùng thiết bị.
DẤU HIỆU
Phòng thí nghiệm đạt mà số thật vẫn đỏ sau vài ngày
| Chỉ số | Giá trị |
|---|---|
| LCP phòng thí nghiệm | 2,0 s, đạt |
| LCP thực tế sau 4 ngày | 4,2 s, còn lẫn ngày cũ |
| Việc cần làm | Chờ đủ 28 ngày rồi mới kết luận |
Số thật là cửa sổ 28 ngày nên cần đủ thời gian để các ngày cũ trôi khỏi cửa sổ trước khi số cải thiện hết.
Tài liệu tham khảo:PageSpeed Insights: dữ liệu thực tế và phòng thí nghiệm ↗Chrome DevTools: tham khảo bảng Mạng ↗web.dev: khác biệt giữa dữ liệu thật và dữ liệu phòng thí nghiệm ↗
06
TRƯỚC KHI BẮT ĐẦU
Danh sách kiểm tra.
Đánh dấu từng mục để xem mức sẵn sàng. Trạng thái chỉ lưu trên trình duyệt của bạn.
0%SẴN SÀNG
Tài liệu tham khảo:web.dev: Core Web Vitals ↗web.dev: ngân sách hiệu suất ↗
Nội dung của thẻ Ảnh nhẹ mà vẫn nétChọn thẻ khác
01
TRÔNG NHƯ THẾ NÀO
Xử lý ảnh trông như thế nào.
Ba màn hình: báo cáo ảnh, nén bằng Squoosh, mã ảnh sau xử lý. Bấm từng mục để xem.
PageSpeed chỉ ra ảnh nào quá nặng
PageSpeed ước tính tiết kiệm 4.380 KB từ ảnh. Banner gốc 4000×1500 nặng 1.840 KB, nhưng điện thoại chỉ hiển thị khoảng 390 điểm ảnh ngang.
Đọc tiếp
Đọc cột “Gốc → hiển thị” trước: ảnh gốc lớn gấp nhiều lần ảnh hiển thị là chưa xử lý. Còn 9 ảnh khác cùng kiểu.
MÔ PHỎNG · SỐ MẪU
pagespeed.web.dev
https://nhathom.example/nen-thomĐiện thoại
Thay đổi kích thước, nén và đổi định dạng ảnhTiết kiệm ước tính 4.380 KB1
ẢnhGốc → hiển thị (điểm ảnh)TệpTiết kiệm
banner-nen-thom.jpg4000×1500 → 390×14621.840 KB1.720 KB
nen-nap-go-200g.jpg3024×3024 → 172×172318 KB260 KB
nen-ly-su-300g.jpg3024×3024 → 172×172296 KB238 KB
nen-hoa-hong.jpg2800×2800 → 172×172287 KB229 KB
logo-nha-thom.png3000×800 → 120×323168 KB164 KB
Còn 9 ảnh khác, cùng kiểu: ảnh gốc từ máy ảnh, đưa thẳng lên website.
- 1Tiết kiệm ước tính 4.380 KB chỉ từ ảnh: tệp hiện tại trừ tệp sau khi đổi cỡ, nén, đổi định dạng.
- 2banner-nen-thom.jpg: ảnh gốc 4000×1500 điểm ảnh, điện thoại chỉ hiển thị 390 điểm ngang. Tệp 1.840 KB nhưng cần khoảng 120 KB.
- 3logo-nha-thom.png 168 KB cho logo rộng 120 điểm ảnh: nên dùng tệp vẽ bằng nét (SVG) hoặc ảnh nhỏ vài KB.
Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.
Đổi cỡ và nén sang WebP bằng Squoosh
Ảnh sản phẩm 3024×3024 JPEG 318 KB đổi về 800×800, lưu WebP chất lượng 80, còn 54 KB, nhẹ hơn 83%. So bằng mắt hai nửa hình.
Đọc tiếp
Squoosh chạy ngay trong trình duyệt trên máy bạn. Nếu một ảnh nhìn khác rõ ở chất lượng 80 thì nâng riêng ảnh đó lên 85.
MÔ PHỎNG · SỐ MẪU
squoosh.app
Original
WebP
nen-nap-go-200g.jpg
3024×3024JPEG · 318 KB1
Resize
8008002
WebP
803
4
54 KB83% smaller
- 1Ảnh gốc 3024×3024, JPEG 318 KB: chụp từ điện thoại, đưa thẳng lên website. Khung hiển thị chỉ cần cỡ nhỏ hơn nhiều.
- 2Đổi cỡ về 800×800: đủ nét cho khung hiển thị khoảng 400 điểm ảnh, kể cả màn hình có độ phân giải gấp đôi.
- 3WebP, chất lượng 80: 318 KB còn 54 KB, nhẹ hơn 83%. So hai ảnh bằng mắt, chưa thấy khác biệt là đủ.
Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.
Mã ảnh: cỡ, ưu tiên và tải trễ
Banner có srcset hai cỡ (640 và 1280), khai báo sẵn chiều rộng, chiều cao và fetchpriority="high". Ảnh sản phẩm có loading="lazy". Hai vị trí, hai cách.
Đọc tiếp
Ảnh đầu trang là phần tử LCP nên không được tải trễ. Đặt loading="lazy" nhầm vào ảnh này làm LCP chậm hơn.
MÔ PHỎNG · SỐ MẪU
view-source:nhathom.example/nen-thom
nen-thom (mã nguồn)
1<!-- Ảnh đầu trang (LCP): tải ngay, ưu tiên cao, có kích thước -->2<img src="/anh/banner-nen-thom-1280.webp"3srcset="/anh/banner-nen-thom-640.webp 640w,4/anh/banner-nen-thom-1280.webp 1280w"5sizes="100vw" width="1280" height="480"6fetchpriority="high" alt="Bộ sưu tập nến thơm mùa Thu">78<!-- Ảnh sản phẩm bên dưới: chỉ tải khi khách cuộn gần tới -->9<img src="/anh/nen-nap-go-200g-800.webp"10width="800" height="800" loading="lazy" decoding="async"11alt="Nến thơm nắp gỗ 200 g">
- Dòng 3 và 4: srcset cho hai cỡ ảnh, 640 và 1280 điểm. Điện thoại tự chọn bản 640, máy tính bản 1280.
- Dòng 5 và 6: chiều rộng, chiều cao để dành chỗ (đỡ xô lệch bố cục), fetchpriority="high" để ảnh đầu trang tải trước.
- Dòng 10: loading="lazy" cho ảnh dưới màn hình đầu, chỉ tải khi cuộn tới. Không đặt cho ảnh đầu trang, kẻo LCP chậm.
Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.
Tài liệu tham khảo:web.dev: dùng ảnh WebP ↗web.dev: tải ảnh trễ ở cấp trình duyệt ↗web.dev: không tải trễ ảnh LCP ↗
02
LÀM NHƯ THẾ NÀO
Năm bước xử lý ảnh.
Làm từ ảnh quan trọng nhất ra. Ảnh đầu trang quyết định LCP, xử lý trước.
- 01Liệt kê ảnh theo vị trí: ảnh đầu trang (phần tử LCP), ảnh sản phẩm bên dưới, logo.
- 02Đổi cỡ theo khung hiển thị lớn nhất (gấp đôi cho màn nét cao), không giữ cỡ máy ảnh.
- 03Nén và đổi sang WebP, chất lượng khoảng 80. Xem một ảnh mẫu rồi mới áp dụng cả nhóm.
- 04Khai báo srcset, chiều rộng, chiều cao. Ảnh đầu trang tải ngay, ưu tiên cao; ảnh dưới đặt loading="lazy".
- 05Đo lại bằng PageSpeed và DevTools, ghi dung lượng khi tải hết và dung lượng trước khi cuộn vào sổ.
Bạn đưa vào
- Ảnh gốc chất lượng cao
- Danh sách trang có nhiều ảnh
- Quyền sửa giao diện hoặc plugin ảnh
- Nơi giữ bản gốc để dùng lại
Đổi cỡ, nén WebP, tải theo vị tríONMATE cùng doanh nghiệp
Bạn nhận lại
- Bộ ảnh xử lý, kế hoạch tải theo vị trí, mã ảnh có srcset và tải trễ, bảng so dung lượng.
Tài liệu tham khảo:web.dev: dùng ảnh WebP ↗web.dev: hình ảnh ↗web.dev: ưu tiên tải tài nguyên (Fetch Priority) ↗
03
CẦN CHUẨN BỊ GÌ
Cần chuẩn bị gì để xử lý ảnh.
Cần ảnh gốc chất lượng cao và quyền sửa giao diện hoặc cài plugin.
NGUYÊN TẮC
Kế hoạch ảnh là bảng ngắn: nhóm, số ảnh, cỡ gốc, cỡ mới, định dạng, cách tải. Ảnh đầu trang tải ngay, ảnh dưới tải trễ.
KẾ HOẠCH ẢNH · MẪU
docs.google.com/spreadsheets
nhathom-ke-hoach-anhTệp Chỉnh sửa Xem Chèn Định dạng Dữ liệu
| A | B | C | D | E | F | |
|---|---|---|---|---|---|---|
| 1 | Nhóm ảnh | Số ảnh | Cỡ gốc | Cỡ mới | Định dạng | Cách tải |
| 2 | Banner đầu trang | 1 | 4000×1500 | 1280×480 | WebP, mức 80 | Tải ngay, ưu tiên1 |
| 3 | Ảnh sản phẩm | 12 | 3024×3024 | 800×8003 | WebP, mức 80 | Tải khi cuộn tới2 |
| 4 | Logo | 1 | 3000×800 | 240×64 | SVG | Tải ngay |
Kế hoạchKết quả
- 1Banner đầu trang tải ngay, ưu tiên cao: đây là phần tử LCP nên cần có sớm nhất, không đặt tải khi cuộn.
- 2Ảnh sản phẩm tải khi cuộn tới: 12 ảnh nằm dưới màn hình đầu, nên lần tải đầu nhẹ đi phần lớn.
- 3Cỡ mới 800×800: đủ nét cho khung khoảng 400 điểm ảnh trên màn hình phân giải cao, nhỏ hơn nhiều ảnh gốc 3024×3024.
Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.
Cỡ theo khung hiển thị
Không giữ cỡ ảnh máy ảnhẢnh đầu trang tải ngay
Ưu tiên cao, không tải trễẢnh bên dưới tải trễ
Chỉ tải khi sắp thấyXem bằng mắt
Mờ thì tăng riêng ảnh đóBộ tài nguyên4 mục
- KháchẢnh nào quan trọng nhấtBanner, sản phẩm chủ lực.
- TệpẢnh gốc và quyền sửaẢnh gốc từ máy ảnh, quyền quản trị.
- ẢnhẢnh báo cáo PageSpeedMục ảnh nặng nhất trong báo cáo.
- BảngDanh sách ảnh theo trangẢnh ở trang nào, ảnh nào đầu trang.
Xem đủ thông số và ghi chú
- Nguồn
- WebP thường nhẹ hơn JPEG và PNG web.dev nêu ảnh WebP thường nhỏ hơn JPEG và PNG ở chất lượng tương đương và được các trình duyệt phổ biến hỗ trợ.
- Nguồn
- Ảnh LCP không nên tải trễ web.dev về LCP nêu ảnh LCP không nên đặt tải trễ vì làm chậm LCP, và nên ưu tiên tải sớm cho ảnh này.
- Lưu ý
- Nén quá tay làm ảnh sản phẩm mờ Ảnh sản phẩm cần nhìn rõ chất liệu và màu. Xem bằng mắt trước khi áp dụng cho cả nhóm và giữ bản gốc để nén lại khi cần.
Tài liệu tham khảo:web.dev: dùng ảnh WebP ↗web.dev: không tải trễ ảnh LCP ↗
04
ĐO ĐIỀU GÌ
Đo bằng dung lượng trước và sau.
Bảng ghi dung lượng ảnh trước, sau, tỷ lệ giảm, kèm số tải khi tải hết và trước khi cuộn.
CẦN ĐO
Đọc dòng “Tải trước khi cuộn” trước: khách phải chờ phần này.
KẾT QUẢ ẢNH · SỐ MẪU
docs.google.com/spreadsheets
nhathom-ket-qua-anhTệp Chỉnh sửa Xem Chèn Định dạng Dữ liệu
| A | B | C | D | E | |
|---|---|---|---|---|---|
| 1 | Nhóm ảnh | Ảnh | Trước | Sau | Giảm |
| 2 | Banner đầu trang | 1 | 1.840 KB | 120 KB | −93%1 |
| 3 | Ảnh sản phẩm | 12 | 3.192 KB | 696 KB | −78% |
| 4 | Logo | 1 | 168 KB | 4 KB | −98% |
| 5 | Tổng khi tải hết | 14 | 5.200 KB | 820 KB | −84%2 |
| 6 | Tải trước khi cuộn | 14 → 6 | 5.200 KB | 356 KB3 | −93% |
Kế hoạchKết quả
- 1Banner −93% (1.840 → 120 KB): ảnh quyết định LCP nên mức giảm này ảnh hưởng lớn nhất tới tốc độ khách cảm nhận.
- 2Tổng khi tải hết 5.200 → 820 KB (−84%): đây là mức giảm khi khách cuộn xem toàn bộ trang.
- 3Tải trước khi cuộn chỉ còn 356 KB trong 6 ảnh: phần khách phải chờ lúc vào trang, số cần theo dõi nhất.
Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.
Cách đọc số · số mẫu
| Chỉ số | Cho biết | Cần xem lại khi |
|---|---|---|
| Banner đầu trang | Giảm mạnh, LCP sớm hơn | Banner vẫn là tệp lớn nhất |
| Ảnh sản phẩm | Giảm 70% trở lên, ảnh vẫn nét | Mờ khi nhìn chi tiết |
| Tải trước khi cuộn | Chỉ vài trăm KB | Vẫn vài MB vì chưa tải trễ |
| Số ảnh tải lần đầu | Ít hơn tổng số ảnh | Bằng tổng số ảnh |
CÁCH ĐỌC
Mở bảng, đọc từ banner xuống.
Đọc tiếp
Banner và dòng “trước khi cuộn” quyết định cảm giác tải trang. Ảnh sản phẩm nằm dưới, khách chỉ thấy khi cuộn.
LƯU Ý
WebP nhẹ hơn nhưng ảnh nhiều chi tiết giảm ít hơn.
Đọc tiếp
Số trong hình là số mẫu.
Tài liệu tham khảo:web.dev: dùng ảnh WebP ↗PageSpeed Insights: dữ liệu thực tế và phòng thí nghiệm ↗
05
CÁCH TRIỂN KHAI
Cách xử lý các tình huống thường gặp.
Số trong bảng là số mẫu để minh họa cách đọc, không phải kết quả dự kiến.
Ảnh gốc từ máy ảnh đưa thẳng lên website
Xử lý lại cả bộ ảnh theo nhóm, bắt đầu từ ảnh đầu trang rồi tới ảnh sản phẩm.
- Đổi cỡ ảnh đầu trang
- Nén WebP chất lượng 80 và xem bằng mắt
- Thay ảnh trên website, kiểm tra trên điện thoại
- Làm tiếp ảnh sản phẩm theo nhóm
Website WordPress có hàng trăm ảnh
Dùng plugin xử lý ảnh để làm hàng loạt (đổi cỡ, nén, WebP, tải trễ), nhưng thử trên bản thử trước.
- Sao lưu thư viện ảnh
- Cài plugin trên bản thử
- Đặt WebP chất lượng 80 và tải trễ
- Kiểm tra ảnh trên điện thoại rồi áp dụng
Ảnh đã nén nhưng LCP vẫn chậm
Kiểm tra ảnh LCP có bị đặt tải trễ hoặc thiếu ưu tiên không, rồi xem ảnh có đúng cỡ không.
- Xác định phần tử LCP trong PageSpeed
- Kiểm tra có loading="lazy" nhầm không
- Thêm fetchpriority="high"
- Đo lại LCP
DẤU HIỆU
PageSpeed vẫn báo đổi cỡ ảnh sau khi đã nén
| Chỉ số | Giá trị |
|---|---|
| Ảnh sản phẩm sau nén | 3024×3024, 140 KB |
| Khung hiển thị | 172×172 trên điện thoại |
| Việc cần làm | Đổi về 800×800 rồi nén lại |
Nén giảm dung lượng nhưng số điểm ảnh vẫn lớn hơn khung hiển thị.
Đọc tiếp
Cần đổi cỡ, không chỉ nén.
DẤU HIỆU
Ảnh banner nhìn mờ trên màn hình lớn
| Chỉ số | Giá trị |
|---|---|
| Ảnh banner | 640×240, chất lượng 60 |
| Màn hình | 1920 điểm ảnh ngang |
| Việc cần làm | Thêm bản 1280, chất lượng 80 |
Cỡ đổi quá nhỏ hoặc chất lượng nén thấp.
Đọc tiếp
Thêm bản 1280 vào srcset hoặc nâng chất lượng.
DẤU HIỆU
Trang nhảy khi ảnh tải xong
| Chỉ số | Giá trị |
|---|---|
| CLS | 0,18 |
| Ảnh thiếu kích thước | Banner và 12 ảnh sản phẩm |
| Việc cần làm | Khai báo width, height cho mọi ảnh |
Ảnh chưa khai báo chiều rộng và chiều cao nên trình duyệt chưa dành chỗ.
Đọc tiếp
Thêm hai thuộc tính này cho mọi ảnh.
Tài liệu tham khảo:web.dev: tải ảnh trễ ở cấp trình duyệt ↗web.dev: không tải trễ ảnh LCP ↗web.dev: ưu tiên tải tài nguyên (Fetch Priority) ↗
06
TRƯỚC KHI BẮT ĐẦU
Danh sách kiểm tra.
Đánh dấu từng mục để xem mức sẵn sàng. Trạng thái chỉ lưu trên trình duyệt của bạn.
0%SẴN SÀNG
Tài liệu tham khảo:web.dev: không tải trễ ảnh LCP ↗web.dev: tải ảnh trễ ở cấp trình duyệt ↗web.dev: CLS ↗
Nội dung của thẻ Gỡ, hoãn, nhúng CSS và JSChọn thẻ khác
01
TRÔNG NHƯ THẾ NÀO
Tối ưu CSS và JavaScript trông như thế nào.
Ba màn hình: Mức độ phủ, cài đặt tối ưu, phần head đã sắp xếp. Bấm từng mục để xem.
DevTools chỉ ra tệp tải mà không dùng
Bảng 6 tệp lớn nhất: slider.min.js không dùng 100% (plugin cũ đã tắt), main.min.js 70%, nha-thom.css 81%. Toàn bảng: 782 KB trên 1,15 MB chưa dùng (68%).
Đọc tiếp
Thao tác như khách trước khi dừng ghi. Tệp “không dùng” ở trang này có thể cần ở trang khác; chỉ gỡ hẳn khi không trang nào cần.
MÔ PHỎNG · SỐ MẪU
nhathom.example/nen-thom
Bảng điều khiểnMức độ phủ
Tất cảCSSJavaScriptTheo từng tệp ▾
URLLoạiTổng số byteByte không dùngMức sử dụng
- …/plugins/slider-anh-cu/js/slider.min.js1JS188.120188.120100,0%
- …/themes/nha-thom/js/main.min.js2JS212.480148.90070,1%
- …/themes/nha-thom/nha-thom.cssCSS118.40296.21081,3%
- …/wp-includes/js/jquery/jquery.min.jsJS89.47655.48062,0%
- …/plugins/bieu-mau/css/bieu-mau.cssCSS41.22039.87096,7%
- …/plugins/slider-anh-cu/css/slider.cssCSS38.01038.010100,0%
782 KB trên 1,15 MB (68%) byte chưa được dùng. Hiển thị 6 trong 23 tệp.3
- 1slider.min.js dùng 0%: plugin Slider ảnh cũ đã tắt nhưng tệp vẫn tải trên mọi trang. Đơn giản nhất là gỡ hẳn plugin.
- 2main.min.js dùng 30%: cần cho giao diện nên không xóa được. Hoãn tải (defer) và tách phần chỉ dùng ở trang riêng.
- 3Cuối bảng: 782 KB không dùng trên 1,15 MB (68%). Đo khi mở trang, ghi và dùng thử vài thao tác thường gặp.
Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.
Tối ưu tệp trong plugin bộ nhớ đệm
Thu gọn CSS và JavaScript đang bật. Gộp CSS tắt vì tải song song nhanh hơn. Hoãn JavaScript bật, trừ jquery.min.js; tệp biểu mẫu chỉ tải ở /lien-he.
Đọc tiếp
Mỗi lựa chọn cần bật rồi đo lại: có website nhanh hơn, có website lỗi giao diện. Danh sách “không hoãn” ghi tệp giao diện cần ngay.
MÔ PHỎNG · SỐ MẪU
Lưu thay đổi
nhathom.example/wp-admin/options-general.php?page=bo-nho-dem&tab=toi-uu-tep
WBảng điều khiểnNhà Thơm (mẫu)N
Bảng tinBài viếtMediaTrangGiao diệnPluginThành viênCông cụCài đặt
Bộ nhớ đệm trang
Phiên bản 1.6.3Bộ nhớ đệmTối ưu tệpẢnhNâng cao
CSS
Để tắt: tải song song nhanh hơn
JavaScript
jquery.min.js2
Tệp theo từng trang3
| Tệp | Chỉ tải ở | Trạng thái |
|---|---|---|
bieu-mau.css, bieu-mau.js | /lien-he | Bật |
slider-anh-cu | Không trang nào | Plugin đã tắt |
- 1Hoãn tải JavaScript (defer): tệp JS không chặn việc vẽ trang. Bật xong thử menu, giỏ hàng, biểu mẫu xem còn chạy đủ.
- 2Loại jquery.min.js khỏi danh sách hoãn: theme gọi jQuery ngay khi tải, hoãn thì menu và giỏ hàng lỗi. Phải thử mới biết.
- 3Tệp theo từng trang: biểu mẫu liên hệ chỉ tải CSS, JS ở /lien-he. Plugin slider đã tắt nên không trang nào tải.
Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.
Phần head sau khi sắp xếp lại
Phông chữ được preload, CSS màn hình đầu nằm thẳng trong trang, CSS còn lại tải với media="print" rồi đổi sang all, JavaScript có defer.
Đọc tiếp
Tải CSS bằng media="print" là kỹ thuật web.dev mô tả để hoãn CSS phụ. Thiếu CSS màn hình đầu thì trang chớp chữ không kiểu; thử trên điện thoại.
MÔ PHỎNG · SỐ MẪU
view-source:nhathom.example/nen-thom
nen-thom (phần head)
1<head>2<meta charset="utf-8">3<meta name="viewport" content="width=device-width, initial-scale=1">4<title>Nến thơm – Quà tặng | Nhà Thơm (mẫu)</title>5<!-- Phông chữ tự lưu trên máy chủ, tải sớm -->6<link rel="preload" href="/phong/be-vietnam-pro-400.woff2"7as="font" type="font/woff2" crossorigin>8<!-- CSS cho màn hình đầu: đặt thẳng trong trang -->9<style>10@font-face{font-family:"Be Vietnam Pro";font-weight:400;11src:url(/phong/be-vietnam-pro-400.woff2) format("woff2");12font-display:swap}13/* … 6 KB: tiêu đề, banner, lưới sản phẩm … */14</style>15<!-- CSS còn lại: tải không chặn hiển thị -->16<link rel="stylesheet" href="/css/nha-thom.min.css?v=2.4"17media="print" onload="this.media='all'">18<script src="/js/nha-thom.min.js?v=2.4" defer></script>19</head>
- Dòng 6, 7: preload tải phông sớm, vì trình duyệt chỉ biết cần phông sau khi đọc CSS. Phông tự lưu trên máy chủ.
- Dòng 12: font-display:swap cho hiện chữ bằng phông tạm ngay, rồi đổi sang phông thật khi tải xong, khách khỏi nhìn khoảng trắng.
- Dòng 16 đến 18: CSS còn lại tải không chặn hiển thị, JavaScript có defer. CSS màn hình đầu nằm sẵn trong trang.
Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.
Tài liệu tham khảo:Chrome DevTools: mức độ phủ mã ↗web.dev: hoãn CSS không quan trọng ↗Lighthouse: loại bỏ tài nguyên chặn hiển thị ↗
02
LÀM NHƯ THẾ NÀO
Năm bước tối ưu CSS và JavaScript.
Gỡ trước, hoãn sau, giữ nguyên sau cùng. Gỡ phần không dùng rẻ nhất.
- 01Mở DevTools, tab Mức độ phủ, thao tác như khách, ghi tệp nào không dùng bao nhiêu phần trăm.
- 02Gỡ thứ không còn dùng: plugin đã tắt, mã đo cũ, phông chữ thừa. Ít rủi ro nhất.
- 03Tệp cần giữ: thu gọn, hoãn JavaScript (defer), tải CSS không chặn, đặt CSS màn hình đầu trong trang.
- 04Loại tệp “phải giữ” khỏi việc hoãn, như jQuery; tệp riêng chỉ tải ở trang cần.
- 05Sau mỗi thay đổi, thử menu, giỏ hàng, biểu mẫu trên điện thoại và đo lại. Lỗi thì hoàn tác.
Bạn đưa vào
- Quyền quản trị WordPress
- Bản thử của website
- Danh sách plugin đang bật
- Điện thoại thật để thử
Đo mức dùng, gỡ, hoãn, thử lạiONMATE cùng doanh nghiệp
Bạn nhận lại
- Danh sách tệp kèm cách xử lý, cấu hình đã thử trên bản thử, phần head mới, bảng dung lượng.
Tài liệu tham khảo:Chrome DevTools: mức độ phủ mã ↗Lighthouse: giảm JavaScript không dùng ↗web.dev: hoãn CSS không quan trọng ↗
03
CẦN CHUẨN BỊ GÌ
Cần chuẩn bị gì để tối ưu CSS và JavaScript.
Cần quyền quản trị, một bản thử và danh sách plugin đang bật.
NGUYÊN TẮC
Bảng tệp: tên tệp, loại, phần trăm không dùng, cách xử lý, trạng thái. Mỗi tệp một cách: gỡ, hoãn hoặc giữ, kèm lý do.
TỆP CSS, JS · MẪU
docs.google.com/spreadsheets
nhathom-tep-css-jsTệp Chỉnh sửa Xem Chèn Định dạng Dữ liệu
| A | B | C | D | E | |
|---|---|---|---|---|---|
| 1 | Tệp | Loại | Không dùng | Cách xử lý | Trạng thái |
| 2 | slider.min.js | JS | 100% | Gỡ plugin cũ1 | Đã gỡ |
| 3 | main.min.js | JS | 70% | Hoãn tải (defer)2 | Đã làm |
| 4 | nha-thom.css | CSS | 81% | CSS đầu trang nhúng thẳng | Đã làm |
| 5 | jquery.min.js | JS | 62% | Giữ, không hoãn3 | Giữ |
| 6 | bieu-mau.css | CSS | 97% | Chỉ tải ở /lien-he | Đã làm |
| 7 | slider.css | CSS | 100% | Gỡ cùng plugin | Đã gỡ |
Cần xử lýĐã làm
- 1slider.min.js không dùng 100%: plugin đã tắt từ lâu nhưng tệp vẫn tải. Gỡ plugin là gọn nhất, không cần chỉnh thêm.
- 2main.min.js không dùng 70% nhưng giao diện cần, không xóa được. Hoãn tải để khỏi chặn, rồi thử lại menu, giỏ hàng.
- 3jquery.min.js giữ nguyên, không hoãn: theme cần ngay khi tải. Ghi lý do ra cột Trạng thái để lần sau không ai hoãn nhầm.
Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.
Đo trước khi gỡ
Số liệu từ Mức độ phủMỗi tệp một cách xử lý
Gỡ, hoãn hay giữThử trên bản thử
Rồi mới lên website chínhGhi lý do giữ
Tránh hoãn nhầm lần sauBộ tài nguyên4 mục
- KháchTính năng nào không thể mấtMenu, giỏ hàng, biểu mẫu, bộ lọc.
- TệpQuyền quản trị, bản thửKèm danh sách plugin đang bật.
- ẢnhẢnh chụp báo cáo LighthouseHai mục tài nguyên chặn, JS không dùng.
- BảngMã dán thêm vào giao diệnMã đo, chat, bản đồ trong chân trang.
Xem đủ thông số và ghi chú
- Nguồn
- Tài nguyên chặn hiển thị làm chậm lần vẽ đầu Lighthouse nêu CSS và JavaScript đồng bộ trong head có thể chặn việc hiển thị trang, và gợi ý nhúng phần quan trọng, hoãn phần còn lại.
- Nguồn
- Mức độ phủ đo phần được dùng Tài liệu DevTools mô tả bảng Mức độ phủ cho biết bao nhiêu phần trăm CSS và JavaScript đã tải thật sự được dùng trong lúc ghi.
- Lưu ý
- “Không dùng” chỉ đúng với thao tác đã thử Mã dùng khi bấm giỏ hàng sẽ hiện là chưa dùng nếu lúc ghi không bấm. Thao tác đủ các luồng chính trước khi gỡ.
Tài liệu tham khảo:Lighthouse: loại bỏ tài nguyên chặn hiển thị ↗Chrome DevTools: mức độ phủ mã ↗
04
ĐO ĐIỀU GÌ
Đo bằng dung lượng theo loại tệp.
Bảng dung lượng theo loại tệp, trước và sau, kèm số yêu cầu. Thấy loại nào còn nặng.
CẦN ĐO
Đọc Giảm rồi Yêu cầu. CSS giảm cả hai là tốt; JS giảm ít vẫn ổn.
DUNG LƯỢNG THEO LOẠI · SỐ MẪU
docs.google.com/spreadsheets
nhathom-dung-luong-theo-loaiTệp Chỉnh sửa Xem Chèn Định dạng Dữ liệu
| A | B | C | D | E | |
|---|---|---|---|---|---|
| 1 | Loại tệp | Trước (KB) | Sau (KB) | Giảm | Yêu cầu |
| 2 | HTML | 62 | 14 | −77% | 1 → 1 |
| 3 | CSS | 310 | 38 | −88% | 9 → 3 |
| 4 | JavaScript | 840 | 303 | −64%1 | 14 → 8 |
| 5 | Phông chữ | 318 | 44 | −86% | 3 → 2 |
| 6 | Ảnh | 5.200 | 356 | −93%2 | 14 → 6 |
| 7 | Khác | 62 | 11 | −82% | 1 → 1 |
| 8 | Tổng | 6.792 | 766 | −89%3 | 42 → 21 |
Theo loại tệpTheo trang
- 1JavaScript giảm ít nhất (−64%): 303 KB còn lại là theme, giỏ hàng, đo lường. Khó giảm thêm nếu không đổi cách xây.
- 2Ảnh −93% (5.200 → 356 KB) chiếm khoảng 80% tổng mức giảm, nên ảnh là việc đầu tiên khi tối ưu tốc độ.
- 3Tổng 6.792 → 766 KB, 42 → 21 yêu cầu, đo ở lần tải đầu (chưa cuộn). Ảnh dưới tải thêm khi cuộn.
Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.
Cách đọc số · số mẫu
| Chỉ số | Cho biết | Cần xem lại khi |
|---|---|---|
| CSS | Giảm dung lượng và số tệp | Tăng khi cài thêm plugin |
| JavaScript | Giảm sau khi gỡ và hoãn tải | Giữ nguyên dù đã gỡ plugin |
| Phông chữ | Ít tệp hơn, nhẹ hơn | Nhiều phông từ nơi khác |
| Dòng tổng | Giảm, số yêu cầu giảm theo | Chỉ có dung lượng giảm |
CÁCH ĐỌC
Mở bảng, nhìn dòng Tổng rồi đi ngược lên để biết loại nào đóng góp nhiều nhất.
Đọc tiếp
Dòng nào gần như không đổi là dòng cần xem lại.
LƯU Ý
Dung lượng đo ở lần tải đầu.
Đọc tiếp
Giỏ hàng, liên hệ có thể có tệp riêng. Số trong hình là số mẫu.
Tài liệu tham khảo:Lighthouse: giảm JavaScript không dùng ↗web.dev: giảm dung lượng tải bằng nén văn bản ↗
05
CÁCH TRIỂN KHAI
Cách xử lý các tình huống thường gặp.
Số trong bảng là số mẫu để minh họa cách đọc, không phải kết quả dự kiến.
Nhiều plugin cũ, không rõ plugin nào còn dùng
Bắt đầu bằng Mức độ phủ để biết tệp nào không dùng, rồi gỡ plugin thừa trước khi tối ưu tệp.
- Ghi Mức độ phủ ở 3 trang chính
- Đối chiếu tệp với danh sách plugin
- Tắt thử từng plugin trên bản thử
- Gỡ plugin không còn cần
Bật tối ưu tệp làm lỗi giao diện
Bật từng lựa chọn một, thử rồi mới bật tiếp, thay vì bật tất cả cùng lúc.
- Tắt mọi lựa chọn tối ưu tệp
- Bật Thu gọn, thử menu, giỏ hàng, biểu mẫu
- Bật Hoãn tải JavaScript, thử lại
- Loại trừ tệp gây lỗi và ghi lý do
TBT cao dù tệp đã nhẹ
Có thể do JavaScript chạy lâu hoặc do mã bên thứ ba.
Đọc tiếp
Xem tác vụ dài rồi tách hoặc hoãn.
- Xem tác vụ dài trong tab Hiệu suất
- Tìm tệp tạo ra tác vụ dài
- Hoãn hoặc tách tệp đó
- Đo lại TBT
DẤU HIỆU
Menu hoặc giỏ hàng không bấm được sau khi bật hoãn JavaScript
| Chỉ số | Giá trị |
|---|---|
| Tệp bị hoãn | jquery.min.js |
| Lỗi trong bảng điều khiển | jQuery is not defined |
| Việc cần làm | Loại jquery.min.js khỏi danh sách hoãn |
Một tệp mà giao diện cần ngay (thường là jQuery) đã bị hoãn.
Đọc tiếp
Loại tệp đó ra khỏi danh sách hoãn.
DẤU HIỆU
Trang hiện chữ không có kiểu rồi mới có kiểu
| Chỉ số | Giá trị |
|---|---|
| Hiện tượng | Chữ thô rồi mới có kiểu |
| Nguyên nhân | CSS nhúng thiếu quy tắc |
| Việc cần làm | Thêm quy tắc vào CSS màn hình đầu |
CSS màn hình đầu chưa đủ nên trình duyệt vẽ trước khi CSS còn lại tải xong.
Đọc tiếp
Bổ sung phần thiếu vào CSS nhúng.
DẤU HIỆU
Gỡ plugin xong thì một khối bị vỡ
| Chỉ số | Giá trị |
|---|---|
| Khối bị vỡ | Trình chiếu ở trang chủ |
| Nguyên nhân | Khối còn gọi plugin cũ |
| Việc cần làm | Thay bằng ảnh tĩnh rồi gỡ plugin |
Khối đó vẫn gọi tệp của plugin.
Đọc tiếp
Khôi phục plugin trên bản thử, tìm khối dùng nó rồi thay thế.
Tài liệu tham khảo:Chrome DevTools: mức độ phủ mã ↗web.dev: tối ưu tác vụ JavaScript dài ↗Lighthouse: loại bỏ tài nguyên chặn hiển thị ↗
06
TRƯỚC KHI BẮT ĐẦU
Danh sách kiểm tra.
Đánh dấu từng mục để xem mức sẵn sàng. Trạng thái chỉ lưu trên trình duyệt của bạn.
0%SẴN SÀNG
Tài liệu tham khảo:web.dev: hoãn CSS không quan trọng ↗Lighthouse: giảm JavaScript không dùng ↗web.dev: tải trước tài nguyên quan trọng ↗
Nội dung của thẻ Trang dựng sẵn, tệp giữ lâuChọn thẻ khác
01
TRÔNG NHƯ THẾ NÀO
Máy chủ và bộ nhớ đệm trông như thế nào.
Ba màn hình: tiêu đề phản hồi, thời gian yêu cầu, plugin bộ nhớ đệm. Bấm từng mục để xem.
Máy chủ báo giữ tệp bao lâu
Tệp nha-thom.min.css?v=2.4 có cache-control public, max-age=31536000 (giữ 1 năm), content-encoding br (nén Brotli, 92 KB còn 24,1 KB khi truyền) và vary Accept-Encoding.
Đọc tiếp
Tệp có “?v=2.4” giữ được một năm, sửa chỉ đổi số phiên bản. Tệp không có số thì giữ ngắn, kẻo khách dùng bản cũ.
MÔ PHỎNG · SỐ MẪU
nhathom.example/nen-thom
Phần tửBảng điều khiểnNguồnMạngHiệu suấtBộ nhớỨng dụngLighthouse
LọcTất cảCSSJSẢnh
- nen-thom
- nha-thom.min.css?v=2.4
- nha-thom.min.js?v=2.4
- banner-nen-thom-1280.webp
- be-vietnam-pro-400.woff2
Tiêu đềXem trướcPhản hồiThời gian
▾ Tổng quát
- URL yêu cầu:https://nhathom.example/css/nha-thom.min.css?v=2.4
- Phương thức yêu cầu:GET
- Mã trạng thái:200 OK
▾ Tiêu đề phản hồi
- cache-control:public, max-age=315360001
- content-encoding:br2
- content-length:24118
- content-type:text/css; charset=UTF-8
- etag:"6702a1c4-5f3a"
- vary:Accept-Encoding3
- x-cache:HIT
5 yêu cầu · 1 yêu cầu được chọn · 24,1 KB đã truyền (92 KB tài nguyên)
- 1cache-control: public, max-age=31536000: trình duyệt giữ tệp CSS 1 năm, lần sau không tải lại. Sửa tệp thì đổi số trong “?v=2.4”.
- 2content-encoding: br: tệp nén Brotli, 92 KB còn 24,1 KB khi truyền. Nén HTML, CSS, JS lợi nhiều, gần như không rủi ro.
- 3vary: Accept-Encoding: bộ nhớ đệm biết bản nén tùy trình duyệt, nên không gửi bản nén cho trình duyệt không hiểu.
Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.
Thời gian một yêu cầu, trước và sau
Trước khi sửa, yêu cầu mất 1,35 s, trong đó chờ máy chủ (TTFB) 1,18 s. Có bản dựng sẵn, tổng còn 312 ms, TTFB 168 ms.
Đọc tiếp
TTFB chiếm phần lớn thì tối ưu ảnh hay JavaScript chưa giúp được vì trang chưa bắt đầu tải. Đọc biểu đồ thời gian trước.
MÔ PHỎNG · SỐ MẪU
nhathom.example/nen-thom
Phần tửBảng điều khiểnNguồnMạngHiệu suấtBộ nhớỨng dụngLighthouse
Tài liệuKhông giới hạn mạng ▾Yêu cầu: nen-thom · Thời gian
Trước · 03/08/2026, chưa dùng bộ nhớ đệm trang
- Xếp hàng1,20 ms
- Bị đình trệ4,60 ms
- Tra cứu DNS41 ms1
- Kết nối ban đầu96 ms
- SSL71 ms
- Đã gửi yêu cầu0,40 ms
- Đang chờ phản hồi từ máy chủ (TTFB)1,18 s2
- Tải nội dung xuống28 ms
Tổng thời gian: 1,35 s
Sau · 31/08/2026, có bản dựng sẵn
- Xếp hàng1,10 ms
- Bị đình trệ3,80 ms
- Tra cứu DNS38 ms
- Kết nối ban đầu92 ms
- SSL64 ms
- Đã gửi yêu cầu0,30 ms
- Đang chờ phản hồi từ máy chủ (TTFB)168 ms3
- Tải nội dung xuống9,00 ms
Tổng thời gian: 312 ms
- 1Tra cứu DNS 41 ms, kết nối 96 ms (SSL 71 ms): phần mạng, hai lần đo gần như nhau, chưa cần tối ưu.
- 2Đang chờ máy chủ (TTFB) 1,18 s: mỗi lượt xem dựng lại trang bằng PHP và cơ sở dữ liệu. Phần chậm nhất.
- 3Có bản dựng sẵn, TTFB còn 168 ms: trả trang đã lưu, không dựng lại. Cả yêu cầu từ 1,35 s còn 312 ms.
Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.
Plugin bộ nhớ đệm trang trong WordPress
Plugin lưu 142 trang dựng sẵn, 94% lượt xem lấy từ bản lưu, giữ 12 giờ. Danh sách không lưu: /gio-hang, /thanh-toan, /tai-khoan; nén Brotli đang bật.
Đọc tiếp
Danh sách không lưu quan trọng nhất: lưu nhầm trang riêng thì khách này có thể thấy giỏ hàng khách khác. Thử bằng hai trình duyệt.
MÔ PHỎNG · SỐ MẪU
nhathom.example/wp-admin/options-general.php?page=bo-nho-dem
WBảng điều khiểnNhà Thơm (mẫu)N
Bảng tinBài viếtMediaTrangGiao diệnPluginThành viênCông cụCài đặt
Bộ nhớ đệm trang
Phiên bản 1.6.3Bộ nhớ đệmTối ưu tệpẢnhNâng cao
12 giờ
/gio-hang//thanh-toan//tai-khoan/
Đang lưu 142 trang. Hôm nay 94% lượt xem lấy từ bản dựng sẵn. Lần xóa gần nhất: 07/10/2026 02:10.3
Lưu thay đổiXóa toàn bộ bộ nhớ đệm- 1Danh sách không lưu: /gio-hang, /thanh-toan, /tai-khoan có nội dung riêng từng khách. Lưu nhầm là khách này thấy giỏ hàng khách khác.
- 2Nén bằng Brotli, không được thì Gzip, tùy máy chủ. Bật ở đây hoặc ở hosting đều được, chỉ cần một nơi nén.
- 3Đang lưu 142 trang, 94% lượt xem lấy từ bản dựng sẵn. Tỷ lệ thấp thì xem lại loại trừ, thời gian giữ.
Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.
Tài liệu tham khảo:web.dev: bộ nhớ đệm HTTP ↗Lighthouse: bật nén văn bản ↗MDN: bộ nhớ đệm HTTP ↗
02
LÀM NHƯ THẾ NÀO
Năm bước tối ưu máy chủ và bộ nhớ đệm.
Đi từ ngoài vào trong: trình duyệt, máy chủ, nén, rồi mới tới truy vấn.
- 01Đo TTFB và đọc tiêu đề phản hồi của từng loại tệp: ảnh, CSS, JavaScript, phông chữ, trang HTML.
- 02Đặt cache-control giữ lâu (1 năm) cho tệp tĩnh, đánh số phiên bản trong tên để đổi khi sửa.
- 03Bật bộ nhớ đệm trang cho trang chung, liệt kê trang không lưu: giỏ hàng, thanh toán, tài khoản.
- 04Bật nén Brotli hoặc Gzip cho HTML, CSS, JavaScript ở hosting hoặc plugin, chỉ cần một nơi nén.
- 05Thử bằng hai trình duyệt (đã đăng nhập và chưa), đo lại TTFB. Trang riêng không được lộ.
Bạn đưa vào
- Quyền quản trị hosting hoặc plugin
- Bản thử của website
- Danh sách trang riêng của từng khách
- Hai trình duyệt để thử
Giữ tệp tĩnh, dựng sẵn trang, nén văn bảnONMATE cùng doanh nghiệp
Bạn nhận lại
- Bảng quy tắc bộ nhớ đệm theo loại tệp, cấu hình trang kèm danh sách không lưu, bảng TTFB trước, sau.
Tài liệu tham khảo:web.dev: thời gian tới byte đầu tiên (TTFB) ↗web.dev: tối ưu TTFB ↗web.dev: bộ nhớ đệm HTTP ↗
03
CẦN CHUẨN BỊ GÌ
Cần chuẩn bị gì cho bộ nhớ đệm
Cần quyền quản trị, biết trang riêng của từng khách và một bản thử.
NGUYÊN TẮC
Bảng quy tắc: loại tệp, ai giữ, giữ bao lâu. Tệp có số phiên bản giữ 1 năm, HTML 12 giờ, giỏ hàng dùng no-store.
QUY TẮC BỘ NHỚ ĐỆM · MẪU
docs.google.com/spreadsheets
nhathom-quy-tac-bo-nho-demTệp Chỉnh sửa Xem Chèn Định dạng Dữ liệu
| A | B | C | D | E | |
|---|---|---|---|---|---|
| 1 | Loại | Trình duyệt giữ | Máy chủ giữ | Cách đặt | Lưu ý |
| 2 | Ảnh | 1 năm | — | cache-control | Đổi tên khi thay ảnh |
| 3 | CSS và JS | 1 năm | — | cache-control | Đổi ?v= khi sửa1 |
| 4 | Phông chữ | 1 năm | — | cache-control | Lưu cùng website |
| 5 | Trang HTML | Không | 12 giờ2 | Plugin bộ nhớ đệm | Dựng lại khi sửa |
| 6 | Giỏ hàng, thanh toán | Không | Không lưu3 | no-store | Riêng từng khách |
Quy tắcKiểm tra
- 1CSS và JS giữ 1 năm, đổi ?v= khi sửa: khách nhận bản mới ngay, còn không sửa thì vẫn giữ lâu.
- 2Trang HTML giữ 12 giờ ở máy chủ, dựng lại khi sửa bài: đủ tươi cho website bán nến, không cần từng phút.
- 3Giỏ hàng, thanh toán “no-store”: không lưu. Bắt buộc loại trừ, vì lưu sẽ lộ nội dung khách này cho khách khác.
Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.
Tệp tĩnh giữ lâu
Có số phiên bản để đổiTrang riêng không lưu
Giỏ hàng, thanh toán, tài khoảnNén văn bản
HTML, CSS, JavaScriptThử bằng hai trình duyệt
Không lộ nội dung riêngBộ tài nguyên4 mục
- KháchTrang nào có nội dung riêngGiỏ hàng, thanh toán, tài khoản.
- TệpQuyền quản trị hosting và pluginWordPress, và hosting nếu cần bật nén.
- ẢnhẢnh báo cáo TTFBMục giảm thời gian phản hồi máy chủ.
- BảngPlugin bộ nhớ đệm đang cóĐể không cài chồng hai lớp.
Xem đủ thông số và ghi chú
- Nguồn
- TTFB tốt khi không quá 0,8 giây web.dev nêu TTFB tốt khi không quá 0,8 giây và gợi ý nguồn gây chậm gồm máy chủ, truy vấn, và thiếu bộ nhớ đệm.
- Nguồn
- cache-control quyết định thời gian giữ MDN giải thích tiêu đề Cache-Control, trong đó max-age cho biết số giây tài nguyên được coi là còn mới và no-store báo không được lưu.
- Lưu ý
- Trang đã lưu có thể cũ Sửa nội dung mà không xóa bản lưu thì khách vẫn thấy bản cũ cho tới khi hết thời gian giữ. Plugin thường tự xóa khi sửa bài, nhưng nên thử.
Tài liệu tham khảo:web.dev: bộ nhớ đệm HTTP ↗web.dev: thời gian tới byte đầu tiên (TTFB) ↗
04
ĐO ĐIỀU GÌ
Đo bằng TTFB của từng trang.
Bảng TTFB từng trang ở hai thời điểm, cho biết trang nào lấy từ bản dựng sẵn.
CẦN ĐO
Trang “Có” mà TTFB vẫn cao: bản dựng sẵn không chạy. Trang “Không” giữ nguyên.
TTFB THEO TRANG · SỐ MẪU
docs.google.com/spreadsheets
nhathom-phan-hoi-may-chuTệp Chỉnh sửa Xem Chèn Định dạng Dữ liệu
| A | B | C | D | E | |
|---|---|---|---|---|---|
| 1 | Trang | Trước 03/08 | Sau 31/08 | Thay đổi | Từ bản dựng sẵn |
| 2 | Trang chủ | 1,28 s | 0,31 s | −0,97 s | Có |
| 3 | Danh mục nến | 1,32 s | 0,30 s | −1,02 s1 | Có |
| 4 | Trang sản phẩm | 1,21 s | 0,34 s | −0,87 s | Có |
| 5 | Giỏ hàng | 0,92 s | 0,88 s | −0,04 s2 | Không |
| 6 | Liên hệ | 0,84 s | 0,29 s | −0,55 s3 | Có |
TTFBTheo giờ
- 1Danh mục nến giảm 1,02 s, nhiều nhất: trang nặng nhất, trước đây mỗi lượt xem dựng lại từ cơ sở dữ liệu.
- 2Giỏ hàng gần như không đổi (−0,04 s): không lưu được vì riêng mỗi khách. Muốn nhanh hơn, xem truy vấn và plugin.
- 3Liên hệ giảm ít hơn (−0,55 s): trang đơn giản, vốn nhanh nên ít chỗ cải thiện. Xếp việc theo tác động.
Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.
Cách đọc số · số mẫu
| Chỉ số | Cho biết | Cần xem lại khi |
|---|---|---|
| TTFB trang chung | Dưới 0,8 s | Vẫn trên 1 s |
| Trang riêng (giỏ hàng) | Không đổi, đã loại trừ đúng | Bị lưu nhầm |
| Tỷ lệ lấy từ bản lưu | Cao, như 90% trở lên | Thấp, vì loại trừ quá nhiều |
| Nén văn bản | Có content-encoding br hoặc gzip | Không có tiêu đề nén |
CÁCH ĐỌC
Đọc từ trang nặng nhất.
Đọc tiếp
Trang chung giảm mạnh, trang riêng gần như không đổi là đúng. Giỏ hàng muốn nhanh hơn thì xem truy vấn và plugin.
LƯU Ý
TTFB đổi theo giờ và tải máy chủ.
Đọc tiếp
Đo ở nhiều giờ khác nhau. Số trong hình là số mẫu.
Tài liệu tham khảo:web.dev: thời gian tới byte đầu tiên (TTFB) ↗web.dev: tối ưu TTFB ↗
05
CÁCH TRIỂN KHAI
Cách xử lý các tình huống thường gặp.
Số trong bảng là số mẫu để minh họa cách đọc, không phải kết quả dự kiến.
Website WordPress chưa có bộ nhớ đệm
Cài một plugin bộ nhớ đệm trang, liệt kê trang riêng không lưu rồi thử bằng hai trình duyệt.
- Sao lưu website, thử trên bản thử
- Cài plugin, bật bộ nhớ đệm trang
- Thêm /gio-hang, /thanh-toan, /tai-khoan vào danh sách không lưu
- Thử bằng 2 trình duyệt rồi đo TTFB
TTFB cao dù đã có bộ nhớ đệm
Kiểm tra bản dựng sẵn có thực sự được dùng không, rồi mới xem tới máy chủ và truy vấn.
- Xem tiêu đề phản hồi có báo lấy từ bản lưu không
- Kiểm tra trang có bị loại trừ không
- Xem plugin hoặc truy vấn chậm
- Cân nhắc nâng gói hosting nếu vẫn chậm
Sửa CSS rồi mà khách vẫn thấy bản cũ
Tệp được giữ 1 năm nhưng tên không đổi.
Đọc tiếp
Thêm số phiên bản vào địa chỉ tệp để khách nhận bản mới.
- Xác định tệp bị giữ bản cũ
- Thêm hoặc đổi ?v= trong địa chỉ tệp
- Xóa bản lưu của trang
- Mở bằng trình duyệt ẩn danh để kiểm tra
DẤU HIỆU
Khách này thấy giỏ hàng của khách khác
| Chỉ số | Giá trị |
|---|---|
| Trang bị lưu | /gio-hang |
| Nguyên nhân | Chưa có trong danh sách không lưu |
| Việc cần làm | Thêm vào danh sách và xóa bản lưu |
Trang riêng bị lưu vào bộ nhớ đệm.
Đọc tiếp
Tắt bộ nhớ đệm ngay, thêm trang đó vào danh sách không lưu và xóa bản đã lưu.
DẤU HIỆU
Sau khi sửa bài, trang vẫn hiện nội dung cũ
| Chỉ số | Giá trị |
|---|---|
| Thời gian giữ | 12 giờ |
| Hiện tượng | Bài sửa 10 phút trước chưa hiện |
| Việc cần làm | Xóa bản lưu và bật tự xóa khi sửa bài |
Bản dựng sẵn chưa được xóa khi sửa.
Đọc tiếp
Xóa bản lưu của trang đó và kiểm tra plugin có tự xóa khi lưu bài không.
DẤU HIỆU
PageSpeed vẫn báo chưa nén văn bản
| Chỉ số | Giá trị |
|---|---|
| content-encoding | Không có |
| Tệp bị nêu | HTML, CSS, JavaScript |
| Việc cần làm | Bật Brotli hoặc Gzip ở hosting |
Nén chưa bật ở máy chủ hoặc bị tắt bởi lớp trung gian.
Đọc tiếp
Bật nén ở một nơi và kiểm tra tiêu đề phản hồi.
Tài liệu tham khảo:MDN: bộ nhớ đệm HTTP ↗web.dev: tối ưu TTFB ↗web.dev: giảm dung lượng tải bằng nén văn bản ↗
06
TRƯỚC KHI BẮT ĐẦU
Danh sách kiểm tra.
Đánh dấu từng mục để xem mức sẵn sàng. Trạng thái chỉ lưu trên trình duyệt của bạn.
0%SẴN SÀNG
Tài liệu tham khảo:web.dev: bộ nhớ đệm HTTP ↗web.dev: giảm dung lượng tải bằng nén văn bản ↗web.dev: bộ nhớ đệm tiến lùi (bfcache) ↗
Nội dung của thẻ Hoãn mã bên thứ baChọn thẻ khác
01
TRÔNG NHƯ THẾ NÀO
Xử lý mã bên thứ ba trông như thế nào.
Ba màn hình: báo cáo mã bên thứ ba, hoãn khung chat, video giữ chỗ. Bấm từng mục để xem.
Mã bên thứ ba và thời gian chặn
Chặn luồng chính 380 ms: Tag Manager 140 ms, Zalo chat 110 ms, Facebook 90 ms, Analytics 40 ms. Google Fonts nặng nhất (318 KB) nhưng không chặn.
Đọc tiếp
Hai cột đọc khác nhau: “Dung lượng” là tải bao nhiêu, “Thời gian chặn” là trình duyệt bận bao lâu. Mã nhỏ vẫn có thể chặn lâu.
MÔ PHỎNG · SỐ MẪU
pagespeed.web.dev
https://nhathom.example/nen-thomĐiện thoại
Giảm tác động của mã bên thứ baMã bên thứ ba chặn luồng chính 380 ms1
Bên thứ baKích thước truyềnThời gian chặn luồng chính
Google Tag Manager96 KB140 ms
Zalo271 KB110 ms
Facebook58 KB90 ms
Google Analytics52 KB40 ms
Google Fonts3318 KB0 ms
Mã bên thứ ba là mã của nơi khác, nhúng vào website: đo, quảng cáo, chat, phông chữ.
- 1Mã bên thứ ba chặn luồng chính 380 ms: trình duyệt bận chạy mã nơi khác, chưa xử lý được thao tác chạm.
- 2Zalo chat 71 KB, chặn 110 ms: khung chat chỉ cần khi khách muốn hỏi mà tải ngay lúc vào trang, nên hoãn.
- 3Google Fonts 318 KB: không chặn nhưng nặng nhất trong bên thứ ba. Tự lưu phông thì nhẹ hơn, bớt một kết nối.
Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.
Chỉ tải khung chat khi khách tương tác
Khung chat Zalo tải khi khách cuộn, chạm hay bấm phím, hoặc sau 8 giây nếu chưa làm gì. Cờ daTaiChat giúp mã chỉ chạy một lần.
Đọc tiếp
Khung chat chỉ có ích khi khách muốn hỏi, nên không cần tải ở lần đầu. Cần thử trên điện thoại thật.
MÔ PHỎNG · SỐ MẪU
view-source:nhathom.example/nen-thom
nen-thom (đoạn nạp khung chat)
1<script>2// Tải khung chat sau khi khách cuộn hoặc chạm, hoặc sau 8 giây3function taiChat() {4if (window.daTaiChat) return;5window.daTaiChat = true;6var s = document.createElement('script');7s.src = 'https://sp.zalo.me/plugins/sdk.js';8s.async = true;9document.body.appendChild(s);10}11['scroll', 'touchstart', 'keydown'].forEach(function (ten) {12window.addEventListener(ten, taiChat, {once: true, passive: true});13});14setTimeout(taiChat, 8000);15</script>
- Dòng 4 và 5: cờ daTaiChat để mã chỉ chạy một lần dù khách vừa cuộn vừa chạm. Thiếu thì chat bị nạp lặp.
- Dòng 11 và 12: tải khi khách cuộn, chạm hoặc bấm phím, tức là lúc bắt đầu tương tác. Chỉ chạy một lần.
- Dòng 14: dự phòng sau 8 giây, để khách chỉ đọc không cuộn vẫn thấy khung chat. Nên thử trên điện thoại thật.
Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.
Video giữ chỗ: bấm mới tải trình phát
Trước: khung YouTube nhúng tải ngay khoảng 0,6 MB. Sau: chỉ ảnh xem trước 18 KB và nút phát; trình phát thật tải khi bấm.
Đọc tiếp
Kiểu này gọi là ảnh giữ chỗ cho video. Khách bấm xem thì gần như không đổi, khách không bấm thì tiết kiệm gần cả MB.
MÔ PHỎNG · SỐ MẪU
nhathom.example/nen-thom/nen-nap-go-200g
Trước · khung YouTube tải ngay1
Cách đốt nến an toàn
khoảng 0,6 MB · 14 yêu cầu · tải ngay khi mở trang, dù khách không bấm xem
Sau · ảnh xem trước, tải trình phát khi bấm2
3Cách đốt nến an toàn · 1:12
18 KB · 1 yêu cầu · trình phát chỉ tải khi khách bấm nút xem
- 1Trước: khung YouTube nhúng tải ngay khi mở trang, khoảng 0,6 MB và nhiều yêu cầu, dù khách chưa bấm xem.
- 2Sau: chỉ hiện ảnh xem trước 18 KB, một yêu cầu. Trình phát thật tải khi khách bấm xem (ảnh giữ chỗ).
- 3Nút phát giữ nguyên hình dạng, vị trí để khách nhận ra ngay là video. Bấm vào thì trình phát tải và chạy.
Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.
Tài liệu tham khảo:Lighthouse: giảm tác động của mã bên thứ ba ↗web.dev: tải JavaScript của bên thứ ba ↗web.dev: tải ảnh trễ ở cấp trình duyệt ↗
02
LÀM NHƯ THẾ NÀO
Năm bước xử lý mã bên thứ ba.
Mỗi mã có một chủ và một lý do. Không ai nhận thì gỡ.
- 01Lập danh sách mã bên thứ ba: tên, nơi nhúng, dùng để làm gì, ai phụ trách.
- 02Đo mỗi mã chặn bao lâu (PageSpeed, tab Hiệu suất) và tải về bao nhiêu KB.
- 03Với từng mã quyết định: giữ nguyên, hoãn tới khi khách tương tác, thay bằng bản tự lưu, hoặc gỡ.
- 04Làm trên bản thử: hoãn chat, hoãn mã quảng cáo, tự lưu phông chữ, ảnh giữ chỗ cho video.
- 05Kiểm tra mã đo vẫn ghi đủ, khung chat vẫn mở được, rồi đo lại thời gian chặn.
Bạn đưa vào
- Quyền sửa giao diện hoặc Tag Manager
- Danh sách mã đang gắn
- Quyền xem báo cáo thẻ đo
- Điện thoại thật để thử
Danh sách mã, giữ hay hoãn, kiểm tra lạiONMATE cùng doanh nghiệp
Bạn nhận lại
- Bảng mã bên thứ ba kèm cách xử lý, mã tải trễ đã thử trên bản thử, bảng thời gian chặn.
Tài liệu tham khảo:web.dev: tải JavaScript của bên thứ ba ↗Lighthouse: giảm tác động của mã bên thứ ba ↗web.dev: kết nối trước đến nguồn bên thứ ba ↗
03
CẦN CHUẨN BỊ GÌ
Cần chuẩn bị gì để xử lý mã bên thứ ba.
Cần quyền sửa giao diện hoặc Tag Manager, và biết mỗi mã để làm gì.
NGUYÊN TẮC
Bảng mã bên thứ ba: dịch vụ, dung lượng, dùng để làm gì, cách xử lý. Mã đã gỡ cũng được ghi lại.
MÃ BÊN THỨ BA · MẪU
docs.google.com/spreadsheets
nhathom-ma-ben-thu-baTệp Chỉnh sửa Xem Chèn Định dạng Dữ liệu
| A | B | C | D | E | |
|---|---|---|---|---|---|
| 1 | Dịch vụ | Cỡ | Dùng để | Cách tải | Xử lý |
| 2 | Google Tag Manager | 96 KB | Quản lý thẻ đo | Sau khi trang tải xong | Giữ |
| 3 | Google Analytics | 52 KB | Đo lượt truy cập | Qua Tag Manager | Giữ |
| 4 | Facebook Pixel | 58 KB | Đo quảng cáo | Qua Tag Manager, tải sau3 | Hoãn |
| 5 | Zalo chat | 71 KB | Khung chat | Khi cuộn hoặc sau 8 giây1 | Hoãn |
| 6 | Google Fonts | 318 KB | Phông chữ | Lưu cùng website2 | Thay |
Danh sáchKết quả
- 1Zalo chat tải khi cuộn hoặc sau 8 giây: chỉ cần khi khách muốn hỏi, nên không chiếm thời gian lần tải đầu.
- 2Google Fonts → tự lưu: 318 KB còn 44 KB, bớt một kết nối. Chỉ khi giấy phép cho phép (Be Vietnam Pro: OFL).
- 3Facebook Pixel vẫn giữ, chỉ đổi lúc tải: mã đo quảng cáo không bỏ, chạy muộn hơn để khỏi tranh việc vẽ trang.
Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.
Mỗi mã một người phụ trách
Không ai nhận thì gỡHoãn tới khi cần
Khung chat, video, bản đồGiữ đủ số đo
Thẻ và chuyển đổi vẫn ghiGhi lại mã đã gỡ
Tránh dán lại không biếtBộ tài nguyên4 mục
- KháchMã nào còn dùngMã đo, quảng cáo, chat nào còn dùng.
- TệpQuyền sửa giao diện, Tag ManagerWordPress và Google Tag Manager (nếu dùng).
- ẢnhẢnh báo cáo bên thứ baĐể biết mã nào chặn lâu nhất.
- BảngDanh sách tài khoản của mãTài khoản Zalo, Facebook, Google.
Xem đủ thông số và ghi chú
- Nguồn
- Mã bên thứ ba có thể chặn luồng chính web.dev về JavaScript bên thứ ba nêu mã từ nơi khác có thể làm chậm tải trang và nên được hoãn, tải bất đồng bộ hoặc thay thế khi không cần ngay.
- Nguồn
- Kết nối trước tới nơi cần dùng web.dev về preconnect mô tả cách báo trình duyệt kết nối sớm tới nơi sẽ tải tài nguyên, nên chỉ dùng cho vài nơi thật sự cần.
- Lưu ý
- Phông tự lưu cần đúng giấy phép Chỉ tự lưu phông có giấy phép cho phép (như OFL) và ghi nguồn. Phông trả phí hoặc có điều khoản riêng thì kiểm tra trước khi tự lưu.
Tài liệu tham khảo:web.dev: tải JavaScript của bên thứ ba ↗web.dev: kết nối trước đến nguồn bên thứ ba ↗
04
ĐO ĐIỀU GÌ
Đo bằng thời gian chặn trước và sau.
Bảng ghi thời gian chặn của mỗi mã trước và sau, kèm TBT toàn trang. Thấy mã nào đã giảm.
CẦN ĐO
Đọc TBT toàn trang cạnh “Cộng mã bên thứ ba”. Hiệu hai dòng là mã website.
KẾT QUẢ MÃ BÊN THỨ BA · MẪU
docs.google.com/spreadsheets
nhathom-ket-qua-ma-ben-thu-baTệp Chỉnh sửa Xem Chèn Định dạng Dữ liệu
| A | B | C | D | |
|---|---|---|---|---|
| 1 | Dịch vụ | Chặn trước | Chặn sau | Giảm |
| 2 | Google Tag Manager | 140 ms | 50 ms | −90 ms |
| 3 | Google Analytics | 40 ms | 20 ms | −20 ms |
| 4 | Facebook Pixel | 90 ms | 10 ms | −80 ms1 |
| 5 | Zalo chat | 110 ms | 0 ms | −110 ms2 |
| 6 | Cộng mã bên thứ ba | 380 ms | 80 ms | −300 ms |
| 7 | TBT toàn trang | 420 ms | 90 ms | −330 ms3 |
Danh sáchKết quả
- 1Facebook Pixel 90 → 10 ms: mã đo vẫn chạy đủ, chỉ chạy sau khi trang hiện nên không chặn lúc khách vào.
- 2Zalo chat 110 → 0 ms: vào trang chưa tải gì từ Zalo. Khách cuộn hoặc chạm thì chat tải, mở như cũ.
- 3TBT toàn trang 420 → 90 ms: mã bên thứ ba từ 380 ms còn 80 ms, cộng 10 ms mã của website.
Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.
Cách đọc số · số mẫu
| Chỉ số | Cho biết | Cần xem lại khi |
|---|---|---|
| Mã quảng cáo, mã đo | Vẫn ghi nhận, chặn ít hơn | Mất số đo sau khi hoãn |
| Khung chat | Mở được, không tải ở lần đầu | Không mở được khi bấm |
| Phông chữ | Ít kết nối hơn, nhẹ hơn | Phông hiển thị khác |
| TBT toàn trang | Giảm theo mã đã xử lý | Không đổi dù đã hoãn mã |
CÁCH ĐỌC
Mở bảng, đọc dòng cộng mã bên thứ ba rồi TBT toàn trang.
Đọc tiếp
Hai dòng giảm gần cùng mức thì nguyên nhân là mã bên thứ ba.
LƯU Ý
Hoãn mã đo dễ mất lượt ghi của khách thoát nhanh.
Đọc tiếp
So số truy cập trước và sau. Số trong hình là số mẫu.
Tài liệu tham khảo:Lighthouse: giảm tác động của mã bên thứ ba ↗web.dev: tối ưu tác vụ JavaScript dài ↗
05
CÁCH TRIỂN KHAI
Cách xử lý các tình huống thường gặp.
Số trong bảng là số mẫu để minh họa cách đọc, không phải kết quả dự kiến.
Có khung chat tải ngay khi vào trang
Hoãn tới khi khách cuộn, chạm hoặc sau vài giây, và thử trên điện thoại thật.
- Tìm đoạn mã nhúng khung chat
- Thay bằng mã tải khi có tương tác
- Thử mở khung chat trên điện thoại
- Đo lại thời gian chặn
Có video YouTube nhúng ở trang chủ
Thay khung nhúng bằng ảnh xem trước, chỉ tải trình phát khi khách bấm.
- Chụp ảnh xem trước của video
- Dựng ảnh giữ chỗ có nút phát
- Tải trình phát khi khách bấm
- Thử nút phát trên điện thoại
Nhiều mã đo gắn từ nhiều năm
Rà từng mã với người đang dùng báo cáo và gỡ mã không còn ai xem.
- Lập danh sách mã đang gắn
- Hỏi người dùng báo cáo từng mã
- Gỡ mã không ai dùng
- Ghi lại mã đã gỡ vào bảng
DẤU HIỆU
Sau khi hoãn, số lượt chuyển đổi ghi nhận giảm
| Chỉ số | Giá trị |
|---|---|
| Lượt chuyển đổi trước | 120 mỗi tuần |
| Sau khi hoãn | 104 mỗi tuần |
| Việc cần làm | Tải mã chuyển đổi sớm hơn |
Khách thoát nhanh hơn mã chạy nên không được ghi.
Đọc tiếp
Đặt mã chuyển đổi tải sớm hơn mã khác, hoặc dùng sự kiện tải trang hoàn tất.
DẤU HIỆU
Khung chat không mở khi khách bấm ngay khi vào trang
| Chỉ số | Giá trị |
|---|---|
| Hiện tượng | Bấm nút chat không có phản hồi |
| Nguyên nhân | Mã chat chưa tải xong |
| Việc cần làm | Tải mã khi nút được bấm |
Khách bấm trước khi mã tải xong.
Đọc tiếp
Hiển thị nút chat ngay và tải mã khi bấm, hoặc thêm sự kiện chạm.
DẤU HIỆU
Phông hiển thị khác sau khi tự lưu
| Chỉ số | Giá trị |
|---|---|
| Phông hiển thị | Phông mặc định của máy |
| Nguyên nhân | Thiếu tệp phông có dấu tiếng Việt |
| Việc cần làm | Tải bản có bộ ký tự Vietnamese |
Tên phông hoặc đường dẫn tệp không khớp.
Đọc tiếp
Kiểm tra khai báo phông trong CSS và bản tải về có đủ dấu tiếng Việt.
Tài liệu tham khảo:web.dev: tải JavaScript của bên thứ ba ↗web.dev: phông chữ web ↗web.dev: tải ảnh trễ ở cấp trình duyệt ↗
06
TRƯỚC KHI BẮT ĐẦU
Danh sách kiểm tra.
Đánh dấu từng mục để xem mức sẵn sàng. Trạng thái chỉ lưu trên trình duyệt của bạn.
0%SẴN SÀNG
Tài liệu tham khảo:web.dev: tải JavaScript của bên thứ ba ↗web.dev: kết nối trước đến nguồn bên thứ ba ↗web.dev: phông chữ web ↗
Nội dung của thẻ Theo dõi để không chậm lạiChọn thẻ khác
01
TRÔNG NHƯ THẾ NÀO
Theo dõi tốc độ trông như thế nào.
Ba màn hình: Core Web Vitals, LCP thực tế theo tuần, kiểm tra hằng tuần. Bấm từng mục để xem.
Báo cáo Core Web Vitals theo nhóm trang
Điện thoại chia URL ba nhóm: Kém (6 nhóm, LCP trên 4 giây), Cần cải thiện (CLS, 14 nhóm), Tốt (118 nhóm). Mỗi dòng là một nhóm URL.
Đọc tiếp
Báo cáo tính theo cửa sổ 28 ngày nên đổi chậm. Dùng nhận ra vấn đề theo nhóm trang và xác nhận sau sửa, không xem từng ngày.
MÔ PHỎNG · SỐ MẪU
search.google.com/search-console
Search Consolenhathom.exampleKiểm tra mọi URL trong nhathom.exampleN
Core Web Vitals
Mở báo cáoDi độngMáy tính
KémCần cải thiệnTốt
6 thg 73 thg 831 thg 828 thg 9
| Trạng thái | Loại sự cố | Nhóm URL |
|---|---|---|
| Kém | LCP lớn hơn 4 giây (di động)1 | 6 |
| Cần cải thiện | CLS lớn hơn 0,1 (di động) | 14 |
| Tốt | Đạt cả LCP, INP và CLS | 118 |
- 1Nhóm trang có LCP trên 4 giây trên điện thoại: đây là nhóm nên xử lý trước, vì tải chậm thấy rõ nhất.
Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.
LCP thực tế theo tuần, có ngày sửa
LCP thực tế (điện thoại) trên 4 s suốt tháng 4–7. Giảm từ 04/08, mốc “sửa xong” 31/08, còn 2,1 s đến 03/10, dưới ngưỡng 2,5 s.
Đọc tiếp
Đánh dấu ngày sửa giúp gắn thay đổi với nguyên nhân. Số thật cải thiện chậm vì cửa sổ 28 ngày, đừng kết luận sớm.
MÔ PHỎNG · SỐ MẪU04/08 bắt đầu sửa31/08 sửa xong123
cruxvis.withgoogle.com
LCPđiện thoại · p75 theo tuần · cả website2,1 sĐạt
Tháng 4Tháng 5Tháng 6Tháng 7Tháng 8Tháng 9Tháng 10
Ngưỡng tốt 2,5 sNgưỡng kém 4 sLCP thực tế (p75)
- 1Tháng 4 đến cuối tháng 7: LCP thực tế 4,4–4,7 s, trên ngưỡng kém (4 s) gần bốn tháng. Xem từng tháng khó thấy.
- 204/08 đến 31/08 đường đi xuống chậm: dữ liệu thật là cửa sổ 28 ngày trượt, nên cải thiện rõ dần theo tuần.
- 3Ngày 03/10: 2,1 s, dưới ngưỡng tốt 2,5 s. Giờ mới kết luận được: cả cửa sổ 28 ngày nằm sau khi sửa.
Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.
Kiểm tra hằng tuần so với ngân sách
Chạy 06/10/2026: 4 trên 5 trang đạt ngân sách. Trang Liên hệ vượt ba mục (LCP 2,6 s, TBT 310 ms, 1.180 KB) vì bản đồ nhúng 05/10.
Đọc tiếp
Kiểm tra hằng tuần bắt thay đổi trong vài ngày, sớm hơn số thật nhiều. Có ngân sách thì “vượt” là sự kiện rõ, không phải cảm giác.
MÔ PHỎNG · SỐ MẪU
sotocdo.nhathom.example/kiem-tra
TSổ tốc độNhà Thơm (mẫu)T
Tổng quanCác trangNgân sáchLịch kiểm traBáo cáo
Kiểm tra hằng tuần
06/10/2026 08:00 · Điện thoạiĐạt ngân sách4 / 5 trangLCP thực tế (p75)2,1 sLần kiểm tra trước29/09/2026
Năm trang chính so với ngân sách1
| Trang | Điểm | LCP | TBT | CLS | Nặng | Ngân sách |
|---|---|---|---|---|---|---|
| Trang chủ | 90 | 2,2 s | 110 ms | 0,03 | 842 KB | Đạt |
| Danh mục nến | 91 | 2,0 s | 90 ms | 0,03 | 766 KB | Đạt |
| Trang sản phẩm | 88 | 2,3 s | 140 ms | 0,04 | 940 KB | Đạt |
| Giỏ hàng | 93 | 1,7 s | 70 ms | 0,02 | 610 KB | Đạt |
| Liên hệ | 76 | 2,6 s | 310 ms | 0,02 | 1.180 KB | Vượt 3 mục2 |
Ngân sách: LCP ≤ 2,5 s · TBT ≤ 200 ms · CLS ≤ 0,1 · Nặng ≤ 1.000 KB3
Liên hệ: bản đồ nhúng thêm ngày 05/10 (khoảng 0,5 MB và một tệp JavaScript lớn). Đề xuất: hiện ảnh bản đồ, chỉ tải bản đồ thật khi khách bấm.
- 1Năm trang chính kiểm tra mỗi tuần, cùng thiết bị và mạng giả lập. 4 trang đạt ngân sách, 1 trang vượt.
- 2Liên hệ vượt 3 mục (LCP 2,6 s, TBT 310 ms, 1.180 KB): do bản đồ nhúng ngày 05/10. Phát hiện ngay trong tuần.
- 3Ngân sách là bốn ngưỡng viết sẵn: LCP, TBT, CLS, dung lượng. Trang nào vượt là thấy ngay, không dựa vào cảm giác.
Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.
Tài liệu tham khảo:Search Console: giới thiệu ↗Chrome UX Report: dữ liệu người dùng thật ↗web.dev: ngân sách hiệu suất ↗
02
LÀM NHƯ THẾ NÀO
Năm bước theo dõi tốc độ.
Thói quen nhỏ lặp lại: đo cùng cách, so với ngân sách, ghi thay đổi.
- 01Đặt ngân sách cho từng chỉ số (LCP, TBT, CLS, dung lượng), lấy ngưỡng “tốt” của Google làm gốc.
- 02Chọn người phụ trách và chu kỳ: lab hằng tuần, dung lượng khi đăng nội dung, số thật hằng tháng.
- 03Chạy kiểm tra hằng tuần cho 5 trang bằng cùng thiết bị, cùng mạng, rồi so với ngân sách.
- 04Trang vượt ngân sách: tìm thay đổi gần nhất (ảnh, plugin, mã nhúng mới) và sửa đúng nguyên nhân.
- 05Ghi nhật ký: ngày, số thật, điểm, dung lượng, ghi chú. Mỗi tháng đọc số thật rồi cập nhật.
Bạn đưa vào
- Quyền xem Search Console
- Sổ đo đã có ở lần trước
- Người phụ trách từng chỉ số
- Lịch kiểm tra hằng tuần
Ngân sách, chu kỳ, người phụ trách, nhật kýONMATE cùng doanh nghiệp
Bạn nhận lại
- Bảng ngân sách có người phụ trách, lịch kiểm tra hằng tuần, nhật ký tốc độ, quy trình khi vượt ngưỡng.
Tài liệu tham khảo:web.dev: ngân sách hiệu suất ↗web.dev: khác biệt giữa dữ liệu thật và dữ liệu phòng thí nghiệm ↗Lighthouse: tổng quan ↗
03
CẦN CHUẨN BỊ GÌ
Cần chuẩn bị gì để theo dõi tốc độ.
Cần sổ đo cũ, quyền xem Search Console, người phụ trách từng chỉ số.
NGUYÊN TẮC
Ngân sách là bảng ngắn: chỉ số, ngưỡng, cách đo, chu kỳ, người phụ trách. Ngưỡng lấy từ giá trị “tốt” của Google; dung lượng tự đặt.
NGÂN SÁCH TỐC ĐỘ · MẪU
docs.google.com/spreadsheets
nhathom-ngan-sach-toc-doTệp Chỉnh sửa Xem Chèn Định dạng Dữ liệu
| A | B | C | D | E | |
|---|---|---|---|---|---|
| 1 | Chỉ số | Ngân sách | Đo bằng | Chu kỳ | Phụ trách |
| 2 | LCP | ≤ 2,5 s1 | PageSpeed, điện thoại | Hằng tuần | Minh Châu |
| 3 | TBT | ≤ 200 ms | PageSpeed, điện thoại | Hằng tuần | Minh Châu |
| 4 | CLS | ≤ 0,1 | PageSpeed, điện thoại | Hằng tuần | Minh Châu |
| 5 | Dung lượng trang | ≤ 1.000 KB2 | DevTools, Fast 4G | Khi đăng nội dung | Hà Trang |
| 6 | LCP thực tế (p75) | ≤ 2,5 s | Search Console | Hằng tháng | Hà Trang3 |
Ngân sáchLịch kiểm tra
- 1LCP ≤ 2,5 s, TBT ≤ 200 ms, CLS ≤ 0,1: theo ngưỡng “tốt” của Google và Lighthouse, không tự đặt.
- 2Dung lượng ≤ 1.000 KB: ngưỡng tự đặt cho website này, không có chuẩn chung. Hiện 766 KB, còn chỗ thêm nội dung.
- 3Mỗi dòng có người phụ trách và chu kỳ. Ngân sách vô chủ chỉ là bảng số, tuần sau không ai mở lại.
Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.
Ngưỡng có nguồn
Giá trị “tốt” của GoogleMỗi chỉ số có người nhận
Và có chu kỳ đo rõĐo cùng cách
Cùng thiết bị, cùng mạngGhi nhật ký
Ngày, số, nguyên nhânBộ tài nguyên4 mục
- KháchAi chịu trách nhiệm tốc độNgười kiểm tra tuần, người đọc số thật.
- TệpQuyền xem Search ConsoleĐể đọc Core Web Vitals theo nhóm trang.
- ẢnhẢnh báo cáo tốc độ cũCác lần đo trước, để dựng nhật ký.
- BảngLịch đăng bài và cập nhậtBiết thay đổi nào gây chậm.
Xem đủ thông số và ghi chú
- Nguồn
- Ngân sách hiệu suất web.dev về ngân sách hiệu suất mô tả cách đặt giới hạn cho chỉ số hoặc dung lượng và kiểm tra thường xuyên để phát hiện sớm khi vượt.
- Nguồn
- Chrome UX Report là dữ liệu thật Tài liệu Chrome UX Report mô tả dữ liệu thật của người dùng Chrome, tổng hợp trong 28 ngày, là nguồn của báo cáo Core Web Vitals trong Search Console.
- Lưu ý
- Ngưỡng dung lượng là tự đặt Không có chuẩn chung cho dung lượng trang. Đặt theo website và loại khách, ghi lý do và xem lại khi thay đổi cách xây website.
Tài liệu tham khảo:web.dev: ngân sách hiệu suất ↗Chrome UX Report: dữ liệu người dùng thật ↗
04
ĐO ĐIỀU GÌ
Đo bằng nhật ký tốc độ.
Nhật ký ghi số thật, điểm, dung lượng từng mốc, kèm ghi chú. Vài tháng sau vẫn hiểu vì sao số đổi.
CẦN ĐO
Đọc LCP thực tế cạnh Ghi chú. Số thật chậm hơn vài tuần là bình thường.
NHẬT KÝ TỐC ĐỘ · SỐ MẪU
docs.google.com/spreadsheets
nhathom-nhat-ky-toc-doTệp Chỉnh sửa Xem Chèn Định dạng Dữ liệu
| A | B | C | D | E | |
|---|---|---|---|---|---|
| 1 | Ngày | LCP thực tế | Điểm | Dung lượng | Ghi chú |
| 2 | 03/08/2026 | 4,6 s | 58 | 6,8 MB | Đo trước khi sửa |
| 3 | 31/08/2026 | 3,4 s1 | 91 | 0,77 MB | Sửa xong, đo lại |
| 4 | 29/09/2026 | 2,1 s2 | 91 | 0,77 MB | Số thực tế đạt |
| 5 | 06/10/2026 | 2,1 s | 91 | 0,77 MB | Liên hệ vượt ngân sách3 |
Nhật kýNgân sách
- 1Ngày 31/08: phòng thí nghiệm 91 điểm nhưng số thực tế mới 3,4 s: dữ liệu 28 ngày còn lẫn ngày chưa sửa.
- 2Ngày 29/09: số thực tế 2,1 s. Cửa sổ 28 ngày nằm trọn sau khi sửa, giờ mới nói được là nhanh hơn.
- 3Ngày 06/10: ghi việc Liên hệ vượt ngân sách. Có nhật ký thì xem lại được vì sao và khi nào số đổi.
Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.
Cách đọc số · số mẫu
| Chỉ số | Cho biết | Cần xem lại khi |
|---|---|---|
| LCP thực tế | Giảm dần sau khi sửa | Không đổi sau 28 ngày |
| Điểm phòng thí nghiệm | Ổn định giữa các tuần | Tụt đột ngột |
| Dung lượng | Dưới ngân sách | Tăng dần sau mỗi lần đăng nội dung |
| Ghi chú | Ghi rõ nguyên nhân | Trống, không biết vì sao đổi |
CÁCH ĐỌC
Mở nhật ký, đọc từ dòng đầu xuống dòng cuối.
Đọc tiếp
Ba dòng đầu kể đợt tối ưu, dòng cuối cho biết việc cần làm tiếp.
LƯU Ý
Số thật trung bình 28 ngày nên chậm đổi.
Đọc tiếp
Kiểm tra hằng tuần mới phát hiện sớm. Số trong hình là số mẫu.
Tài liệu tham khảo:Chrome UX Report: dữ liệu người dùng thật ↗web.dev: khác biệt giữa dữ liệu thật và dữ liệu phòng thí nghiệm ↗
05
CÁCH TRIỂN KHAI
Cách xử lý các tình huống thường gặp.
Số trong bảng là số mẫu để minh họa cách đọc, không phải kết quả dự kiến.
Vừa tối ưu xong và muốn giữ kết quả
Đặt ngân sách từ chính số vừa đạt, chọn người phụ trách và bắt đầu kiểm tra hằng tuần.
- Ghi số hiện tại thành mốc
- Đặt ngân sách theo ngưỡng “tốt”
- Giao người phụ trách từng chỉ số
- Đặt lịch kiểm tra hằng tuần
Nhiều người cùng đăng ảnh, thêm plugin
Thêm bước kiểm tra dung lượng khi đăng nội dung và danh sách cần xem trước khi cài plugin.
- Viết quy tắc cỡ ảnh khi đăng
- Kiểm tra dung lượng trang sau khi đăng
- Thử plugin mới trên bản thử
- Ghi vào nhật ký khi cài thêm
Có báo cáo tốc độ định kỳ cho quản lý
Gửi nhật ký tốc độ mỗi tháng, gồm số thật, điểm, dung lượng và các sự cố đã xử lý.
- Đọc số thật trong Search Console
- Cập nhật nhật ký
- Ghi sự cố và cách xử lý
- Gửi báo cáo tháng
DẤU HIỆU
Một trang vượt ngân sách sau khi thêm bản đồ
| Chỉ số | Giá trị |
|---|---|
| Trang vượt ngân sách | Liên hệ, 3 mục |
| Thay đổi gần nhất | Bản đồ nhúng ngày 05/10 |
| Việc cần làm | Dùng ảnh giữ chỗ cho bản đồ |
Bản đồ nhúng tải nặng.
Đọc tiếp
Thay bằng ảnh giữ chỗ và tải khi khách bấm, như với video.
DẤU HIỆU
Search Console báo kém nhưng kiểm tra tuần vẫn đạt
| Chỉ số | Giá trị |
|---|---|
| Kiểm tra tuần | 5 trang đạt |
| Search Console | 1 nhóm LCP trên 4 giây |
| Việc cần làm | Xem nhóm URL và các ngày gần đây |
Số thật là cửa sổ 28 ngày, còn kiểm tra tuần là phòng thí nghiệm.
Đọc tiếp
Chờ đủ thời gian và xem nhóm URL bị báo.
DẤU HIỆU
Số liệu tốt nhưng khách vẫn phàn nàn chậm
| Chỉ số | Giá trị |
|---|---|
| LCP thực tế p75 | 2,1 s, đạt |
| Phân bổ | 12% lượt tải trên 4 giây |
| Việc cần làm | Xem thiết bị và mạng của nhóm chậm |
Số liệu là trung bình theo nhóm, khách phàn nàn có thể ở thiết bị hoặc mạng yếu hơn.
Đọc tiếp
Xem phân bổ chứ không chỉ p75.
Tài liệu tham khảo:web.dev: ngân sách hiệu suất ↗Chrome UX Report: dữ liệu người dùng thật ↗Google Search Central: Core Web Vitals ↗
06
TRƯỚC KHI BẮT ĐẦU
Danh sách kiểm tra.
Đánh dấu từng mục để xem mức sẵn sàng. Trạng thái chỉ lưu trên trình duyệt của bạn.
0%SẴN SÀNG
Tài liệu tham khảo:web.dev: ngân sách hiệu suất ↗web.dev: khác biệt giữa dữ liệu thật và dữ liệu phòng thí nghiệm ↗web.dev: Core Web Vitals ↗
NHỚ NHANH
Sáu phần việc, từ đo tốc độ đến theo dõi.
Chọn một ô để quay lại đúng phần nội dung ở trên.
01
NĂM BƯỚC TRIỂN KHAI
ONMATE làm gì, và doanh nghiệp nhận lại được gì.
Mỗi bước kết thúc bằng một thứ xem được. Bấm một bước để xem việc làm và thứ được bàn giao.
01 · Đo
02 · Sửa
03 · Giữ
BƯỚC 01
Đo hiện trạng
Trang, thiết bị, mạng ghi rõ.
Bàn giaoBảng số trướcBƯỚC 02
Tìm nguyên nhân
Ảnh, tài nguyên chặn, mã bên thứ ba, cache.
Bàn giaoDanh sách theo ảnh hưởngBƯỚC 03
Sửa theo thứ tự
Việc ảnh hưởng lớn, rủi ro thấp trước.
Bàn giaoBản sửa trên bản thửBƯỚC 04
Đo lại
Cùng điều kiện, rồi theo dõi dữ liệu thực tế.
Bàn giaoBảng số sauBƯỚC 05
Quy tắc giữ tốc độ
Ảnh, mã mới, kiểm tra định kỳ.
Bàn giaoTài liệu quy tắcTài liệu tham khảo:web.dev: tải ảnh trễ ↗MDN: bộ nhớ đệm HTTP ↗web.dev: Core Web Vitals ↗
02
CÂU HỎI THƯỜNG GẶP
Những câu hay được hỏi trước khi bắt đầu.
Chọn một chủ đề. Câu trả lời nói rõ cả điều làm được lẫn điều không ai bảo đảm được.
Có cam kết điểm 100 không?
Không. Điểm phòng thí nghiệm dao động theo lần đo; mục tiêu là chỉ số người dùng thật trong ngưỡng tốt.
Vì sao công cụ báo khác nhau?
Dữ liệu thực tế là người dùng thật nhiều tuần; phòng thí nghiệm là một lần tải giả lập trên một thiết bị, một mạng.
Bao lâu thì thấy kết quả?
Đo phòng thí nghiệm thấy ngay; dữ liệu thực tế cần vài tuần để phản ánh.
Có cần đổi hosting?
Chỉ khi đo thấy máy chủ phản hồi chậm. Phần lớn trường hợp sửa ảnh và tài nguyên trước.
Sửa tốc độ có làm vỡ giao diện?
Có rủi ro; ONMATE sửa trên bản thử và rà trang, form trước khi đưa lên bản thật.
Có ảnh hưởng SEO không?
Trải nghiệm trang là một phần Google xem xét; tốc độ tốt trước hết giúp khách ở lại.
Tài liệu tham khảo:PageSpeed Insights: dữ liệu thực tế và phòng thí nghiệm ↗web.dev: Core Web Vitals ↗
03
BẮT ĐẦU
Kể điều bạn cần, bắt đầu từ đây.
Chỉ cần họ tên và số điện thoại. Các mục còn lại bỏ trống cũng được.
Yêu cầu đã sẵn sàng
Yêu cầu chưa được gửi. Bạn có thể sao chép nội dung và gửi qua Messenger hoặc kênh liên hệ bên dưới để bắt đầu trao đổi.
- Họ và tên
- Số điện thoại
- Dịch vụ
- Điều cần trao đổi
- Ngân sách
CÓ THỂ CẦN THÊM