Hosting WordPress: Bạn Thực Sự Trả Tiền Cho Cái Gì

Hosting WordPress được bán trong dải giá từ khoảng 3 bảng mỗi tháng đến vài trăm bảng, và các gói ở hai đầu dải tự mô tả bằng những từ gần như giống hệt. Nhanh. An toàn. Có sao lưu. Có hỗ trợ. Phần thông số giúp người mua phân biệt chúng, tức nhánh PHP nào chạy site, engine cơ sở dữ liệu nào đứng sau, có bao nhiêu lớp cache và lớp nào đang thực sự bật, thường vắng trên trang bạn được mời mua.

Sự vắng mặt đó là một phần của sản phẩm. “Quản lý” là hạng mục tiếp thị chứ không phải kỹ thuật, và không tổ chức tiêu chuẩn nào định nghĩa nó. Hai nhà cung cấp dùng cùng từ đó có thể khác nhau ở chỗ có chạy cache đối tượng bền không, bạn có được giữ plugin cache riêng không, bản sao lưu có rời hạ tầng họ được không, và bạn có mở nổi shell không.

Sau đây là phần thông số những trang đó bỏ qua: WordPress đòi hỏi gì, phần nào của hệ thống thực sự làm trang nhanh lên, hosting quản lý thêm gì và lặng lẽ lấy gì, cùng giá tháng thực tế từng bậc.

Bạn thực sự trả tiền cho cái gì khi mua hosting WordPress? Bốn thứ. Một phiên bản PHP và engine cơ sở dữ liệu đạt chuẩn WordPress công bố. Các lớp cache mà nếu không có bạn phải tự cài và tinh chỉnh. Công việc vận hành, tức cập nhật, staging, sao lưu và tường lửa. Và dung lượng dự phòng cho yêu cầu không cache được. Trang giới thiệu gần như không cần thứ tư. Cửa hàng hay site thành viên tiêu phần lớn ngân sách vào đó.

Hosting WordPress là tên một hạng mục, không phải một bản thông số

Khoảng cách giá bên trong cùng một hạng mục chính là bằng chứng. Hai gói cùng ghi hosting WordPress quản lý có thể nằm ở 20 bảng và 250 bảng mỗi tháng, và lời quảng cáo sẽ không giải thích khoảng cách đó, vì thứ tạo ra nó không hề được nhắc tới.

Ở đầu rẻ, bạn mua một lát của máy dùng chung, kèm một pool PHP-FPM, một lớp cache trang và một bảng điều khiển. Ở đầu đắt, bạn mua tài nguyên tính toán được cô lập, cache đối tượng bền, môi trường staging, tường lửa được quản lý, một đội hỗ trợ chịu đọc log lỗi của bạn, và một bên chịu trách nhiệm theo hợp đồng khi bản cập nhật lõi làm hỏng giao diện.

Cả hai đều là sản phẩm chính đáng. Vấn đề là người mua không thấy được thứ đang đứng trước mặt mình là loại nào, nên quyết định rơi vào tay giá và các trang đánh giá xếp hạng theo hoa hồng tiếp thị liên kết. Kết quả đoán được ở cả hai chiều. Trang giới thiệu nằm trên gói 150 bảng cả đời không dùng hết, còn cửa hàng WooCommerce nằm trên gói 5 bảng rồi gục ở bước thanh toán vào thứ Bảy đông khách đầu tiên.

Lối ra là mua theo bốn câu hỏi thay vì theo tên bậc: nhánh PHP nào, có những lớp cache nào, gói hấp thụ được bao nhiêu yêu cầu không cache được, và dữ liệu của bạn ra sao khi bạn rời đi.

WordPress thực sự đòi hỏi gì ở máy chủ

WordPress công bố một trang yêu cầu, nó ngắn, và chính vì thế nó bị bỏ qua. Hãy đọc nó như một bản thông số mua hàng, vì gói nào trượt ở đây là loại ngay trước khi bàn tới hiệu năng.

Phiên bản PHP

Trang yêu cầu của WordPress ghi chuẩn khuyến nghị là “PHP phiên bản 8.3 trở lên”. Cùng trang đó còn kèm một cảnh báo quan trọng hơn cả khuyến nghị: WordPress “vẫn chạy được trên PHP 7.4 trở lên và MySQL 5.5.5 trở lên, nhưng các phiên bản đó đã hết vòng đời chính thức và có thể khiến site của bạn phơi ra trước các lỗ hổng bảo mật”.

Toàn bộ cái bẫy nằm gọn trong câu ấy. WordPress không từ chối khởi động trên một nhánh PHP cổ lỗ. Nó chạy, trông bình thường, và lặng lẽ ngồi trên một trình thông dịch nhiều năm rồi không nhận bản vá bảo mật nào.

Cơ sở dữ liệu

Cũng trang ấy đòi “MariaDB 10.11 trở lên hoặc MySQL 8.0 trở lên”. Engine cũ hơn vẫn chạy, và đó là lý do có nhiều site đến thế còn nằm trên chúng. Thống kê sử dụng của chính WordPress cho thấy khoảng một trong sáu bản cài báo cáo một bản MySQL 5.x, thấp hơn hẳn mức sàn đã nêu, riêng MySQL 5.7 chiếm khoảng 12 phần trăm số site báo cáo.

Hệ quả không phải là site sẽ hỏng. Hệ quả là bạn mất các cải tiến ở tầng engine, vốn có ích đúng cho những tải khó cache, và bạn ôm sẵn một cuộc di chuyển kiểu gì rồi cũng phải làm.

HTTPS và các phần mở rộng

HTTPS được liệt kê là “bắt buộc với mọi bản cài”, không phải khuyến nghị. Nhà cung cấp nào tới năm 2026 còn coi chứng chỉ là món phụ phí thì đã nói hộ bạn về phần còn lại của gói.

