# Tăng tốc WordPress: 10 bước theo đúng thứ tự hiệu quả

> Cách tăng tốc WordPress theo thứ tự tác động - đo đúng chỉ số, page cache, PHP 8.3, Redis, database, ảnh, plugin, cron - kèm lệnh kiểm tra và cách làm trên ZoPanel.

Source: https://zopanel.net/vi/blog/speed-up-wordpress  
Updated: 2026-10-21

## Ý chính

- Page cache là bước tăng tốc WordPress lớn nhất vì trang đã cache không cần chạy PHP và database.
- WordPress.org khuyến nghị PHP 8.3 trở lên và MariaDB 10.11 hoặc MySQL 8.0 trở lên.
- Redis object cache giúp những trang không cache được như wp-admin, giỏ hàng và người dùng đã đăng nhập.
- Đo trước khi sửa - Core Web Vitals tốt khi LCP dưới 2,5 giây, INP dưới 200 ms và CLS dưới 0,1.

Muốn tăng tốc WordPress hiệu quả, hãy làm theo thứ tự tác động: **bật page cache** để trang được phục vụ thẳng từ web server, **nâng PHP lên 8.3 trở lên** với OPcache, **thêm Redis object cache** cho những trang không cache được, **dọn plugin và database**, rồi mới tới **ảnh và front-end**. Phần lớn website chậm vì mỗi lượt xem đều bắt PHP dựng trang từ đầu; chỉ riêng page cache thường đã thay đổi mọi thứ.

Bài viết đi qua 10 bước theo đúng thứ tự đó, mỗi bước kèm cách đo, cách làm thủ công và lỗi hay gặp. Cuối bài là cách làm các bước phía server trên ZoPanel, nơi phần lớn chỉ là bật một công tắc.

## Đo trước khi tăng tốc WordPress

Sửa mà không đo thì không biết mình cải thiện được gì. Có hai nhóm chỉ số cần theo dõi.

**Phía server: TTFB (time to first byte).** Thời gian từ lúc gửi request tới khi nhận byte đầu tiên. Đây là phần PHP, database và cache quyết định. Đo bằng `curl` từ một máy khác:

```bash
curl -o /dev/null -s -w 'TTFB: %{time_starttransfer}s  Tổng: %{time_total}s\n' https://example.com/
```

Chạy vài lần liên tiếp. Trang WordPress không cache trên server ổn thường mất vài trăm mili giây; trang đã cache thường chỉ còn vài chục mili giây cộng độ trễ mạng.

