Mỗi tuần chúng tôi nhận vài tin nhắn dạng "web em chậm quá anh xem giúp", kèm một đường link và không gì khác. Câu hỏi thật sự đằng sau đó luôn là: nguyên nhân website tải chậm nằm ở đâu, và sửa cái nào trước thì đỡ tốn tiền nhất.
Sau khi đo đủ nhiều site, một điều trở nên rõ ràng: các nguyên nhân không xuất hiện với xác suất ngang nhau, dù gần như mọi bài viết trên mạng đều liệt kê chúng thành một danh sách phẳng như thể cái nào cũng khả năng ngang cái nào. Hậu quả rất cụ thể. Chủ website đọc xong, đi kiểm "code có tối ưu không" trước, mất hai ngày họp với bên lập trình, rồi mới phát hiện thủ phạm nằm trong thư mục ảnh sản phẩm — nơi có 40 tấm JPG mỗi tấm 4MB.
Bài này là một bảng chẩn đoán chứ không phải một câu chuyện. Mười hai nguyên nhân, xếp theo tần suất chúng tôi gặp thật khi được gọi vào đo, kèm cách nhận ra từng cái và ranh giới rõ ràng giữa phần bạn tự làm được và phần buộc phải thuê. Nếu bạn muốn đọc một ca cụ thể được xử lý từ đầu đến cuối, hành trình kéo tốc độ tải web từ 8 giây xuống 1,2 giây kể lại đúng quá trình đó; ở đây chúng tôi không kể lại, chỉ đưa bảng.
Trước khi mở bảng: đo cái gì mới đúng
Một sai lầm phổ biến là bấm F5 vài lần trên máy văn phòng rồi kết luận. Máy tính bàn nối mạng dây trong công ty là điều kiện đẹp nhất mà website của bạn từng được hưởng, và nó không phải điều kiện của khách. Khách của bạn đang cầm điện thoại tầm trung, 4G hai vạch, trong quán cà phê.
Trước khi lần theo bảng bên dưới, bạn cần hai con số. Thứ nhất là TTFB (time to first byte) — thời gian từ lúc gửi yêu cầu đến lúc máy chủ trả về byte đầu tiên. Nó đo sức khỏe của máy chủ, không liên quan gì đến ảnh hay giao diện. Thứ hai là tổng dung lượng trang tính bằng MB. Hai con số này chia bảng thành hai nửa: TTFB cao thì lỗi nằm ở tầng máy chủ và database; tổng dung lượng lớn thì lỗi nằm ở nội dung trang. Phần chỉ số chi tiết hơn như LCP, CLS, INP thì Core Web Vitals giải thích dễ hiểu đã nói kỹ, chúng tôi không lặp lại.
Ngưỡng thô để bạn tự đối chiếu: TTFB dưới 0,6 giây là ổn, trên 1,5 giây là có vấn đề thật. Tổng dung lượng trang chủ dưới 2MB là chấp nhận được, trên 5MB thì gần như chắc chắn ảnh đang là thủ phạm.
Bảng 12 nguyên nhân website tải chậm, xếp theo tần suất gặp
Cột "tần suất" bên dưới là ước lượng định tính từ các ca chúng tôi được gọi vào đo, không phải một thống kê có kiểm toán — hãy đọc nó như thứ tự ưu tiên kiểm tra, không phải như số liệu nghiên cứu. Cột "mất thêm" là khoảng thời gian điển hình mà lỗi đó cộng vào thời gian tải trên mạng di động.
| # | Nguyên nhân | Tần suất gặp | Mất thêm (ước lượng) | Ai sửa |
|---|---|---|---|---|
| 1 | Ảnh chưa nén, sai kích thước hiển thị | ~8/10 site | 2 - 5 giây | Tự làm được |
| 2 | Plugin, tiện ích, module thừa còn bật | ~6/10 | 0,5 - 2 giây | Tự làm được |
| 3 | Hosting chia sẻ quá tải hoặc gói quá nhỏ | ~6/10 | 0,5 - 3 giây (TTFB) | Phải thuê |
| 4 | Không bật cache trang | ~5/10 | 0,3 - 2 giây (TTFB) | Tự làm hoặc thuê |
| 5 | Chưa nén Gzip/Brotli, chưa gộp CSS/JS | ~5/10 | 0,3 - 1 giây | Kỹ thuật, việc nhỏ |
| 6 | Script bên thứ ba tích tụ (pixel, chat, remarketing cũ) | ~5/10 | 0,5 - 2,5 giây | Tự làm được |
| 7 | Không dùng CDN, máy chủ đặt xa khách | ~4/10 | 0,3 - 1,5 giây | Phải thuê |
| 8 | Font chữ và bộ icon nặng, chặn hiển thị | ~4/10 | 0,3 - 1 giây | Kỹ thuật, việc nhỏ |
| 9 | Slider hoặc video tự phát ngay đầu trang | ~3/10 | 1 - 3 giây | Tự làm được |
| 10 | Database phình: log, revision, session rác | ~3/10 | 0,5 - 3 giây (TTFB) | Phải thuê |
| 11 | Redirect chồng nhiều chặng, HTTP sang HTTPS lòng vòng | ~2/10 | 0,2 - 0,8 giây | Tự làm hoặc thuê |
| 12 | Code hoặc kiến trúc sai (truy vấn N+1, tải toàn bộ dữ liệu) | ~2/10 | 1 - 6 giây (TTFB) | Phải thuê, đắt |
Đọc bảng này theo chiều dọc sẽ thấy điều đáng chú ý nhất: code tồi nằm cuối bảng, không phải đầu bảng. Trong phần lớn ca chúng tôi xử lý, ba dòng đầu tiên giải thích được đa số thời gian chờ, và ba dòng đó chẳng dòng nào đòi viết lại một dòng code nghiệp vụ nào. Người ta hay nhảy ngay đến kết luận "chắc web viết ẩu" vì đó là kết luận dễ nhất khi không có dữ liệu — trong khi thứ đang giết tốc độ là 40 tấm ảnh chưa ai nén.
Chiều ngược lại cũng đúng và cần nói thẳng: nếu bạn đã làm hết dòng 1 đến 9 mà TTFB vẫn 2 giây, thì dòng 10 và 12 là chỗ vấn đề nằm, và đó là phần tốn tiền thật.
Năm việc bạn tự làm được trong một buổi chiều
Không cần lập trình viên, không cần chờ báo giá. Làm xong năm việc này rồi hãy đo lại, phần lớn site sẽ khác hẳn.
Nén và xuất lại ảnh. Quy tắc đơn giản: ảnh hiển thị rộng 800px thì đừng tải lên file rộng 4000px. Xuất lại ở đúng kích thước cần dùng, chuyển sang định dạng WebP, đặt trần mỗi ảnh dưới 200KB cho ảnh sản phẩm và dưới 400KB cho ảnh banner. Riêng việc này thường cắt được nửa thời gian tải.
Gỡ những gì không còn ai dùng. Mở danh sách plugin và danh sách thẻ theo dõi, hỏi từng cái: ba tháng qua có ai mở kết quả của nó ra xem không? Pixel của chiến dịch năm ngoái, công cụ chat đã đổi nhà cung cấp, script heatmap dùng thử một tuần — chúng vẫn đang tải trên từng lượt truy cập.
Bật cache. Nếu bạn dùng WordPress hay một nền tảng phổ thông, bật cache là cài một plugin và tick vài ô. Trang được lưu sẵn thành file tĩnh thay vì dựng lại từ database mỗi lần có người ghé — đây là thay đổi rẻ nhất có tác động lên TTFB.
Bỏ slider và video tự phát ở đầu trang. Slider năm ảnh ở đầu trang chủ buộc trình duyệt tải cả năm ảnh trước khi vẽ được gì. Nó cũng gần như không tăng tỷ lệ chuyển đổi. Thay bằng một ảnh tĩnh cộng một nút bấm rõ ràng.
Dọn redirect. Gõ địa chỉ site của bạn không có "https" và không có "www", xem trình duyệt nhảy qua bao nhiêu chặng mới tới đích. Ba, bốn chặng là chuyện thường gặp và mỗi chặng tốn một vòng kết nối. Gộp lại còn một chặng duy nhất.
Ba việc cần người kỹ thuật nhưng chưa cần viết lại
Đây là vùng giữa: bạn không tự làm được, nhưng cũng không phải làm lại website. Chi phí thường nằm trong một, hai ngày công.
Cache tầng máy chủ (Redis, OPcache, cache đối tượng) khác với cache plugin ở chỗ nó giảm tải trực tiếp cho database. Với site có nhiều người dùng đăng nhập — thành viên, giỏ hàng, tài khoản — cache trang tĩnh không dùng được nhiều, cache tầng máy chủ mới là thứ ăn thua.
CDN đưa ảnh và file tĩnh ra các điểm gần khách. Nếu máy chủ của bạn đặt ở Singapore hay Mỹ mà khách chủ yếu ở Việt Nam, mỗi file phải đi một quãng đường vô ích. CDN xử lý đúng lớp vấn đề này và thường là thay đổi rẻ so với hiệu quả.
Tối ưu database. Bảng log tăng trưởng không kiểm soát, revision bài viết chất đống, session rác của khách vãng lai, index thiếu ở đúng cột hay được truy vấn. Một buổi dọn dẹp cộng thêm vài index đúng chỗ có thể kéo TTFB từ 2 giây xuống dưới nửa giây mà không ai phải chạm vào giao diện.
Khi nào vấn đề là hosting, khi nào là code
Đây là câu hỏi tốn tiền nhất trong toàn bộ chủ đề, vì trả lời sai theo hướng này thì bạn nâng cấp máy chủ đắt tiền mà không nhanh hơn, trả lời sai theo hướng kia thì bạn trả tiền viết lại phần mềm mà đáng ra chỉ cần đổi gói.
Phép thử để phân biệt: mở một trang gần như trống của site — trang chính sách, trang liên hệ, thứ gì đó không có ảnh và không truy vấn dữ liệu. Đo TTFB của nó.
- TTFB trang trống vẫn cao (trên 1 giây): vấn đề ở hạ tầng. Máy chủ đang thiếu tài nguyên hoặc bị hàng xóm trên gói chia sẻ ăn hết CPU.
- TTFB trang trống thấp nhưng trang danh mục sản phẩm chậm: vấn đề ở truy vấn và code. Máy chủ khỏe, chỉ là ứng dụng bắt nó làm việc ngu.
- Cả hai đều chậm: thường là database phình cộng hosting yếu — dòng 3 và dòng 10 cùng lúc.
Nếu kết luận rơi vào nhóm hạ tầng, bước tiếp theo là chọn đúng gói theo tải thật chứ không theo cảm tính, và chi phí thuê VPS cho doanh nghiệp có bảng đối chiếu cấu hình với lượng truy cập. Nếu bạn còn đang phân vân giữa các loại nền tảng thì bài VPS, hosting hay cloud chọn theo giai đoạn của website giải quyết đúng câu hỏi đó. Về phía chúng tôi, dịch vụ máy chủ có gói VPS khởi điểm 199.000đ/tháng, cam kết uptime 99.9%, backup hằng ngày lưu 30 ngày và phản hồi sự cố mức P1 trong 15 phút.
Nếu kết luận rơi vào nhóm code, hãy hỏi thêm một câu trước khi quyết định viết lại: website đang chạy trên nền tảng nào và nền tảng đó có phải nguyên nhân gốc không. Một site WordPress chất 30 plugin và một site code tay ẩu chậm vì hai lý do khác hẳn nhau, và cách sửa cũng khác — chúng tôi đã bóc tách ở bài WordPress hay code tay: chọn nền tảng nào cho website doanh nghiệp.
Chi phí tham khảo nếu bạn thuê ngoài
Khoảng giá tham khảo thị trường tại thời điểm viết (08/2026), chưa gồm VAT. Con số thực tế phụ thuộc quy mô site, nền tảng và tình trạng bàn giao mã nguồn, nên hãy xem đây là khung để đọc báo giá chứ không phải cam kết giá.
| Hạng mục | Khoảng giá tham khảo | Thời gian điển hình | Khi nào cần |
|---|---|---|---|
| Đo và báo cáo chẩn đoán tốc độ | 0 - 3 triệu | 1 - 2 ngày | Trước mọi việc khác |
| Tối ưu ảnh hàng loạt + lazy load | 3 - 8 triệu | 1 - 3 ngày | Dòng 1 của bảng |
| Dọn plugin, script, gộp CSS/JS | 3 - 7 triệu | 1 - 2 ngày | Dòng 2, 5, 6 |
| Cài cache tầng máy chủ + CDN | 5 - 12 triệu | 2 - 4 ngày | Dòng 4, 7 |
| Tối ưu database, thêm index | 8 - 20 triệu | 3 - 7 ngày | Dòng 10 |
| Chuyển hosting sang VPS/cloud | 5 - 15 triệu (phí chuyển) | 1 - 3 ngày | Dòng 3 |
| Viết lại phần chậm của ứng dụng | 30 - 150 triệu trở lên | 3 tuần trở lên | Dòng 12, sau cùng |
Nếu bạn đang cân nhắc làm site mới thay vì tối ưu site cũ, phép so sánh nên đặt cạnh chi phí làm website bán hàng chứ không so với riêng khoản tối ưu — một site cũ tối ưu tốt vẫn thường rẻ hơn làm lại, trừ khi mã nguồn đã không còn ai bảo trì được.
Quy trình 30 phút để loại trừ theo đúng thứ tự
- Đo TTFB và tổng dung lượng trang chủ trên điều kiện di động. Ghi lại hai con số.
- Nếu tổng dung lượng trên 3MB, mở danh sách file tải về, sắp xếp theo dung lượng giảm dần. Gần như chắc chắn nhóm đầu là ảnh — bạn đã tìm ra dòng 1.
- Nếu TTFB trên 1 giây, làm phép thử trang trống ở phần trên để tách hạ tầng khỏi code.
- Đếm số script bên thứ ba đang chạy. Trên 8 script là dấu hiệu của dòng 6.
- Kiểm tra cache đã bật chưa bằng cách tải trang hai lần và so sánh thời gian phản hồi lần hai.
- Chỉ sau khi bốn bước trên đều sạch mới đặt câu hỏi về chất lượng code. Đây là bước cuối, không phải bước đầu.
Làm đúng thứ tự này, bạn sẽ biết mình đang đứng ở dòng nào của bảng trước khi gọi cho bất kỳ ai. Và khi gọi, bạn hỏi được câu hỏi cụ thể thay vì câu "web em chậm quá".
Nếu bạn đã đo mà vẫn không rõ con số đang chỉ về đâu, gửi địa chỉ website kèm hai con số TTFB và dung lượng trang cho chúng tôi — đội kỹ thuật Microads sẽ đọc và nói thẳng bạn đang ở dòng nào, tự sửa được hay phải thuê, hoàn toàn miễn phí. Gọi 0919 788 815 hoặc gửi khanhn@microads.vn, và nếu cần bàn rộng hơn về hạ tầng thì dịch vụ phát triển phần mềm của Microads đã đồng hành với hơn 200 khách hàng từ 2015 theo đúng cách tiếp cận này: đo trước, sửa theo thứ tự tác động, không bán thứ bạn chưa cần.