Ngoài ra, Sổ tay Hosting WordPress nêu json và mysqli là bắt buộc, còn curl, dom, exif, fileinfo, hash, igbinary, imagick, intl, mbstring, openssl, xml và zip là rất nên có. Có hai cái đáng nêu tên với người bán. Không có zip, gói cập nhật plugin và lõi không giải nén được. Không có imagick, việc tải ảnh lên rơi xuống một thư viện ảnh yếu hơn và ảnh của bạn xấu đi trước khi ai đó kịp động tới plugin tối ưu.

Phiên bản PHP là dòng có đòn bẩy lớn nhất trên hóa đơn

Trong mọi thứ nhà cung cấp nắm giữ, nhánh PHP có tỷ lệ hiệu quả trên công sức tốt nhất. Trên hầu hết bảng điều khiển nó chỉ là một menu thả xuống. Không phải dựng lại gì, không phải chuyển gì, và một site vốn đã tương thích chỉ đơn giản bắt đầu chạy trên trình thông dịch nhanh hơn và được hỗ trợ tốt hơn.

Lý do nó nằm yên nhiều năm là tổ chức chứ không phải kỹ thuật. Không ai sở hữu nó. Đơn vị dựng site đã đi từ lâu, nhà cung cấp không đơn phương đổi vì lỗi nghiêm trọng từ một plugin bị bỏ rơi sẽ thành lỗi của họ, còn phía kinh doanh không có cớ gì để nghĩ tới một con số chưa ai từng cho họ xem.

Vậy câu hỏi đầu tiên dành cho nhà cung cấp không phải về tốc độ. Nó là: gói này mặc định chạy nhánh PHP nào, cung cấp những nhánh nào, và bạn có tự đổi được mà không cần mở phiếu hỗ trợ không. Nhà cung cấp chỉ đưa ra nhánh mà WordPress không còn khuyến nghị thì đã trả lời luôn mọi câu hỏi khác.

Hãy thử trên staging, đừng bao giờ lật thẳng trên bản chạy thật. Site chuyển từ PHP 7.4 lên 8.3 thường lòi ra hai ba cảnh báo lỗi thời từ các plugin không còn được bảo trì, và đó mới là chi phí thật. Hãy dự trù nửa ngày đến một ngày công lập trình, chi tiết hơn trong bài đơn giá lập trình viên WordPress và những gì cần hỏi.

Nửa còn lại của cuộc tranh luận PHP là bảo mật

Lý do người ta nêu ra khi nâng PHP là hiệu năng. Lý do thực sự quan trọng là bảo mật, và nó đo được chứ không phải để tranh cãi.

PHP tự công bố lịch các phiên bản được hỗ trợ. Mỗi nhánh có hai năm hỗ trợ tích cực rồi thêm hai năm chỉ vá bảo mật. Tính đến tháng 9 năm 2026, PHP 8.2 ở chế độ chỉ vá bảo mật tới 31/12/2026, còn PHP 8.3 chỉ vá bảo mật tới 31/12/2027 sau khi hỗ trợ tích cực kết thúc ngày 31/12/2025. PHP 8.4 còn hỗ trợ tích cực tới 31/12/2026 và vá bảo mật tới 31/12/2028; PHP 8.5 tới 31/12/2027 và vá bảo mật tới 31/12/2029. Cũ hơn thế là đã xong: PHP 8.1 kết thúc ngày 31/12/2025, PHP 8.0 ngày 26/11/2023 và PHP 7.4 ngày 28/11/2022.

Hãy đặt điều đó cạnh thứ các site WordPress đang thực sự chạy. Trang thống kê WordPress báo khoảng 38,8 phần trăm bản cài nằm trên một nhánh đã hết vòng đời hoàn toàn, khoảng 23,2 phần trăm vẫn ở PHP 7.4 hoặc cũ hơn. Chỉ khoảng 36,4 phần trăm đạt chuẩn PHP 8.3 mà WordPress khuyến nghị, và thêm 24,8 phần trăm nữa nằm trên PHP 8.2, vốn mất hỗ trợ bảo mật vào cuối năm nay.

Vậy đa số site WordPress chạy một trình thông dịch hoặc không còn nhận bản vá, hoặc chỉ còn vài tháng nữa là thế, và gần như lần nào cũng chỉ là một thiết lập hosting chưa ai ngó tới. Sửa nó rẻ hơn một giấy phép plugin, nên danh sách kiểm tra tăng cường bảo mật WordPress của chúng tôi xếp nó là bước một.

Các lớp cache, theo thứ tự một yêu cầu gặp chúng

Gần như mọi tuyên bố hiệu năng của nhà cung cấp đều là tuyên bố về cache, và gần như mọi người mua nghe chúng như một lời hứa duy nhất không phân biệt. Có bốn lớp riêng biệt, thứ tự cố định, mỗi lớp tiết kiệm một loại công việc khác nhau. Thứ tự dưới đây là thứ tự một yêu cầu đi qua, và yêu cầu đã được lớp trước trả lời thì không bao giờ tới các lớp sau.

Cache biên, tức CDN

Thứ đầu tiên một yêu cầu gặp là một lớp cache nằm hoàn toàn ngoài máy chủ của bạn, trên mạng các điểm hiện diện gần khách truy cập. Nếu phản hồi đã nằm sẵn ở đó, nhà cung cấp của bạn không hề thấy yêu cầu ấy.

Lớp này tiết kiệm cả khoảng cách mạng lẫn công tính toán. Khách ở Manchester chạm vào một nút biên tại London thì tránh được một vòng vượt Đại Tây Dương. Với tài nguyên tĩnh, nó gần như miễn phí và luôn đáng có. Với HTML, nó mạnh nhưng có điều kiện, vì phải nói cho lớp biên biết phản hồi nào là riêng tư và tuyệt đối không được chia sẻ.

