Website của bạn chậm, PageSpeed báo TTFB cao, và nhà cung cấp gợi ý nâng lên gói đắt hơn? Khoan vội. Nhiều website nâng hosting xong vẫn chậm, vì vấn đề thật nằm ở cache, plugin, database, vị trí máy chủ hoặc CDN.
Audit hosting website trước khi nâng gói giúp bạn biết nên mua thêm tài nguyên, sửa cache, chuyển máy chủ hay tối ưu WordPress trước.
Tóm tắt nhanh
- Đừng nâng hosting chỉ vì thấy website chậm; hãy đo TTFB, cache, máy chủ gốc và tài nguyên trước.
- TTFB cao qua CDN chưa chắc do hosting yếu; cần đo riêng bản cache HIT, MISS và request đi thẳng về máy chủ gốc.
- Nếu cache thường xuyên bị BYPASS hoặc DYNAMIC, nâng CPU/RAM có thể không giải quyết gốc vấn đề.
- Với WordPress, hãy kiểm tra PHP, database, plugin, object cache và PHP workers trước khi đổi gói.
- Nên nâng gói khi đã có bằng chứng: tài nguyên đầy, lỗi 502/504, database nghẽn hoặc lượng truy cập vượt khả năng gói hiện tại.
Audit hosting website là gì?
Audit hosting website là quá trình kiểm tra dữ liệu hiệu năng và tài nguyên máy chủ trước khi quyết định nâng gói, chuyển nhà cung cấp hoặc tối ưu cấu hình. Mục tiêu là tìm đúng điểm nghẽn thay vì mua thêm tài nguyên theo cảm giác.
Nói dễ hiểu, bạn không chỉ hỏi “hosting có yếu không”, mà hỏi cụ thể hơn: máy chủ phản hồi chậm ở đâu, cache có hoạt động không, truy cập có đang đi qua CDN không, database có nghẽn không, PHP có đủ worker không và gói hiện tại có thật sự chạm giới hạn không.
Fan-out query quanh chủ đề này thường xoay quanh TTFB cao, cache HIT/MISS, đo origin server và thời điểm nâng VPS. Vì vậy bài này đi theo hướng kiểm tra trước, quyết định sau.
Bạn đang đọc bài viết thuộc chuyên mục Tăng tốc website của VietnamTutor — nơi mình ưu tiên đo đúng nguyên nhân trước khi khuyên bạn mua thêm công cụ hoặc tài nguyên.
Vì sao nâng hosting chưa chắc làm website nhanh hơn?
Nâng hosting chỉ giúp rõ rệt khi điểm nghẽn thật nằm ở tài nguyên máy chủ hoặc năng lực xử lý của nhà cung cấp hiện tại. Nếu vấn đề nằm ở cache bị bỏ qua, redirect, ảnh LCP, JavaScript, database query chậm hoặc vị trí máy chủ, nâng gói có thể chỉ làm hóa đơn tăng.
web.dev xem TTFB là chỉ số nền tảng vì nó xảy ra trước các chỉ số hiển thị như FCP và LCP; nếu TTFB cao, các chỉ số phía sau thường bị kéo chậm theo [1]. Nhưng web.dev cũng nhắc rằng caching có thể che giấu backend chậm, nên cần có cách bỏ qua CDN/cache để đo thời gian máy chủ thật sự xử lý [1].
Đây là điểm nhiều chủ website dễ nhầm. Khi bạn đo bằng PageSpeed Insights, GTmetrix hoặc trình duyệt, kết quả có thể là bản đã qua CDN. Nếu trang đang HIT cache, số đo đẹp không chứng minh máy chủ gốc khỏe. Ngược lại, nếu cache MISS đúng lúc test, kết quả xấu cũng chưa đủ để kết luận phải nâng gói.
Mình khuyên bạn đo trước, mua sau. Website chậm cần được chẩn đoán theo dữ liệu, không nên xử lý bằng cảm giác.
Đo TTFB thế nào cho đúng?
Để đo TTFB đúng, bạn cần xem cả dữ liệu người dùng thật, dữ liệu lab và vài lần đo thủ công từ các đường đi khác nhau. Một con số đơn lẻ không đủ để quyết định nâng gói hosting.
Google Search Central định nghĩa Core Web Vitals là nhóm chỉ số trải nghiệm người dùng thực tế, gồm LCP, INP và CLS; ngưỡng tốt là LCP trong 2,5 giây, INP dưới 200 mili giây và CLS dưới 0,1 [2]. PageSpeed Insights dùng phân vị 75 để phản ánh trải nghiệm của phần lớn người dùng, nhất là nhóm gặp điều kiện khó hơn [3]. Vì vậy bạn nên nhìn dữ liệu 28 ngày, không chỉ một lần test.
Quy trình đo gọn:
- Mở PageSpeed Insights để xem dữ liệu thực tế nếu URL đủ mẫu.
- Đo lại trang chủ, trang dịch vụ, bài blog và trang có form/chuyển đổi.
- Dùng Chrome DevTools, tab Network, xem document request và mục Waiting for server response.
- Đo từ vị trí gần khách hàng chính, ví dụ Việt Nam hoặc Singapore nếu khách chủ yếu ở Việt Nam.
- So sánh URL có CDN/cache và URL bỏ cache có kiểm soát.
Nếu bạn cần đào sâu riêng phần này, bài audit TTFB cho WordPress đã giải thích kỹ hơn về waterfall, server response time và cách đọc số đo.
Kiểm tra cache HIT/MISS ra sao?
Cache HIT/MISS cho biết request có được phục vụ từ cache hay phải quay về máy chủ gốc. Đừng chỉ kiểm tra Cloudflare; hãy đọc cả cache của trình duyệt, plugin WordPress, máy chủ web, reverse proxy và CDN nếu có.
Trước hết, dùng cửa sổ ẩn danh, không đăng nhập WordPress, rồi gửi cùng một URL 2-3 lần. Lần đầu có thể MISS vì cache chưa có dữ liệu; lần sau mới cho thấy cache có được tái sử dụng không. MDN giải thích Cache-Control là header điều khiển cách trình duyệt và shared cache lưu response; max-age cho biết response còn mới trong bao lâu, còn Age cho biết response đã nằm trong cache bao nhiêu giây [4].
# Chạy 2-3 lần cùng một URL để xem cache có được dùng lại không curl -I https://example.com/ # Nếu muốn nhìn nhanh các header liên quan cache curl -sI https://example.com/ | grep -iE "cache|age|etag|vary|set-cookie|via"
Với WordPress dùng plugin cache, mỗi plugin và mỗi hosting có thể dùng header khác nhau. LiteSpeed Cache thường để lại x-litespeed-cache; tài liệu LiteSpeed mô tả giá trị hit là phục vụ từ cache, miss là chưa có cache và phải tạo response mới [5]. Một số plugin như WP Rocket, Cache Enabler hoặc W3 Total Cache không phải lúc nào cũng có header HIT/MISS riêng, nên bạn cần nhìn thêm cache-control, age, etag, last-modified, set-cookie và thời gian phản hồi.
# WordPress trên LiteSpeed Cache x-litespeed-cache: hit cache-control: public, max-age=604800 # WordPress có page cache nhưng không có header riêng cache-control: public, max-age=3600 age: 128 etag: "abc123" # Trang động hoặc đang bị loại khỏi cache cache-control: no-cache, no-store, must-revalidate set-cookie: wordpress_logged_in_... set-cookie: woocommerce_items_in_cart=1
Nếu website không dùng WordPress, nguyên tắc vẫn giống nhau: kiểm tra header của lớp cache đang dùng. Nginx FastCGI cache có thể dùng header tùy chỉnh như x-fastcgi-cache; Varnish hay một số CDN có thể dùng x-cache, via hoặc age. Tên header không hoàn toàn chuẩn hóa, nên hãy hỏi nhà cung cấp hosting/CDN đang bật lớp cache nào.
# Ví dụ reverse proxy hoặc CDN không phải Cloudflare x-cache: HIT age: 240 via: 1.1 varnish cache-control: public, s-maxage=600 # Ví dụ cache máy chủ gốc tự cấu hình x-fastcgi-cache: HIT cache-control: public, max-age=300
Nếu mọi request công khai đều có no-store, private, nhiều Set-Cookie, hoặc luôn MISS sau nhiều lần tải lại, hãy xử lý cache trước khi nâng gói. Nếu riêng Cloudflare là lớp bạn đang dùng, bài Cloudflare Cache Rules WordPress đã đi sâu vào cf-cache-status và rule order.
Kiểm tra máy chủ gốc cần nhìn những gì?
Máy chủ gốc là nơi website thật sự chạy PHP, truy vấn database và tạo HTML khi cache không có sẵn. Nếu máy chủ gốc chậm, cache có thể che bớt vấn đề nhưng không giải quyết triệt để cho trang động, người dùng đăng nhập hoặc lúc cache hết hạn.
Hãy kiểm tra bốn nhóm dữ liệu:
- CPU và RAM: có thường xuyên chạm 80-90% trong giờ cao điểm không?
- PHP workers: có hàng đợi, lỗi 502/504 hoặc request treo khi nhiều người truy cập không?
- Database: query chậm, bảng quá lớn, thiếu index hoặc plugin tạo truy vấn nặng không?
- I/O và storage: ổ đĩa có nghẽn khi backup, import sản phẩm hoặc chạy cron không?
Với website khách chủ yếu ở Việt Nam, vị trí máy chủ cũng đáng kiểm tra. Nếu origin ở quá xa, người dùng Việt Nam có thể bị tăng thời gian kết nối, nhất là với trang chưa cache. Bạn có thể đọc thêm bài server location cho website Việt Nam để chọn vị trí phù hợp hơn.
Đây là lúc bạn nên xin log hoặc biểu đồ CPU, RAM, PHP-FPM, slow query, error log, bandwidth và lỗi 5xx. Nếu nhà cung cấp chỉ khuyên “nâng gói”, bạn đang thiếu cơ sở ra quyết định.
Với WordPress, nên kiểm tra gì trước?
Với WordPress, audit hosting website cần đi kèm kiểm tra PHP/database, plugin nặng, cache trang, object cache và cron. WordPress có thể chậm vì gói hosting yếu, nhưng cũng có thể chậm vì cách website được xây.
WordPress.org hiện khuyến nghị host hỗ trợ PHP 8.3 trở lên, MariaDB 10.6 trở lên hoặc MySQL 8.0 trở lên, cùng HTTPS cho mọi website [6]. WordPress vẫn có thể chạy trên phiên bản cũ hơn, nhưng WordPress.org cảnh báo các bản cũ đã hết vòng đời chính thức có thể tạo rủi ro bảo mật và nên nâng cấp [6].
Checklist WordPress nên kiểm tra:
- PHP version, memory limit, max execution time và OPcache.
- Plugin tạo query nặng: page builder, filter sản phẩm, thống kê, form, membership, popup.
- Database autoload options quá lớn hoặc bảng log phình to.
- Object cache như Redis/Memcached có bật và hoạt động không.
- WP-Cron có chạy dồn vào giờ cao điểm không.
- Trang động như giỏ hàng, thanh toán, tài khoản có bị cache sai hoặc không cache được không.
Nếu website đã có lượng truy cập rõ ràng, bài chọn hosting theo quy mô website sẽ giúp đặt câu hỏi đúng hơn: website giới thiệu, WooCommerce, membership hay hệ thống dữ liệu động cần cách chọn gói khác nhau.
Khi nào nên nâng gói hosting?
Bạn nên nâng gói hosting khi dữ liệu cho thấy gói hiện tại thật sự thiếu tài nguyên hoặc giới hạn vận hành, sau khi đã xử lý các lỗi cấu hình rõ ràng. Nâng gói là quyết định hợp lý khi có bằng chứng, không phải khi chỉ có cảm giác.
| Dấu hiệu | Nên làm gì trước? | Có nên nâng gói? |
|---|---|---|
| TTFB origin cao cả khi bỏ CDN | Kiểm tra PHP, database, plugin, cache | Có thể, nếu tài nguyên đã chạm giới hạn |
| Cache công khai không bao giờ HIT | Sửa plugin cache, cookie, header, query string | Chưa vội |
| CPU/RAM đầy giờ cao điểm | Xem log, tối ưu query, giảm cron | Nên cân nhắc |
| Lỗi 502/504 khi nhiều người truy cập | Kiểm tra PHP workers và upstream timeout | Thường nên nâng hoặc đổi kiến trúc |
| LCP chậm do ảnh hero | Tối ưu ảnh, preload, kích thước, định dạng | Không phải ưu tiên đầu tiên |
| Khách ở Việt Nam, server quá xa | Dùng CDN hoặc chuyển origin gần hơn | Có thể đổi vị trí hơn là nâng tài nguyên |
Nếu LCP chậm chủ yếu vì ảnh hoặc tài nguyên phía frontend, nâng hosting chỉ giúp một phần. Khi đó hãy đọc thêm bài tối ưu ảnh WordPress để cải thiện LCP trước khi mua gói cao hơn.
Cách ra quyết định gọn: nếu cache đã đúng, query đã được xử lý, plugin nặng đã giảm, nhưng giờ cao điểm vẫn đầy CPU/RAM hoặc sinh lỗi 5xx, nâng gói là hợp lý. Nếu cache còn sai và dữ liệu đo chưa tách origin/CDN, hãy sửa audit trước.
Mẫu biên bản audit hosting
Một biên bản ngắn giúp bạn so sánh trước và sau khi tối ưu, đồng thời tránh tranh luận cảm tính với nhà cung cấp hosting. Mục tiêu là ghi lại số đo, kết luận và hành động tiếp theo.
Ngày kiểm tra: 2026-06-09 Website: example.com Người kiểm tra: [Tên] 1. TTFB và Core Web Vitals - PageSpeed Insights URL: - LCP p75: - INP p75: - CLS p75: - TTFB lab: 2. Cache/CDN - CDN đang dùng: - Header cache trang chủ: - Header cache trang dịch vụ: - Có Age header không: - Trang nào luôn MISS hoặc không cache: 3. Máy chủ gốc - CPU giờ cao điểm: - RAM giờ cao điểm: - Lỗi 502/504: - PHP workers: - Slow query: 4. WordPress - PHP version: - Database version: - Plugin nặng: - Object cache: - WP-Cron: 5. Kết luận - Nên sửa cấu hình: - Nên tối ưu WordPress: - Nên nâng gói hoặc đổi nhà cung cấp: - Người phụ trách: - Deadline:
Biên bản này chỉ cần đủ rõ để bạn biết vấn đề nằm ở đâu, ai xử lý và khi nào đo lại. Hãy làm việc này trước khi trả thêm tiền mỗi tháng cho gói hosting cao hơn.
Nguồn tham khảo
- web.dev: Optimize Time to First Byte
- Google Search Central: Understanding Core Web Vitals
- Google Developers: About PageSpeed Insights
- MDN: Cache-Control header
- http.dev: X-LiteSpeed-Cache header
- WordPress.org: Requirements
- Cloudflare Docs: Cloudflare cache responses
Các câu hỏi thường gặp
TTFB cao có nên nâng hosting ngay không?
Chưa nên vội. Bạn cần đo TTFB qua CDN, TTFB máy chủ gốc, trạng thái cache, CPU/RAM, PHP workers và database trước. Nếu điểm nghẽn là cache sai hoặc plugin nặng, nâng hosting có thể không cải thiện nhiều.
Cache HIT và MISS khác nhau thế nào?
HIT nghĩa là nội dung được phục vụ từ cache, thường nhanh hơn. MISS nghĩa là cache chưa có nội dung đó nên request phải quay về máy chủ gốc. Nếu MISS hoặc BYPASS xảy ra quá thường xuyên, máy chủ sẽ chịu tải nhiều hơn.
Website WordPress nhỏ có cần VPS không?
Không nhất thiết. Website giới thiệu nhỏ có thể chạy tốt trên hosting hoặc managed WordPress tốt nếu cache đúng và tài nguyên đủ. VPS phù hợp hơn khi bạn cần quyền kiểm soát, có người vận hành và có dữ liệu cho thấy gói hiện tại đã chạm giới hạn.
Nâng CPU và RAM có làm Core Web Vitals tốt hơn không?
Có thể, nhưng chỉ khi máy chủ đang thiếu tài nguyên thật. Nếu Core Web Vitals xấu do ảnh LCP, JavaScript, font, cache bị bỏ qua hoặc vị trí máy chủ xa, nâng CPU/RAM không phải giải pháp chính.
Nên đo website trong bao lâu trước khi quyết định nâng gói?
Tối thiểu nên xem dữ liệu vài ngày có giờ cao điểm, tốt hơn là kết hợp dữ liệu thực tế 28 ngày từ PageSpeed Insights hoặc Search Console với log hosting. Với website có chiến dịch quảng cáo, hãy đo trong giai đoạn có traffic thật.
Audit hosting website không phải để trì hoãn nâng cấp, mà để nâng cấp đúng lúc và đúng chỗ. Nếu dữ liệu cho thấy gói hiện tại đã nghẽn, hãy nâng. Nếu dữ liệu chỉ ra cache, plugin, database hoặc vị trí máy chủ mới là vấn đề, hãy sửa ở đó trước. Làm vậy, bạn tiết kiệm tiền hơn và website cũng nhanh hơn thật.
