Website chậm dù thuê hosting mạnh vì hosting chỉ quyết định một phần rất nhỏ của thời gian tải trang: khoảng thời gian máy chủ trả về tệp HTML đầu tiên. Phần còn lại, thường chiếm hơn 90%, diễn ra trong trình duyệt của khách: tải và xử lý CSS, font, JavaScript, ảnh, và mã của bên thứ ba như công cụ đo lường, quảng cáo, chat. Ngày 25/09/2026, chúng tôi đo ba trang chủ bằng Lighthouse. Máy chủ của cả ba trả lời trong 21 đến 225 mili giây, nhưng nội dung chính hiện ra sau 7,0 đến 18,5 giây ở chế độ di động. Nâng cấp hosting cho cả ba trang này gần như không đổi được gì. Bài này đi qua số đo, chỉ ra thủ phạm của từng trang, kể cả trang của chính Alodev, và nêu khi nào nâng hosting mới đúng chỗ.
Hosting chỉ lo được mili giây đầu tiên
Một lần tải trang đi qua nhiều chặng. Trình duyệt hỏi tên miền, bắt tay mã hoá, gửi yêu cầu; máy chủ dựng HTML và gửi về. Đến đây là phần hosting chịu trách nhiệm, đo bằng chỉ số thời gian tới byte đầu tiên (TTFB). Sau đó trình duyệt đọc HTML, phát hiện hàng chục tệp CSS, JavaScript, font, ảnh cần tải thêm, tải chúng, chạy JavaScript, tính bố cục, rồi mới vẽ nội dung lên màn hình. Google đo khoảnh khắc khối nội dung lớn nhất hiện ra bằng chỉ số LCP, và xếp loại tốt khi LCP dưới 2,5 giây.
Biểu đồ trên là toàn bộ lập luận của bài. Máy chủ của techcrunch.com trả lời nhanh nhất trong ba trang, 21 mili giây, nhưng trang đó lại chậm nhất, 18,5 giây. Nếu chủ website này nâng gói hosting lên gấp đôi, trong trường hợp tốt nhất họ tiết kiệm được khoảng 10 mili giây trên 18.500. Tiền nên đặt vào chỗ khác.
alodev.vn: máy chủ 85 mili giây, trang trắng gần 4 giây
Chúng tôi đo trang của mình trước, và kết quả không đẹp. Điểm hiệu suất di động 63 đến 66, LCP 8,0 đến 8,9 giây, trong khi máy chủ trả lời trong 83 đến 88 mili giây ở cả ba lần. Hai chỉ số còn lại tốt: tổng thời gian chặn (TBT) 36 đến 80 mili giây, độ dịch chuyển bố cục (CLS) bằng 0. Nghĩa là trang không giật và không đơ, nó chỉ hiện ra muộn.
Lighthouse chia thời gian LCP thành bốn phần và quy 94% cho "độ trễ khi hiển thị": tài liệu đã về, khối chữ cần vẽ đã có trong HTML, nhưng trình duyệt chưa vẽ. Báo cáo chỉ ra những gì trình duyệt phải chờ. Trang tải 17 tệp CSS (115 KiB), trong đó 4 tệp chặn hiển thị với mức tiết kiệm ước tính 850 mili giây; nhiều tệp là CSS của giao diện cũ vẫn nạp chung cho toàn site. Trang tải 20 tệp font (217 KiB) cho nhiều độ đậm và bảng chữ. Tệp nặng nhất của cả trang là mã Google Tag Manager, 173 KiB, trong đó Lighthouse ước tính 71 KiB không được dùng tới.
Không mục nào trong danh sách đó liên quan tới máy chủ. Việc cần làm là gộp và cắt CSS thừa, giảm số biến thể font, tải mã đo lường sau khi trang đã hiện. Đó là việc của người viết mã giao diện, và chúng tôi ghi nó vào danh sách việc của chính website này.
trancongthang.vn: luồng chính bận 10 giây vì hiệu ứng
Blog trancongthang.vn cũng viết bằng Next.js, máy chủ trả lời 223 đến 251 mili giây, LCP 6,1 đến 7,1 giây. Điểm lạ nằm ở một chỉ số khác: tổng thời gian luồng chính của trình duyệt phải làm việc là 10,3 đến 11,2 giây, dù thời gian bị chặn (TBT) chỉ 29 đến 170 mili giây. Một tệp JavaScript duy nhất chiếm 6,4 đến 7,2 giây trong số đó, nhưng chỉ khoảng 1,1 giây là chạy mã; phần lớn còn lại là tính lại kiểu và bố cục mà tệp đó kích hoạt.
Hình dạng đó thường là dấu hiệu của hiệu ứng chuyển động chạy liên tục: mỗi khung hình đổi vị trí một phần tử, trình duyệt phải tính lại bố cục. Giao diện blog làm lại tháng 9/2026 dùng thư viện cuộn mượt và dải thẻ ảnh chạy trên vòng cung bằng requestAnimationFrame. Chúng tôi chưa khoanh chính xác hiệu ứng nào gây ra phần lớn chi phí, nhưng đây là nghi phạm đầu tiên cần đo tách. Trên máy tính mạnh, người đọc không thấy gì; trên điện thoại tầm trung, pin và độ mượt sẽ trả giá.
Blog này cũng là ví dụ về sức nặng của mã bên thứ ba. Lịch sử kho mã ghi ngày 19/08/2026 gỡ Google Analytics: tệp gtag.js nặng 166 KB, chiếm 51% dung lượng trang trên di động, và sau khi gỡ, dung lượng trang di động giảm từ 323 KB xuống 157 KB. Hiện ảnh minh hoạ lấy từ kho Unsplash chiếm 203 KiB và là phần bên thứ ba lớn nhất của trang.
techcrunch.com: 73% dung lượng đến từ bên thứ ba
Trang chủ techcrunch.com chạy WordPress trên hạ tầng rất mạnh: HTML về trong 19 đến 22 mili giây ở cả ba lần đo. Nhưng trang nặng 4,4 MB, gọi từ 271 tới hơn 430 yêu cầu tuỳ lần, và ở lần đo đầu tiên 371 trong 435 yêu cầu, 3.265 KiB trong 4.468 KiB, thuộc tên miền bên thứ ba. Điểm hiệu suất 29 đến 40, TBT 0,8 đến 1,2 giây, LCP ở hai trong ba lần đo vượt 18 giây.
Một trang tin tức sống bằng quảng cáo có lý do để chấp nhận chi phí này. Website doanh nghiệp thì hiếm khi có. Nhưng cơ chế thì giống nhau: mỗi đoạn mã dán vào thẻ head, dù là công cụ đo lường, bản đồ nhiệt, chat trực tuyến, pixel quảng cáo, đều tải về và chạy trên điện thoại của khách. Bộ phận marketing thêm chúng qua trình quản lý thẻ mà không cần lập trình viên, và không ai đo lại sau đó.
Bảng chẩn đoán: nguyên nhân nào, nâng hosting có giúp không
| Nguyên nhân | Nhìn thấy ở đâu trong Lighthouse | Nâng hosting có giúp | Cách xử lý |
|---|---|---|---|
| Máy chủ dựng trang chậm, cơ sở dữ liệu chậm | Thời gian phản hồi của máy chủ cao (trên 0,8 giây) | Có | Nâng cấu hình, thêm bộ nhớ đệm, tối ưu truy vấn |
| CSS chặn hiển thị, CSS thừa | Yêu cầu chặn quá trình hiển thị; CSS không dùng | Không | Gộp, cắt, nạp CSS theo trang |
| Quá nhiều font và biến thể | Nhiều yêu cầu loại Font; LCP là khối chữ | Không | Giảm độ đậm, cắt bảng chữ, dùng font-display |
| JavaScript nặng hoặc chạy liên tục | Thời gian khởi động JS, công việc luồng chính | Không | Tách mã, bỏ hiệu ứng không cần, tải chậm |
| Mã bên thứ ba | Third-party summary; tệp nặng nhất thuộc tên miền khác | Không | Rà danh sách thẻ, tải sau khi trang hiện, bỏ thẻ không dùng |
| Ảnh quá lớn | Kích thước ảnh, định dạng ảnh | Không | Nén, đổi WebP hoặc AVIF, đúng kích thước hiển thị |
| Khách ở xa máy chủ | Thời gian phản hồi cao ở khách nước ngoài | Một phần | Dùng CDN, đặt máy chủ gần khách |
Trong bảy dòng, chỉ một dòng rưỡi là việc của hosting. Đó cũng là lý do lời khuyên "nâng gói hosting cho nhanh" thường không có tác dụng: nó giải bài toán ở dòng đầu tiên, trong khi website đang hỏng ở các dòng dưới.
Khi nào KHÔNG nên nâng cấp hosting
- Thời gian phản hồi máy chủ trong Lighthouse hoặc PageSpeed Insights đã dưới 0,8 giây: phần chậm nằm ở trình duyệt, nâng hosting không đổi được LCP.
- Chỉ số tệ nhất là TBT hoặc thời gian khởi động JavaScript: đó là CPU điện thoại của khách, không phải CPU máy chủ.
- Tệp nặng nhất trong báo cáo thuộc tên miền khác: tiền hosting không mua được tốc độ cho máy chủ của Google, Facebook hay nhà quảng cáo.
- Chưa đo trước khi nâng: nếu không có số trước và sau, không ai biết khoản tiền bỏ ra đổi được gì.
Ngược lại, nâng hosting là đúng khi thời gian phản hồi máy chủ cao và tăng theo giờ cao điểm, khi máy chủ báo hết bộ nhớ hoặc CPU, khi trang quản trị hay giỏ hàng chậm vì cơ sở dữ liệu, hoặc khi website hay mất kết nối. Những triệu chứng đó đo được bằng công cụ giám sát máy chủ, và nên đo trước khi mua.
Một lưu ý về cách đọc số: Lighthouse đo trong phòng thí nghiệm với một cấu hình giả lập cố định, nên lý tưởng để so trước và sau một thay đổi. Google xếp hạng dựa trên dữ liệu người dùng thật (Chrome UX Report), có thể tốt hơn hoặc tệ hơn số phòng thí nghiệm tuỳ thiết bị và mạng của khách. Dùng Lighthouse để tìm thủ phạm, dùng dữ liệu thật trong Search Console để biết khách đang chịu gì.
Câu hỏi thường gặp
Vì sao website của tôi chậm dù hosting cấu hình cao?
Vì hosting chỉ quyết định thời gian máy chủ trả HTML, thường vài chục đến vài trăm mili giây. Phần lớn thời gian tải nằm ở trình duyệt: CSS chặn hiển thị, font, JavaScript, ảnh và mã bên thứ ba. Mở Lighthouse, xem thời gian phản hồi máy chủ: nếu dưới 0,8 giây, thủ phạm nằm ở phía trình duyệt.
Kiểm tra tốc độ website bằng công cụ gì?
PageSpeed Insights của Google cho cả số phòng thí nghiệm (Lighthouse) lẫn dữ liệu người dùng thật nếu website đủ lượt truy cập. Lighthouse có sẵn trong Chrome (DevTools) và chạy được bằng dòng lệnh để đo lặp lại nhiều lần, như cách bài này làm.
Điểm Lighthouse bao nhiêu là đạt?
Lighthouse xếp 90 đến 100 là tốt, 50 đến 89 cần cải thiện, dưới 50 là kém. Với doanh nghiệp, đáng theo dõi hơn điểm tổng là ba chỉ số Core Web Vitals trên dữ liệu thật: LCP dưới 2,5 giây, INP dưới 200 mili giây, CLS dưới 0,1.
Google Analytics có làm chậm website không?
Có, ở mức đo được. Trong lần đo alodev.vn, tệp Google Tag Manager là tệp nặng nhất trang, 173 KiB; blog trancongthang.vn từng giảm dung lượng trang di động từ 323 KB xuống 157 KB chỉ bằng việc gỡ Google Analytics. Nếu cần đo lường, nên tải mã sau khi trang đã hiện hoặc dùng công cụ nhẹ hơn.
Website WordPress chậm có nên chuyển hosting không?
Chỉ khi thời gian phản hồi máy chủ cao. Website WordPress chậm thường vì theme nặng, nhiều plugin nạp mã trên mọi trang và mã bên thứ ba; những thứ đó đi theo website sang hosting mới. Đo trước bằng Lighthouse rồi mới quyết định.