Cache toàn trang

Lớp thứ hai lưu phần HTML đã dựng xong của một trang để PHP và cơ sở dữ liệu không phải chạy lại. Sổ tay Hosting WordPress khuyến nghị một reverse proxy như NGINX hoặc Varnish, thứ “lưu đầu ra trực tiếp vào bộ nhớ hoặc ổ cứng của máy chủ”, rồi thêm quy tắc quyết định lớp này có chạy được hay không: “nên loại toàn bộ người dùng đã đăng nhập khỏi cache vì họ phải thấy nội dung cá nhân hóa.”

Đây chính là lớp làm hosting rẻ trông đẹp. Khi nó chạy tốt, khách được trả về một tệp, còn phiên bản PHP, engine cơ sở dữ liệu và số lượng plugin thôi quan trọng với yêu cầu đó, vì không cái nào được thực thi.

Cache đối tượng

Lớp thứ ba cache kết quả của từng truy vấn cơ sở dữ liệu và các giá trị đã tính. WordPress có sẵn lớp này mặc định nhưng không bền. Tài liệu WP_Object_Cache nói rõ: “Mặc định, cache đối tượng là không bền. Nghĩa là dữ liệu lưu trong cache chỉ nằm trong bộ nhớ và chỉ tồn tại trong thời gian của yêu cầu đó.”

Làm cho nó bền nghĩa là đặt Redis hoặc Memcached phía sau qua một drop-in, biến một lớp cache phải dựng lại mỗi lần tải trang thành một lớp dùng chung giữa các yêu cầu và các khách. Đây là lớp trở nên quan trọng khi trang không còn cache nguyên khối được, và cũng là lớp hay thiếu nhất ở các gói rẻ.

Cache opcode

Lớp thứ tư là OPcache, nơi lưu mã bytecode đã biên dịch của các tệp PHP trong bộ nhớ chia sẻ để trình thông dịch không phải phân tích và biên dịch lại ở mỗi yêu cầu. Sổ tay nêu rằng “với môi trường WordPress chạy thật, nên bật OPcache cho các yêu cầu web và cấu hình kích thước phù hợp với site hoặc nền tảng hosting”.

Có một hệ quả khi triển khai. Vì OPcache giữ mã đã biên dịch, mỗi lần triển khai phải đặt lại nó hoặc vô hiệu các tệp đã đổi, nếu không máy chủ vẫn chạy bản trước. Nhà cung cấp không nói được OPcache bị vô hiệu ra sao là nhà cung cấp mà ở đó một bản cập nhật plugin trông như không làm gì suốt vài phút.

Vì sao trang giới thiệu chạy nhanh trên gần như mọi nhà cung cấp

Đi hết bốn lớp đó sẽ tới một kết luận khó chịu với ngành hosting. Nếu mọi khách đều ẩn danh và mọi trang đều cache được, cache toàn trang trả lời gần như toàn bộ lưu lượng, và thông số của cỗ máy phía sau gần như không lộ ra.

Vì thế một site công ty năm trang trên gói 4 bảng với một lớp cache trang tử tế có thể cho thời gian phản hồi máy chủ tốt hơn một site phình to trên gói 200 bảng. Bên rẻ đang phục vụ tệp. Bên đắt đang chạy PHP.

Con số cần theo dõi là thời gian tới byte đầu tiên, bản thân nó không phải một Core Web Vital. Tổng quan Web Vitals của Google xếp nó vào nhóm chỉ số hỗ trợ, hữu ích để “chẩn đoán các vấn đề của LCP” do phản hồi máy chủ chậm. Đó đúng là lát cắt tốc độ trang mà nhà cung cấp kiểm soát.

WordPress đồng ý đủ nhiều để viết điều đó vào lõi. Kiểm tra cache toàn trang trong Site Health thêm ở WordPress 6.1 xem “site có dùng giải pháp cache toàn trang hay không và thời gian phản hồi có chấp nhận được không”, với ngưỡng mặc định 600 mili giây. Nếu site của bạn vượt ngưỡng đó dù được cho là đã bật cache trang, thì cache không chạy, và thêm CPU cũng không che được.

Nên với một trang giới thiệu, nâng cấp hosting thường là món mua sai. Thứ làm nó chậm hay là một ảnh bìa quá khổ, một trình dựng trang gửi kèm hàng trăm kilobyte CSS, hoặc sáu độ đậm phông chữ, đúng như lập luận trong bài so sánh Elementor và giao diện tùy chỉnh.

Lưu lượng đã đăng nhập và WooCommerce phá vỡ mô hình

Mọi điều ở trên giả định cache trang trả lời được. Khoảnh khắc khách đăng nhập, giả định đó sụp, và kinh tế học của hosting đảo ngược.

WooCommerce ghi rõ điều này. Hướng dẫn về cache của họ yêu cầu loại Giỏ hàng, Tài khoản của tôi và Thanh toán khỏi cache trang vì các trang đó “cần giữ động vì chúng hiển thị thông tin riêng của khách hàng hiện tại và giỏ hàng của họ”. Tài liệu cũng liệt kê các cookie phải đi vòng qua cache, gồm woocommerce_cart_hash, woocommerce_items_in_cart và wp_woocommerce_session_, và khuyên loại _wc_session_ khỏi cache cơ sở dữ liệu.

Đọc như một bản thông số hosting, nó nói một điều thẳng thừng. Ở cửa hàng, những trang sinh ra doanh thu đúng là những trang cache trang không chạm tới được. Trang danh mục và trang sản phẩm có thể cache cho khách ẩn danh. Giỏ hàng và thanh toán thì không, không bao giờ, với bất kỳ ai.