**Phía người dùng: Core Web Vitals.** Theo [web.dev](https://web.dev/articles/vitals), một trang đạt "tốt" khi **LCP ≤ 2,5 giây**, **INP ≤ 200 ms** và **CLS ≤ 0,1**, đo ở phân vị 75 của lượt tải trang, tách riêng mobile và desktop. Dùng PageSpeed Insights để xem cả dữ liệu thực tế từ người dùng Chrome (nếu website đủ lượt truy cập) lẫn dữ liệu phòng thí nghiệm.

Ghi lại các con số cho trang chủ, một bài viết và (nếu có) trang sản phẩm. Sau mỗi bước, đo lại.

## 1. Bật page cache: bước lớn nhất

Không có page cache, mỗi lượt xem đều chạy PHP: nạp WordPress, nạp plugin, truy vấn database, dựng HTML. Có page cache, web server giữ bản HTML đã dựng và trả ngay cho người truy cập tiếp theo, PHP không chạy.

Chênh lệch lớn tới mức nào? Trong [bài đo thực tế của chúng tôi](/vi/blog/how-many-wordpress-sites-4gb-vps), cùng một VPS Ubuntu 4 GB chạy được khoảng 100 website WordPress khi không có page cache và 250 khi có. Với từng website, page cache thường là thứ quyết định TTFB.

Có hai cách:

- **Cache ở web server** (nginx FastCGI cache, hoặc tính năng cache của panel): nhanh nhất, vì request không chạm tới PHP.
- **Plugin cache** (ghi HTML ra file, rồi rewrite rule phục vụ file đó): dễ cài trên shared hosting, hiệu quả tốt nếu cấu hình đúng.

Dù chọn cách nào, cache phải **bỏ qua** người dùng đã đăng nhập, giỏ hàng, thanh toán, trang tài khoản và request POST, và phải **tự xoá** khi nội dung thay đổi. Đừng chồng hai lớp page cache (plugin cộng server): khi xoá cache sẽ rất khó biết lớp nào còn giữ bản cũ.

## 2. Nâng cấp PHP và bật OPcache

[Trang yêu cầu của WordPress.org](https://wordpress.org/about/requirements/) khuyến nghị **PHP 8.3 trở lên** và **MariaDB 10.11 hoặc MySQL 8.0 trở lên**. Mỗi phiên bản PHP 8.x mới thường nhanh hơn và được vá bảo mật lâu hơn. Trước khi đổi, kiểm tra plugin và theme trên bản staging.

OPcache giữ mã PHP đã biên dịch trong bộ nhớ, để PHP không phải dịch lại mọi file ở mỗi request. Kiểm tra:

```bash
php -i | grep -i "opcache.enable"
```

Với PHP-FPM, OPcache cấu hình theo từng phiên bản PHP; hãy kiểm tra đúng phiên bản website đang dùng.

## 3. Redis object cache cho trang không cache được

Page cache không giúp được wp-admin, giỏ hàng WooCommerce hay website thành viên, vì những trang đó phải dựng riêng cho từng người. Ở đây, **object cache** lưu kết quả truy vấn database vào Redis, để lần sau WordPress lấy từ RAM thay vì hỏi lại database.

Cần hai thứ: Redis chạy trên server, và một plugin như Redis Object Cache để WordPress dùng nó. Trên server có nhiều website, mỗi website nên có Redis database hoặc tiền tố khoá riêng, để không website nào đọc hay xoá dữ liệu của website khác.

## 4. Kiểm tra plugin nặng

Một plugin kém có thể thêm hàng trăm truy vấn mỗi trang. Cài plugin Query Monitor trên bản staging, mở trang chậm, xem truy vấn nào và plugin nào tốn thời gian nhất. Với mỗi plugin, tự hỏi: còn cần không? Có thay bằng vài dòng code hoặc tính năng của server không?

Lỗi hay gặp: plugin "tăng tốc tất cả trong một" bật mọi tuỳ chọn, gộp và thu nhỏ JavaScript làm hỏng giao diện, rồi người dùng tắt hết và kết luận "tối ưu không có tác dụng".

## 5. Dọn database, nhất là autoload

Mỗi request WordPress nạp mọi option có cờ autoload. Plugin đã gỡ thường để lại option rất lớn. Kiểm tra tổng dung lượng:

```bash
wp option list --autoload=on --format=total_bytes
```

Lệnh này có trong [tài liệu WP-CLI](https://developer.wordpress.org/cli/commands/option/list/). Nếu kết quả lên tới vài MB, liệt kê option lớn nhất và xem chúng thuộc plugin nào. Đừng xoá option khi chưa biết chắc nguồn gốc, và luôn sao lưu database trước. Các việc dọn dẹp khác: xoá bản nháp tự động và revision cũ, transient hết hạn, bình luận spam.

## 6. Tối ưu ảnh

Ảnh thường là phần nặng nhất của trang và quyết định LCP.

- **Định dạng hiện đại:** WordPress hỗ trợ WebP từ bản 5.8 và AVIF từ bản 6.5, với điều kiện thư viện ảnh của server (GD hoặc Imagick) hỗ trợ. Kiểm tra ở **Công cụ → Tình trạng trang web → Thông tin → Xử lý phương tiện**.
- **Đúng kích thước:** đừng tải ảnh 4000 px cho khung 800 px. WordPress tự sinh nhiều kích thước và dùng `srcset`.
- **Lazy loading:** WordPress tự thêm `loading="lazy"` cho ảnh; nhưng ảnh lớn ở đầu trang (ảnh LCP) không nên lazy load.
- **Khai báo kích thước** (`width`, `height`) để tránh nhảy bố cục, giúp CLS.

## 7. Thay WP-Cron bằng cron của server

WP-Cron chạy theo lượt truy cập, sinh thêm request PHP và có thể giữ PHP worker nhiều giây khi tên miền phân giải chậm. Tắt nó và để server chạy tác vụ định kỳ. Bài [WP-Cron chạy chậm](/vi/blog/wp-cron-server-cron) hướng dẫn từng bước.

## 8. Chặn bot và lưu lượng rác

Bot cào dữ liệu thường gọi những URL không cache được (tìm kiếm, bộ lọc, tham số ngẫu nhiên), mỗi request là một lần dựng trang đầy đủ. Xem log truy cập để tìm IP và user agent gọi nhiều nhất. Giới hạn tốc độ theo IP ở web server và tường lửa ứng dụng web (WAF) giảm tải đáng kể cho website bị cào.

## 9. Front-end: CSS, JavaScript và font

Sau khi server nhanh, phần còn lại nằm ở trình duyệt: script chặn hiển thị, font tải từ nhiều nguồn, theme quá nặng. Giảm số plugin thêm JavaScript ở mọi trang, tự host font hoặc dùng font hệ thống, trì hoãn script không cần thiết. Mỗi thay đổi ở đây nên thử trên staging, vì đây là chỗ dễ làm hỏng giao diện nhất.

## 10. Server đủ tài nguyên và đặt gần người dùng

Không tối ưu nào bù được server thiếu RAM hay CPU. Dấu hiệu thiếu tài nguyên: lỗi 502/503 khi đông khách, PHP worker luôn bận hết, server dùng swap trên đĩa. Nếu khách của bạn ở Việt Nam, đặt server ở Việt Nam hoặc gần đó giảm độ trễ mạng cho mọi request; CDN giúp phần file tĩnh cho khách ở xa.

## Tăng tốc WordPress trên ZoPanel

Các bước phía server ở trên đều có sẵn trong ZoPanel:

- **Page cache:** website → tab **PHP & cấu hình** → bật **Page cache**. Trang được cache 10 phút; người dùng đăng nhập, giỏ hàng, thanh toán, wp-admin, request POST và URL có tham số truy vấn luôn bỏ qua cache (tham số quảng cáo như `utm_*`, `fbclid`, `gclid` không tính). Một must-use plugin nhỏ tự xoá cache khi bài viết, bình luận, menu, theme hay plugin thay đổi. Kiểm tra bằng `curl -sI https://example.com/ | grep -i x-cache`. Trang **Tối ưu** liệt kê website WordPress chưa bật cache và bật được cho tất cả một lần. Chi tiết trong [tài liệu Website và PHP](/vi/docs/hosting).
- **Phiên bản PHP:** ZoPanel hỗ trợ PHP 7.4 tới 8.4 chạy song song, chọn riêng cho từng website ở tab **PHP & cấu hình**.
- **Redis object cache:** cùng tab **PHP & cấu hình**; ZoPanel tạo Redis database riêng cho website và cấu hình plugin. Redis cần được cài trên server trong mục **Cơ sở dữ liệu**.
- **Tác vụ định kỳ:** tab **WordPress** → thẻ **Vận hành** → **Server chạy tác vụ định kỳ (5 phút/lần, không theo lượt khách)**.
- **Bot:** thẻ **Giới hạn tốc độ request** trên tab **PHP & cấu hình** (Nhẹ 20/giây, Vừa 8/giây, Chặt 2/giây) và tường lửa ứng dụng web (ModSecurity + OWASP CRS) trong tab **Công cụ**.
- **Chẩn đoán:** tab **Nhật ký** → **Chạy chẩn đoán** cho biết website có bị giới hạn bởi số PHP worker hay RAM của gói không.

Có một điều nên biết: để tiết kiệm RAM, PHP của website không có khách trong 30 phút (mặc định) sẽ "ngủ". Lượt truy cập kế tiếp đánh thức nó trong vài trăm mili giây, và mã đã biên dịch được nạp lại từ OPcache trên đĩa nên trang đầu tiên gần nhanh như bình thường. Với gói cao cấp cần tránh cả độ trễ đó, bật **PHP luôn chạy** trong gói hosting. Xem [tài liệu hiệu năng PHP](/vi/docs/php-performance).

## Những sai lầm khiến WordPress vẫn chậm

- **Đo một lần, từ xa.** Lần đo đầu thường trúng cache trống. Đo nhiều lần, từ gần người dùng thật.
- **Cài ba plugin cache cùng lúc.** Chúng giẫm lên nhau và tạo lỗi khó tìm.
- **Cache cả trang đăng nhập hoặc giỏ hàng.** Khách thấy giỏ hàng của người khác: lỗi nghiêm trọng hơn chậm.
- **Chỉ tối ưu điểm PageSpeed.** Điểm phòng thí nghiệm hữu ích, nhưng Core Web Vitals từ người dùng thật mới là thứ quan trọng.
- **Quên rằng WooCommerce khác blog.** Cửa hàng có nhiều trang không cache được; object cache và đủ PHP worker quan trọng hơn ở đó.

## Kết luận

Tăng tốc WordPress không cần hàng chục plugin. Làm theo thứ tự: đo, bật page cache, nâng PHP, thêm object cache cho trang động, dọn plugin và database, rồi mới tối ưu ảnh và front-end. Bốn bước đầu thường mang lại phần lớn cải thiện.

Gói Free của ZoPanel có page cache, Redis object cache, nhiều phiên bản PHP và WordPress Toolkit cho 10 website. Cài bằng `curl -fsSL https://get.zopanel.net | sudo bash` trên Ubuntu 22.04/24.04 hoặc Debian 12/13, xem thêm [tài liệu WordPress Toolkit](/vi/docs/wordpress) và [bảng giá](/vi/pricing).

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

### Cách tăng tốc WordPress hiệu quả nhất là gì?

Bật page cache. Trang đã cache được web server trả ngay mà không chạy PHP hay truy vấn database, nên TTFB giảm mạnh và server phục vụ được nhiều khách hơn hẳn. Trong phép đo của chúng tôi, page cache nâng số website trên cùng VPS 4 GB từ khoảng 100 lên 250.

### WordPress nên dùng PHP phiên bản nào?

WordPress.org khuyến nghị PHP 8.3 trở lên. Trước khi nâng, thử plugin và theme trên bản staging, vì plugin cũ có thể chưa tương thích.

### Có cần Redis khi đã có page cache không?

Với blog và website giới thiệu ít người đăng nhập thì thường không cần. Với WooCommerce, website thành viên hay website có nhiều người dùng trong wp-admin, Redis object cache giúp đáng kể vì những trang đó không dùng được page cache.

### Vì sao WordPress chậm dù đã cài plugin cache?

Thường do trang thực tế không được cache (người dùng đăng nhập, URL có tham số, cookie làm bỏ qua cache), plugin nặng chạy ở những trang không cache được, hoặc server thiếu PHP worker. Kiểm tra header cache của phản hồi và dùng Query Monitor để tìm nút thắt.

### Core Web Vitals đạt bao nhiêu là tốt?

Theo web.dev, LCP từ 2,5 giây trở xuống, INP từ 200 ms trở xuống và CLS từ 0,1 trở xuống, đo ở phân vị 75 của lượt tải trang trên mobile và desktop.