Điều tương tự đúng với site thành viên, nền tảng học tập, diễn đàn và mọi site có cổng khách hàng. Khi cookie phiên đã được đặt, phần lớn plugin cache ngừng hẳn việc trả HTML đã cache cho khách đó, nên mỗi cú nhấp đều chạy PHP và đụng cơ sở dữ liệu. Đây là lúc cache đối tượng thôi là tối ưu hóa và trở thành kết cấu chịu lực, và là lúc gói rẻ gây đau theo cách không phép đo trang chủ nhân tạo nào thấy được, như đã nói trong bài vì sao cửa hàng WooCommerce của bạn chậm.

Hosting WordPress quản lý thực sự gồm những gì

Bóc hết tính từ, hosting quản lý quy về một bó công việc vận hành khá nhất quán. Đáng để định giá bó công việc đó cho trung thực, vì với doanh nghiệp không có nhân sự kỹ thuật, mua thường rẻ hơn tự làm.

Cập nhật

Gói quản lý thường tự áp bản cập nhật lõi, đôi khi cả bản cập nhật plugin, thỉnh thoảng kèm một lượt kiểm tra hồi quy hình ảnh trước và sau. Điều hữu ích cần biết là WordPress đã làm miễn phí đến đâu.

WordPress đã tự cập nhật các bản lõi nhỏ và tệp dịch theo mặc định từ nhiều năm nay, và từ bản 5.6 thì bản cài mới bật sẵn tự động cập nhật cho cả bản lõi nhỏ lẫn bản lớn trừ khi phát hiện một checkout quản lý phiên bản, còn bản cài cũ giữ nguyên hành vi trước đó. Vậy phần trả tiền không phải là bản cập nhật lõi nhỏ. Đó là cập nhật plugin, việc quay lui khi một cái hỏng, và một người nhận ra rằng nó đã hỏng.

Staging và sao lưu

Môi trường staging một cú nhấp thực sự có giá trị và thực sự phiền khi tự dựng. Hãy đánh giá nó theo hai chi tiết chứ không theo việc có hay không: đẩy staging ngược lên bản chạy thật có ghi đè cơ sở dữ liệu đang sống không, vì như thế sẽ mất đơn hàng và bình luận phát sinh sau bản sao; và site staging có bị chặn khỏi công cụ tìm kiếm và chặn gửi thư không.

Tường lửa và quét mã độc

Phần lớn gói quản lý gồm một tường lửa ứng dụng web ở lớp biên và một dạng quét mã độc. Tường lửa là giá trị thật, vì vá ảo ở tầng mạng mua cho bạn thời gian giữa lúc một lỗ hổng plugin được công bố và lúc bạn cập nhật xong.

Quét thì yếu hơn vẻ ngoài của nó. Nó thường phát hiện chữ ký của các tệp độc hại đã biết, nghĩa là bắt được lây nhiễm đại trà và bỏ sót các vụ nhắm đích. Hãy coi nó là chuông báo khói chứ không phải ổ khóa, và giữ phần việc tăng cường ở phía bạn.

Hosting quản lý lấy đi những gì

Các hạn chế là nửa không ai đọc, và thường có hệ quả lớn hơn phần tính năng. Chúng tồn tại vì những lý do đứng vững được, nhưng là lý do của nhà cung cấp chứ không phải của bạn.

Ví dụ công khai rõ nhất là danh sách plugin bị cấm của WP Engine, vốn cấm cả nhóm chứ không cấm từng cái tên xấu. Plugin cache bị cấm vì chúng “có thể xung đột với cấu trúc cache tích hợp sẵn của nền tảng”. Plugin sao lưu bị cấm với lý do chúng “làm site phình lên một cách không cần thiết”. Plugin bài viết liên quan bị cấm vì “cực kỳ nặng cho cơ sở dữ liệu”. Plugin có lỗ hổng đã ghi nhận bị cấm thẳng, plugin trùng chức năng nền tảng cũng vậy.

Từng điều một đều là quyết định kỹ thuật hợp lý. Gộp lại, chúng có nghĩa là site của bạn không dễ mang đi như bạn tưởng. Nếu bản dựng phụ thuộc vào cấu hình của một plugin cache cụ thể, cấu hình đó không đi cùng bạn.

Truy cập shell là thiếu sót phổ biến còn lại. Khá nhiều gói quản lý không cho SSH, hoặc chỉ cho một shell hạn chế không có WP-CLI, khiến việc thường ngày như tìm và thay hàng loạt sau khi đổi tên miền biến thành một phiếu hỗ trợ. Hai điểm nữa hay làm người ta vấp: tiến trình chạy dài thường bị giới hạn, nên nhập 50.000 sản phẩm phải chia nhỏ; và thư gửi đi hay bị chặn hoặc bóp băng thông với giả định rằng site bị chiếm sẽ bị dùng để phát tán thư rác.

Những tuyên bố hiệu năng không sống sót qua kiểm chứng

Tiếp thị hosting chạy trên một nhóm nhỏ tuyên bố, và chúng rã ra ngay khi bạn hỏi cái gì đã được đo.

“Nhanh gấp 20 lần” gần như không bao giờ nêu mốc so sánh. Nhanh hơn cái gì, ở trang nào, với những plugin nào, dưới mức đồng thời bao nhiêu? Thiếu bốn thứ đó, con số chỉ là tỷ lệ giữa hai đại lượng không tên.

“Băng thông không giới hạn” nằm ngay cạnh hạn mức lượt truy cập hằng tháng trong cùng một bảng. Dù sao băng thông hiếm khi là nút thắt của một site WordPress. Nút thắt là số tiến trình PHP chạy đồng thời, thứ mà gói thường không hề nhắc.

“Uptime chín mươi chín phẩy chín phần trăm” nghe như tuyệt đối, nhưng không phải. Trong một tháng ba mươi ngày, nó cho phép khoảng 43 phút ngừng chạy. Ba số chín là mức bình thường của hosting dùng chung, bốn số chín cho phép khoảng bốn phút mỗi tháng, và khác biệt ấy là khác biệt giữa một bất tiện và một sự cố không ai nhận ra. Hãy đọc xem khoản đền bù thực sự trả gì khi họ không đạt, chủ đề chúng tôi xử lý riêng trong bài SLA uptime có ý nghĩa.

Tuyên bố cuối là phổ biến nhất và gây hiểu lầm nhất: ảnh chụp một phép đo tốc độ trên trang chủ đã cache. Nó đo cache trang chứ không đo nhà cung cấp, và cache trang lại đúng là thành phần gần như tương đương ở mọi nơi.

Cách kiểm chứng một nhà cung cấp cho đúng

Kiểm chứng hosting không khó, nhưng phải làm trên đường đi thực sự bắt máy chủ làm việc. Năm bước, theo thứ tự.

Thứ nhất, thử một đường không cache. Gắn thêm một chuỗi truy vấn duy nhất để xuyên qua cache trang, hoặc yêu cầu một trang không bao giờ được cache như giỏ hàng hay trang tài khoản. Nếu bạn không tạo nổi một yêu cầu chạy PHP thì bạn đang đo một máy chủ tệp tin.

Thứ hai, lặp lại. Một yêu cầu đơn lẻ không nói gì về độ biến thiên, mà độ biến thiên mới là chỗ hosting rẻ lộ mặt. Hãy lấy ít nhất 20 mẫu và đọc phân vị thứ 75, con số thống kê Google dùng cho dữ liệu thực địa.

Thứ ba, thử từ nơi khách của bạn ở. Phản hồi đo từ một trung tâm dữ liệu ngay cạnh máy chủ không phải phản hồi mà khách của bạn ở Leeds nhận được.

Thứ tư, thử dưới mức đồng thời. Chạy 10 hoặc 20 yêu cầu không cache được cùng lúc. Đây là phép thử duy nhất phơi ra tình trạng cạn worker PHP, và cạn worker chính là thứ quật ngã một cửa hàng giữa đợt khuyến mãi.

Thứ năm, so sánh cùng điều kiện: cùng nhánh PHP, cùng bộ plugin, cùng giao diện, cùng khối lượng nội dung. Một cuộc chuyển đổi thay cả bộ plugin cùng lúc với đổi nhà cung cấp thì chẳng chứng minh được gì về bên nào cả. Nếu bạn muốn chạy quy trình này trên một site thật thay vì trên nhà cung cấp ứng viên, đó chính là việc mà một cuộc kiểm tra hiệu suất WordPress làm.

Hosting thực sự tác động tới Core Web Vitals nào

Core Web Vitals là chỗ tuyên bố hosting và thứ hạng tìm kiếm dễ bị trộn lẫn, nên đáng nói chính xác chỉ số nào máy chủ ảnh hưởng được.

Có ba chỉ số, đánh giá ở phân vị thứ 75 của lượt tải trang, tách riêng di động và máy tính. Largest Contentful Paint đo tải, tốt ở mức 2,5 giây trở xuống, cần cải thiện trong khoảng 2,5 đến 4,0 giây, kém khi vượt 4,0. Interaction to Next Paint đo mức đáp ứng, tốt ở 200 mili giây trở xuống, cần cải thiện tới 500 mili giây, kém khi cao hơn. Cumulative Layout Shift đo độ ổn định thị giác, tốt ở 0,1 trở xuống, cần cải thiện tới 0,25, kém khi cao hơn. First Input Delay đã bị bỏ và thay bằng INP, chỉ số trở thành Core Web Vital chính thức năm 2024.

Hosting tác động trực tiếp đúng một chỉ số. Thời gian phản hồi máy chủ là một phần của LCP, nên nhà cung cấp cắt 400 mili giây ở đó là cắt 400 mili giây khỏi LCP của mọi khách. Trên nhà cung cấp chậm, đó có thể là khác biệt giữa đạt và trượt.

Nó gần như không làm gì cho CLS, thứ sinh ra từ ảnh thiếu kích thước và phông chữ tải muộn, và làm rất ít cho INP, thứ bị JavaScript trên luồng chính chi phối. Quy tắc là: nếu LCP kém và phản hồi máy chủ chưa cache nằm trên mốc 600 mili giây WordPress nêu, hosting là một phần của vấn đề. Nếu phản hồi thoải mái mà LCP vẫn kém, lỗi nằm trong trang, và hướng dẫn vượt Core Web Vitals năm 2026 của chúng tôi mới là nơi nên tiêu ngân sách.

Sao lưu, và phần không ai kiểm tra

Mọi gói trên mức rẻ nhất đều quảng cáo sao lưu. Gần như không ai mua chúng hỏi những câu quyết định bản sao lưu ấy có đáng gì hay không.

Đã từng có ai khôi phục thử chưa

NCSC nói thẳng trong hướng dẫn cho tổ chức nhỏ: khi đã tạo bản sao lưu, “điều quan trọng là bạn biết cách khôi phục nó và kiểm tra rằng nó chứa toàn bộ dữ liệu quan trọng của bạn”. Một bản sao lưu chưa thử là một niềm tin, không phải một biện pháp kiểm soát.

Hãy hỏi nhà cung cấp việc khôi phục bắt đầu ra sao, mất bao lâu với site cỡ của bạn, và khôi phục cơ sở dữ liệu có khôi phục cả thư mục uploads không. Rồi làm thử một lần trên staging trước khi bạn cần tới. Dạng hỏng cần để ý là bản khôi phục trả về tệp mà không trả cơ sở dữ liệu, hoặc bản khôi phục thành công nhưng lặng lẽ mất mọi thứ tạo ra sau bản sao.

Thời gian lưu và tần suất

Sao lưu hằng ngày giữ bảy ngày nghe rộng rãi cho tới khi bạn nghĩ xem một site WordPress thực sự hỏng ra sao. Site bị bôi xấu bị phát hiện trong vài giờ. Vụ xâm nhập lặng lẽ chèn liên kết rác vào các bài cũ thì mất vài tuần mới lộ, và tới lúc đó mọi bản sao còn giữ đều đã chứa phần chèn ấy.

Với bất cứ thứ gì mang tính thương mại, ba mươi ngày là mức sàn hữu ích hơn, và một bản sao hằng tháng riêng là khoản bảo hiểm rẻ. Cửa hàng còn cần nhịp sao lưu cơ sở dữ liệu tính theo lượng đơn, vì mất bốn giờ đơn hàng không cùng loại vấn đề với mất bốn giờ chỉnh sửa bài viết.

Bản sao nằm ở đâu và ở định dạng nào

Ý còn lại của NCSC là bản sao lưu vẫn gắn với hệ thống đang sống thì không tách biệt: thiết bị chứa bản sao lưu “không nên vẫn kết nối với máy của bạn khi không dùng”, vì thứ gì xâm phạm được nguồn cũng với tới được nó. Áp vào hosting, một bản sao lưu nằm trong cùng tài khoản và chỉ khôi phục được qua đúng bảng điều khiển ấy thì chung số phận với thứ nó bảo vệ.

Định dạng là phiên bản tinh vi hơn của cùng vấn đề. Nếu cách duy nhất để đọc bản sao lưu là nút khôi phục của chính nhà cung cấp, bạn có một tiện ích chứ không có một bản sao mang đi được. Phép thử là hôm nay bạn có tải về được một bản kết xuất SQL thuần và một kho tệp mà một lập trình viên đủ năng lực dựng lại được ở nơi khác hay không. Nếu không, chuyển đổi thôi là một quyết định kỹ thuật và thành một cuộc thương lượng.

Dữ liệu nằm ở đâu, và vì sao điều đó quan trọng với người mua ở Anh

Quyết định hosting là quyết định bảo vệ dữ liệu; với doanh nghiệp Anh, câu hỏi không phải công ty đăng ký ở đâu mà là dữ liệu cá nhân nằm đâu, ai với tới được.

Hướng dẫn chuyển giao quốc tế của ICO nêu phép thử ba bước. Nếu UK GDPR áp dụng cho việc xử lý của bạn, chính bạn khởi tạo chuyển giao, và bên nhận là pháp nhân riêng, đó là chuyển giao hạn chế. ICO nói rõ quy tắc “áp dụng cho mọi chuyển giao hạn chế, kể cả những lần nhỏ và không thường xuyên”, bao trùm mọi tổ chức xử lý dữ liệu cá nhân, “gồm cả hộ kinh doanh cá thể và người tự làm chủ”.

Hãy để ý cái gì tính là chuyển giao. ICO tính cả việc gửi dữ liệu cá nhân lẫn “làm cho dữ liệu đó có thể truy cập được” với tổ chức ngoài Anh. Một đội hỗ trợ nước ngoài vào được trang quản trị, hay bản sao lưu nhân bản sang vùng khác, đều khớp định nghĩa ấy.

Mỗi chuyển giao hạn chế phải được phủ bởi một trong ba thứ: quy định đầy đủ của Anh cho nơi nhận, biện pháp bảo đảm như Thỏa thuận Chuyển giao Dữ liệu Quốc tế, Phụ lục hay quy tắc doanh nghiệp ràng buộc, hoặc ngoại lệ. Khi dựa vào biện pháp bảo đảm, ICO còn đòi đánh giá rủi ro chuyển giao chứng tỏ mức bảo vệ không giảm đáng kể. Không điều nào khiến nhà cung cấp nước ngoài hết dùng được. Chúng chỉ biến đây thành quyết định cần ghi lại, và ghi trước khi chuyển rẻ hơn nhiều so với lúc đang chuyển hay giữa một yêu cầu truy cập dữ liệu.

Một thỏa thuận với bên xử lý nên viết gì

Nhà cung cấp là bên xử lý còn bạn là bên kiểm soát, nên hợp đồng văn bản không phải tùy chọn. ICO liệt kê những gì hợp đồng phải có, và bốn điều khoản đọc thẳng ra thành câu hỏi cho nhà cung cấp.

Bên xử lý phụ đứng đầu. Theo Điều 28(3)(d), bên xử lý không được thuê bên xử lý khác khi chưa được bạn cho phép, phải báo các thay đổi dự kiến để bạn phản đối, và phải áp nghĩa vụ tương đương xuống cả chuỗi. Về mặt hosting, đó là CDN, nơi chứa bản sao lưu, dịch vụ chuyển tiếp thư và nhà cung cấp đám mây nền tảng. Hãy đòi danh sách.

Bảo mật đứng thứ hai. Điều 28(3)(c) đòi biện pháp đáp ứng Điều 32, và ICO nêu rõ chúng gồm gì: mã hóa và giả danh hóa, khả năng phục hồi của hệ thống xử lý, “khả năng khôi phục quyền truy cập vào dữ liệu cá nhân khi có sự cố”, và “các quy trình định kỳ kiểm tra và đánh giá hiệu quả của các biện pháp”. Đó là diễn tập khôi phục được viết vào luật chứ không phải vào một bài về thực hành tốt.

Thứ ba là lối ra. Theo Điều 28(3)(g), khi hợp đồng kết thúc, bên xử lý phải xóa hoặc trả lại toàn bộ dữ liệu cá nhân theo lựa chọn của bạn và xóa các bản sao hiện có. Nhà cung cấp có bản sao lưu không rời được nền tảng của họ thì vướng cả vấn đề hợp đồng lẫn thực tế. Thứ tư là kiểm toán: theo Điều 28(3)(h), bạn có quyền nhận thông tin cần để chứng minh tuân thủ cùng chứng nhận và báo cáo của họ.

Các bậc, và chi phí của chúng ở Anh

Bốn bậc phủ gần như mọi site WordPress, và ranh giới giữa chúng do tải không cache được định đoạt chứ không phải do lưu lượng. Các dải dưới đây là mức người mua ở Anh thường trả mỗi tháng. Chúng là dải theo hạng mục chứ không phải bảng giá của một nhà cung cấp nào, nên hãy dùng chúng để kiểm tra tính hợp lý của một báo giá.

Hosting dùng chung, 3 đến 15 bảng mỗi tháng

Hoàn toàn đủ cho một trang giới thiệu cache được, và thực sự đắt đỏ nếu có ai đăng nhập. Bạn chia sẻ dung lượng PHP với những hàng xóm không nhìn thấy, nên thứ cắn bạn là độ biến thiên dưới tải chứ không phải mức trung bình. Hãy kiểm tra nhánh PHP trước, vì bậc này là nơi các trình thông dịch hết vòng đời tụ lại.

WordPress quản lý, 20 đến 400 bảng mỗi tháng

Lựa chọn mặc định đúng cho site nội dung và cửa hàng nhỏ. Bạn mua cập nhật, staging, tường lửa, cache đối tượng bền và một đội hỗ trợ, và trả giá bằng những hạn chế ở trên. Dải 20 đến 100 bảng phủ một site đơn có lưu lượng vừa phải. Trên mức đó, thường bạn đang trả cho nhiều site hơn, nhiều lượt truy cập hơn, hoặc nhiều worker PHP hơn.

VPS hoặc đám mây tự dựng, 15 đến 120 bảng cộng phí quản lý

Một máy đám mây khiêm tốn tốn 15 đến 120 bảng mỗi tháng, nhưng máy mới là phần rẻ. Phải có người vá hệ điều hành, tinh chỉnh reverse proxy, chạy cache đối tượng và lo sao lưu, và mua việc đó vào tốn thêm 150 đến 600 bảng mỗi tháng. Đáng khi tải không cache được là có thật, hoặc khi hệ thống của bạn có yêu cầu mà nền tảng quản lý cấm.

Hạ tầng riêng, từ 400 bảng mỗi tháng

Triển khai đa vùng, sự kiện có mức đồng thời cao, yêu cầu nghiêm ngặt về nơi lưu trú dữ liệu, hoặc một kiến trúc mà WordPress chỉ là một thành phần trong nhiều thành phần. Hosting thôi là một lựa chọn sản phẩm và trở thành một phần của bản dựng, đúng cách chúng tôi tiếp cận nó trong một dự án phát triển website.

Ước lượng theo yêu cầu không cache được, không theo lượt xem trang

Gói hosting được bán theo lượt truy cập hằng tháng vì đó là con số người mua nhận ra. Nó gần như vô dụng cho việc hoạch định dung lượng, vì 100.000 lượt xem trang ẩn danh đã cache gần như không tốn gì, còn 10.000 lượt đã đăng nhập có thể làm bão hòa một máy chủ nhỏ.

Con số đáng kể là số yêu cầu không cache được đồng thời, và phép tính rất đơn giản. Một worker PHP xử lý một yêu cầu không cache được tại một thời điểm. Số worker cần có xấp xỉ bằng số yêu cầu không cache được mỗi giây lúc cao điểm nhân với thời gian phản hồi PHP trung bình tính theo giây. Hai mươi yêu cầu không cache được mỗi giây, mỗi cái 400 mili giây, cần khoảng tám worker để theo kịp, và bạn muốn thêm ít nhất một nửa nữa làm dự phòng.

Vậy hãy hỏi hai câu mà không trang gói nào trả lời: gói này chạy bao nhiêu worker PHP, và giới hạn bộ nhớ mỗi tiến trình là bao nhiêu? Cả hai con số đều tồn tại và thường không được công bố. Hỏi thẳng thì bộ phận hỗ trợ thường sẽ nói, và câu trả lời đó nói về gói nhiều hơn mọi phép đo chuẩn trên trang.

Rồi hãy ước lượng phía mình cho trung thực. Đếm tỷ lệ phiên đã đăng nhập, lưu lượng thanh toán và tài khoản ở giờ bận nhất chứ không phải giờ trung bình, và lưu lượng admin-ajax hay REST mà các plugin sinh ra ở nền, thứ vô hình trong công cụ phân tích và rất rõ trong log máy chủ.

Số lượng plugin và khối lượng xuất bản là quyết định hosting

Hai thứ bên trong site quyết định nó cần bao nhiêu hosting, và cả hai thường bị coi là quyết định nội dung do những người không bao giờ thấy hóa đơn đưa ra.

Thứ nhất là bộ plugin. Mỗi plugin đang bật đều thêm các tùy chọn tự nạp ở mọi yêu cầu, các sự kiện hẹn giờ kích hoạt trên yêu cầu của khách vì cron của WordPress không phải cron thật, và số truy vấn cho mỗi lần dựng trang. Ba mươi plugin trên một trang giới thiệu đã cache thì sống được. Ba mươi plugin trên một cửa hàng không cache được gì nghĩa là ba mươi plugin chạy ở từng bước thanh toán. Lõi WordPress có một quan điểm sơ bộ về lúc điều này bắt đầu cắn: kiểm tra Site Health về cache đối tượng bền gợi ý nên dùng cache đối tượng khi site vượt các ngưỡng như 2.000 bài viết, 2.000 người dùng hoặc 600 tùy chọn tự nạp.

Thứ hai là khối lượng xuất bản. Các bản sửa đổi chồng lên nhau không giới hạn theo mặc định, thư viện phương tiện phình thành hàng chục nghìn tệp với vài kích thước sinh ra cho mỗi tệp, và cả hai đều làm phình cơ sở dữ liệu và cửa sổ sao lưu. Một site xuất bản hằng ngày suốt năm năm là một bài toán hosting khác hẳn cùng thiết kế đó xuất bản hằng tháng, và trang gói không phản ánh điều đó. Rà soát bản dựng chứ không phải rà soát gói mới là việc một lập trình viên WordPress nên làm trước khi báo giá một cuộc chuyển đổi.

Chọn, theo thứ tự

Đi theo trình tự này thì quyết định thường tự lộ ra. Xác định bao nhiêu phần lưu lượng của bạn không cache được, vì riêng con số đó chọn bậc cho bạn. Xác nhận nhánh PHP và phiên bản cơ sở dữ liệu đạt chuẩn đã công bố, vì gói trượt ở đó là loại bất kể giá. Xác định những lớp cache nào đã gồm sẵn và lớp nào bạn phải tự lo. Hỏi bản sao lưu nằm ở đâu, ở định dạng nào, và hôm nay bạn tải một bản về được không. Rồi đọc điều khoản bên xử lý về bên xử lý phụ, vị trí dữ liệu và việc xóa khi hết hợp đồng. Chỉ sau tất cả những điều đó thì giá mới có nghĩa, vì tới lúc ấy bạn mới đang so sánh cùng một sản phẩm.

Mecanik làm việc này như một hạng mục trọn gói trước mọi cuộc chuyển đổi, thường song song với một dự án phát triển website, và nhận hỗ trợ lâu dài qua dịch vụ thuê lập trình viên WordPress. Nếu bạn đang cân nhắc chính nền tảng này đi về đâu, bài viết của chúng tôi về WordPress 7.0 và client AI trong lõi là bài đọc kèm hợp lý.

Câu hỏi thường gặp

Hosting WordPress ở Anh nên tốn bao nhiêu? Điều đó phụ thuộc gần như hoàn toàn vào việc bao nhiêu phần lưu lượng của bạn cache được. Một trang giới thiệu với khách ẩn danh được phục vụ tốt ở mức 3 đến 15 bảng mỗi tháng trên hosting dùng chung. Site nội dung hoặc cửa hàng nhỏ thường thuộc về hosting WordPress quản lý ở mức 20 đến 100 bảng mỗi tháng, tăng lên 100 đến 400 bảng cho gói đông khách hoặc nhiều site. Cửa hàng hay site thành viên có nhiều lưu lượng đã đăng nhập thường cần VPS hoặc đám mây với 15 đến 120 bảng cho máy, cộng 150 đến 600 bảng mỗi tháng nếu có người khác quản lý.

Hosting WordPress quản lý có đáng khoản tiền tăng thêm không? Có, nếu bạn không có người vận hành, vì bạn đang mua cập nhật, staging, sao lưu, tường lửa và một lớp cache đối tượng bền mà nếu không bạn phải tự cấu hình. Cái giá là những hạn chế có thật. Nhà cung cấp thường xuyên cấm plugin cache, plugin sao lưu và plugin nặng cơ sở dữ liệu, hay không cho truy cập shell, giới hạn tiến trình chạy dài và chặn thư gửi đi. Hãy đối chiếu các giới hạn đó với bản dựng của bạn trước khi ký, không phải sau.

WordPress cần phiên bản PHP nào trong năm 2026? WordPress khuyến nghị PHP 8.3 trở lên. Nó vẫn chạy trên PHP 7.4 trở lên, nhưng các nhánh đó đã hết vòng đời và không nhận bản vá bảo mật. PHP 8.1 kết thúc ngày 31/12/2025, PHP 8.0 ngày 26/11/2023 và PHP 7.4 ngày 28/11/2022, còn PHP 8.2 ở chế độ chỉ vá bảo mật tới 31/12/2026. Khoảng 38,8 phần trăm bản cài WordPress vẫn báo cáo một nhánh đã hết vòng đời hoàn toàn.

Hosting tốt hơn có cải thiện Core Web Vitals không? Chỉ một trong ba chỉ số, và chỉ một cách gián tiếp. Thời gian phản hồi máy chủ là một phần của Largest Contentful Paint, nên nhà cung cấp nhanh hơn sẽ hạ LCP cho mọi khách. Nó gần như không làm gì cho Cumulative Layout Shift, thứ sinh ra từ ảnh thiếu kích thước và phông chữ tải muộn, và làm rất ít cho Interaction to Next Paint, thứ bị JavaScript trên luồng chính chi phối. Nếu phản hồi máy chủ đã thoải mái, vấn đề còn lại nằm trong trang.

Vì sao cửa hàng WooCommerce của tôi chậm trên một gói ghi là nhanh? Vì những trang quan trọng không cache được. WooCommerce yêu cầu Giỏ hàng, Tài khoản của tôi và Thanh toán giữ động, và đặt cookie phiên đi vòng qua cache trang với người mua đã đăng nhập. Phép đo tốc độ trên trang chủ đang đo một tệp đã cache, trong khi thanh toán chạy PHP và đụng cơ sở dữ liệu ở mọi yêu cầu. Thứ một cửa hàng thực sự mua là dung lượng cho các yêu cầu không cache được, không phải con số trang chủ đã cache.