Hướng dẫn cài

đặt plugin
LiteSpeed
Cache
< Bản gốc: Johnny Nguyen | Dịch & chú thích thêm: Nguyễn Đức Anh />

// Bạn được quyền sao chép, đăng lại nội dung này, miễn là có dẫn nguồn //

- xóm Và, Chương Mỹ, Hà Nội, hè 2020 -

Vài lời của người dịch: plugin LiteSpeed Cache tuy hơi khó cài đặt lần
đầu, nhưng nếu bạn làm đúng cách, nó ăn dễ WP Rocket hay Swift
Performance (dù đây cũng là hai plugin cache có chất lượng hàng
đầu). Trong bài viết dưới đây của Johnny Nguyen​, tôi sẽ chia sẻ với
mọi người cách cấu hình nâng cao plugin LiteSpeed Cache để tối đa
hóa tốc độ và không còn phải đau đầu về caching nữa.

Nhờ có Quic.cloud, giờ bạn không bắt buộc phải dùng máy chủ web
của LiteSpeed thì mới dùng được plugin LiteSpeed Cache, nhưng
nếu có nó làm web server, hiệu suất trang sẽ tốt hơn. Hiện rất nhiều
hosting hỗ trợ sẵn máy chủ LiteSpeed / OpenLiteSpeed hoặc có thể
cài đặt dễ dàng. Bạn có thể tham khảo host của Closte, cài
CyberPanel trên DigitalOcean, hoặc Vultr. Lưu ý về mặt chi phí thì
OpenLiteSpeed hoàn toàn miễn phí, còn LiteSpeed Enterprise hiện
chỉ miễn phí khi dùng một tên miền với RAM của máy chủ web từ
2GB trở xuống.

Một số thông tin cơ bản về LiteSpeed web servers

● LiteSpeed là web server phổ biến thứ 4 sau Apache,
NGINX và Microsoft IIS. LiteSpeed phổ biến kể từ khi nó
được biết đến là có tốc độ ngang ngửa NGINX nhưng lại
có khả năng tương thích với Apache.
● Bạn có thể chạy các phần mềm Apache trên đó (chẳng hạn
như WHM/cPanel) và cũng có thể sử dụng các tùy chỉnh
của Apache (chẳng hạn như chỉnh sửa file .htaccess).
● Nó phổ biến với cả các website nhỏ chạy trên VPS cũng
như các website thương mại lớn chạy trên máy chủ riêng
(dedicated servers).
● Nó đem lại hiệu suất rất tuyệt vời mà không cần nhiều tùy
chỉnh.

1
 ● Kèm các plugin cache độc quyền (tự thiết kế) cho
WordPress, Joomla, Drupal, Magento, vân vân.
● Cũng kèm theo các ứng dụng bảo mật tự xây dựng để
chống lại kiểu tấn công vét cạn (brute-force attacks) và
DDoS (tấn công từ chối dịch vụ).

Một số thông tin cơ bản về plugin LiteSpeed Cache

(LSC)
● Plugin MIỄN PHÍ chất lượng cao chỉ có một yêu cầu- phải
được sử dụng trên các máy chủ web của LiteSpeed (cái
mà tôi đặc biệt yêu thích). Trên các máy chủ
không-phải-LiteSpeed, bạn có thể sử dụng tất cả các tính
năng của nó, ngoại trừ caching (đây là chức năng chính).
● Đây là plugin caching cấp độ doanh nghiệp
(enterprise-grade) đúng nghĩa (tốt cho cả người tiêu dùng
thông thường và các yêu cầu cao cấp). Tôi đặc biệt khuyến
khích sử dụng nó trên các trang có lưu lượng truy cập lớn
(trên 1 triệu lượt xem trên tháng) và/hoặc có nhiều trang
(trên 1 ngàn trang).
● LSC được cập nhật rất thường xuyên. Đội lập trình viên
của họ cực kỳ năng nổ (extremely aggressive) trong việc
sửa các lỗi và khắc phục vấn đề ngay lập tức. Mô hình kinh
doanh của họ xoay quanh việc duy trì tính ổn định của liên
kết “máy chủ-máy khách”, vì thế họ không bao giờ tụt hậu
về bất kỳ vấn đề quan trọng nào. Bất kỳ lỗi nào được tìm
thấy thường sẽ được sửa trong vài GIỜ (chứ không phải
trong vài ngày hay vài tuần).
● Với những ai không chạy trên máy chủ LiteSpeed, tôi thích
sử dụng plugin Swift Performance cache. Ngoài ra Rocket,

2
 Breeze, Comet Cache, Cache Enabler và Speed of Light
cũng có chất lượng tốt.

LiteSpeed Cache có nhiều tính năng

● Caching phía máy chủ (sử dụng máy chủ để tạo các trang
cache chứ không dùng PHP chậm).
● Caching đối tượng (Object caching).
● Có thể cache các trang riêng tư (trang người dùng đăng
nhập), và các trang admin.
● Tối ưu hóa ảnh (vâng, nó miễn phí!)
● Tối ưu hóa cơ sở dữ liệu
● Tương thích CDN
● QUIC.cloud – tính năng mới phục vụ các trang cache thông
qua CDN cho những ai không sử dụng máy chủ LiteSpeed!
● Và rất nhiều thứ khác nữa!

Tại sao tôi thích plugin LiteSpeed Cache hơn các plugin khác:

● Phù hợp nhất cho các trang có lưu lượng truy cập khủng
(lựa chọn ưa thích của tôi)
● Phù hợp nhất cho các trang có hàng ngàn trang (lựa chọn
ưa thích của tôi)
● Có kiểu object-caching
● Nhiều tùy chọn chi tiết và dành cho nhà phát triển để cache
nội dung riêng tư
● Plugin cache phía máy chủ đúng nghĩa (nhanh hơn so với
cấp độ PHP)
● Nhiều tùy chọn tối ưu nâng cao dành cho CSS/JS (nếu bạn
thích)
● Tối ưu hóa ảnh miễn phí

3
 ● Tối ưu hóa cơ sở dữ liệu (chuyển các bảng thành dạng
InnoDB và view autoloads)
● Dịch vụ QUIC.cloud mới

LS & LiteSpeed cache không chỉ tăng tốc trang web của bạn mà còn
giúp bạn giảm tải server đi nhiều-cải thiện hiệu suất mà vẫn tiết kiệm
được tiền!

Hướng dẫn cài đặt NHANH

Ngay dưới đây là phần hướng dẫn cài đặt chỉ 2 phút cho những
người bận rộn. Bạn không mất nhiều thời gian để có tốc độ xé gió.

(Lưu ý: Tôi thích các tùy chỉnh của mình hơn nhiều so với các cài đặt
mặc định của LiteSpeed Cache. Để hiểu rõ tại sao lại như vậy, hãy
đọc các hướng dẫn cài đặt CHI TIẾT).

1. Cài​ plugin LiteSpeed Cache (miễn phí). Sau đó đi đến

phần Setting
2. General > General > Request Domain Key​ – cần làm
điều này nếu bạn định sử dụng dịch vụ của QUIC.cloud
hoặc bạn muốn các tính năng của LiteSpeed caching trên
nền máy chủ không-phải-LiteSpeed. Với những ai sử dụng
LScache trên máy chủ LiteSpeed, bạn có thể không cần
tích hợp QUIC.cloud.
3. Cache > Cache > Enable Cache​ – bật tùy chọn này lên.
Nếu bạn không sử dụng LS server, bạn cần phải đăng ký
QUIC.cloud để sử dụng tính năng này.
4. Cache > Cache Logged-in users​ – OFF.
5. Cache > Drop Query String​ – nhập vào 3 mục sau, mỗi
mục một dòng riêng lẻ (fbclid, gclid, utm*).
6. Cache > Browser > Browser Cache​ – ON.
7. Cache > WooCommerce > Privately Cache Cart​ – OFF.

4
 8. CDN > CDN Settings > QUIC.cloud CDN​ – bật nếu bạn
muốn sử dụng QC CDN.
9. CDN > CDN Settings > Cloudflare API​ (chỉ dành cho
những ai đang dùng Cloudflare) – nhập email, khóa API
toàn cầu và tên miền.
10. Page optimization > CSS Settings > Generate Critical
CSS​ – OFF.
11. Page optimization > CSS Settings > Inline CSS
Async Lib​ – OFF.
12. Page optimization > Optimization Settings > Remove
WordPress Emoji​ – ON. (Các trình duyệt hiện đại đều đã
tích hợp sẵn emojis bên trong).
13. Nhấn [SAVE CHANGES]​ và bạn sẽ có tốc độ xé gió!

Hướng dẫn cài đặt CHI TIẾT

Bước 1 – Cài đặt plugin LiteSpeed Cache

Yêu cầu:

● Bạn phải sử dụng webserver của LiteSpeed hoặc dịch vụ

QUIC.cloud để áp dụng cơ chế caching của họ. Để có kết
quả tốt nhất, hãy sử dụng máy chủ LiteSpeed!
● Nếu bạn mua web hosting từ bên thứ ba, cần đảm bảo
rằng họ chạy trên máy chủ LiteSpeed.
● Nếu bạn tự quản trị lấy web-server của bạn, cần đảm bảo
bạn đã cấu hình bộ đệm gốc cho LS cũng như bật chức
năng crawler.

Bước 2 – Cấu hình plugin LiteSpeed Cache

5
Đi đến phần setting từ panel quản trị (admin). Click vào LiteSpeed
Cache > General​.

Tôi sẽ đi đến tất cả các cài đặt và nói chi tiết các thiết lập riêng của
mình. Bất kỳ cài đặt nào mà tôi không đề cập đến nghĩa là tôi dùng
thiết lập mặc định có sẵn. Bạn cũng nên tham khảo thêm tài liệu
hướng dẫn chính thức của LiteSpeed Cache.

General > General Settings

● Automatically Upgrade​ (tự động cập nhật LiteSpeed
Cache khi nó ra phiên bản mới) – OFF là an toàn nhất,
nhưng thành thật mà nói bạn hoàn toàn có thể để là ON. Vì
LSC được xây dựng rất tốt; các bản cập nhật chưa bao giờ
phá vỡ bất cứ trang web nào của tôi (còn các plugin cấp độ
người dùng như Rocket hay Swift thì đã từng). LSC được
cập nhật rất thường xuyên vì thế bạn có thể cảm thấy đỡ
phiền phức hơn nếu bạn cho phép cập nhật tự động, còn
nếu không bạn sẽ phải thấy thông báo cập nhật hàng tuần
reo réo lên trên màn hình =)). Cảnh báo nhỏ: Tôi từng thấy
một số cập nhật không thường xuyên (occasional updates)
tạo ra vấn đề với tính năng tối ưu hóa ảnh của họ, vì thế
bạn có thể không muốn cập nhật tự động nếu trang của
bạn dựa rất nhiều vào tính năng này.
● Domain Key​ (khóa cho tên miền) – bạn có thể yêu cầu key
nếu bạn có ý định sử dụng bất kỳ tính năng nào của
QUIC.cloud. Nó về cơ bản là CDN dạng khủng, nhưng có
thêm nhiều tính năng mở rộng như tối ưu hóa ảnh (nén,
ảnh chiếm chỗ), tạo critical CSS, caching trang tại máy chủ
biên (edge). Tôi chỉ sử dụng nó để nén ảnh trên các trang
không sử dụng plugin ShortPixel. Còn các tính năng khác
tôi không cần. Nếu bạn sử dụng LSC trên máy chủ
không-phải-LiteSpeed server, thì bạn cần có QUIC.cloud
để nhận được lợi ích từ khả năng caching của họ (bạn có

6
 thể xem hướng dẫn kết nối plugin LiteSpeed Cache vs
QUIC.cloud ở bài viết này).
● Notifications​ (gửi các thông báo) – Tôi để OFF.

Cache > Cache

● Enable LiteSpeed Cache​ (bật litespeed cache) – ON (tất
nhiên rồi!)
● Cache Logged-in Users​ (cache cho người dùng đã đăng
nhập) – OFF trong hầu hết trường hợp. Chỉ thực tế nếu
bạn có rất ít người dùng đăng nhập, VÀ tất cả họ đều thấy
thông tin khác nhau, VÀ họ ghé thăm trang và đăng nhập
thường xuyên! Ngay cả có như vậy đi nữa tôi vẫn thích để
nó là OFF để phòng trường hợp có xung đột tiềm năng.
Bạn chắc chắn không nên sử dụng tính năng này nếu bạn
có nhiều người dùng; nó sẽ tạo ra quá nhiều trang cần phải
cache mà hầu như không được dùng.
● Cache Commenters​ – OFF. Chỉ có tác dụng trên trang
nào đấy đang có rất nhiều bình luận cùng lúc. Nếu bình
luận trên trang của bạn cần phải kiểm duyệt và bạn bật
chức năng này (ON) thì người bình luận sẽ nhận được
trang đã cache và không thấy bình luận đang chờ phê
duyệt, nếu tắt (OFF) người bình luận sẽ nhận được trang
động, chứ không phải trang đã được cache. Không có
nhiều ảnh hưởng dù bạn bật hay tắt (vì đa số website
không có quá vài người bình luận cùng lúc), nhưng tôi
thích để OFF hơn. Tính năng này có lẽ hữu ích trên trang
rất lớn, nơi mà có thể có hàng nghìn người bình luận cùng
lúc.
● Cache REST API​ – không cần thiết với đa số mọi người.
Để nó là ON, nhưng hãy tắt (OFF) nếu bất kỳ tính năng
nào bị hỏng

7
● Cache Login Page​ (cache cho trang đăng
nhập/wp-login.php) – ON sẽ nhanh hơn vì các bot tự động
thường tấn công trang đăng nhập. Để OFF nếu nó phá vỡ
trang đăng nhập của bạn (thiết kế, chức năng, captcha).
Với những ai thay đổi url của wp-login, đừng làm như vậy!
LiteSpeed server đã tích hợp sẵn tính năng bảo vệ url
đăng nhập rồi. Hiệu suất sẽ tốt hơn nhiều khi bạn để LS
ngăn chặn tấn công vét cạn (brute force attacks) so với để
các plugin bảo mật chậm chạp làm!
● Cache favicon.ico​ – ON
● Cache PHP Resources​ (cache các tài nguyên PHP) – ON.
Thực sự giúp ích cho các theme và plugin viết mã không
tốt.
● Cache Mobile​ (cache di động) – OFF với hầu hết các
trang! Đừng bật tính năng này trừ khi bạn có AMP hoặc có
thiết kế/nội dung riêng cho di động. Các trang có thiết kế
đáp ứng cũng không cần bật tính năng này.
● List of Mobile User Agents​ – không cần quan tâm. Nó chỉ
cần dùng nếu “Cache Mobile” được bật. Bạn có thể thêm
các thiết bị khác ở đây nếu bạn cảm thấy một số cái bị
thiếu.
● Private Cached URIs​ – Tôi không bao giờ sử dụng. Nó chỉ
hữu ích cho các trang cần tách riêng cache cho từng người
dùng (giả định là họ xem các nội dung khác nhau). Một ví
dụ tốt là trang tài khoản, nhưng caching sẽ không cần thiết
nếu người dùng của bạn không đăng nhập thường xuyên.
Bên cạnh đó vì họ đã là người dùng rồi họ có khả năng
chẳng bận tâm lắm đến chuyện mất một chút giời gian tải
trang. Tôi cũng không khuyến nghị sử dụng vì máy chủ của
bạn phải mất thêm thời gian tạo cache trong khi người
dùng có thể không quay lại sớm để tận dụng lợi thế ấy.
● Force Public Cache URIs​ – các trang liệt kê ở đây sẽ
được cached. Hữu ích trong trường hợp cần loại trừ các

8
 trang cụ thể khỏi các quy tắc loại trừ có độ phủ rộng dựa
trên chuỗi.
● Drop Query String​ (loại bỏ chuỗi truy vấn) – rất hữu ích
để tránh caching trang không cần thiết cho một số chuỗi
truy vấn. Một số chuỗi truy vấn dùng để thay đổi nội dung
(ví dụ ngôn ngữ, tiền, vân vân) và cần phải cache một cách
riêng rẽ. Một số chuỗi truy vấn không làm thay đổi nội dung
(chẳng hạn các mã theo dõi Google/Facebook, các cookies
tiếp thị liên kết) và chỉ được dùng để theo dõi, do vậy
chúng cần đưa vào danh sách bỏ qua (drop). Tôi khuyên
đưa các dòng này vào: fbclid, gclid, utm*, _ga. (hiện mặc
định LiteSpeed Cache đã thêm các query này).

Cache > TTL (Time To Live / Thời Gian Sống)

Phần này bạn giữ như mặc định, không thay đổi gì

An toàn nhất là bạn đừng động đến phần này, cứ giữ nguyên như
mặc định là được rồi:

● Default Public Cache TTL​ (thời gian sống mặc định của
cache công khai) – giữ nguyên. Đây là cài đặt thời gian
sống của cache cho hầu hết các trang. Tất cả các TTL
khác là cho các kiểu trang cụ thể. Giá trị mặc định là một
tuần. Thời gian ghi trên này là tính theo giây. Các giá trị có
thể là 1 giờ (3600), 1 ngày (86400), 2 tuần (1209600). Vì
hầu hết các trang không thay đổi sau khi đăng, để TTL dài
hơn có thể có ích.
● Default Private Cache TTL​ (thời gian sống mặc định của
cache riêng) – giữ nguyên.
● Default Front Page TTL​ (thời gian sống mặc định của
trang front page) – giữ nguyên.
● Default Feed TTL​ – giữ nguyên.

9
 ● Default REST TTL​ – giữ nguyên.
● Default HTTP STATUS 404 Page TTL​ – giữ nguyên.
● Default HTTP STATUS 403 Page TTL​ – giữ nguyên.
● Default HTTP STATUS 500 Page TTL​ – giữ nguyên.

Cache > Purge

● Purge All ON Upgrade​ (tự động purge cache khi bạn cập
nhật theme, plugin, hoặc lõi của WordPress) – an toàn nhất
thì bạn để là ON.
● Auto Purge Rules For Publish/Update​ (các quy tắc tự
động purge khi xuất bản/cập nhật) – các thiết lập mặc định
cũng ổn. Bạn có thể bỏ chọn các tùy chọn nhất định nếu
bạn biết chúng không bao giờ cập nhật khi bạn xuất bản
bài đăng mới. Hoặc bạn cũng có thể tick vào tùy chọn “All
pages” để đảm bảo rằng mọi thứ sẽ được purged khi có
bài viết mới hoặc cập nhật. Nếu bạn có các widgets trên
bài post blog nhận được bình luận thường xuyên, “All
pages” có thể là ý tưởng tốt, nhưng nhìn chung, trong đa
số trường hợp, để như mặc định tốt hơn.
● Serve Stale​ – Tôi thích ý tưởng ẩn bên dưới lựa chọn này
(giúp giảm tải server trong khi purge cache) nhưng nó
không cần thiết trên 98% website trừ khi bạn biết bạn đang
làm gì. Tôi để nó OFF.
● Scheduled Purge URLs​ – được dùng để purge URL cụ
thể vào thời điểm mà bạn muốn.
● Scheduled Purge Time​ – thời gian chính xác để thực hiện
purge theo lịch trình. Tính năng này được dùng cho những
người không sử dụng auto-purge, hoặc có nội dung được
tạo ra từ các nguồn bên ngoài mà không kích hoạt
auto-purge.
● Purge All Hooks​ – danh sách này liệt kê các hook kích
hoạt trang purge bất cứ khi nào các hành động nhất định

10
 được thực hiện. Những cái mặc định nên được để nguyên
như vậy vì chúng ảnh hưởng trực tiếp đến thiết kế của
trang web. Bạn có thể thêm các hook khác của các plugin
khác nếu chúng ảnh hưởng đến thiết kế của trang (Nếu
bạn không biết cách thêm các hook, bạn chỉ cần purge thủ
công cache bất cứ khi nào bạn thực hiện thay đổi ảnh
hưởng đến frontend/giao diện người dùng bên ngoài).

Nói thêm về cái “Auto Purge Rules For Publish/Update”: Khi bài đăng
được xuất bản hoặc cập nhật, không chỉ có bài post, page đó thay
đổi. Danh sách thư mục, danh sách tag, font page của blog, và nhiều
kiểu dạng lưu trữ khác có thể cũng thay đổi. Chẳng hạn như bạn có
thể chỉ định cụ thể kiểu trang sẽ được tự động purge mỗi khi bài đăng
được tạo hoặc cập nhật.

Những trang mà bạn chọn phụ thuộc vào theme của bạn và cách các
post hiển thị trên trang của bạn.

Có tùy chọn cho All pages/Tất cả các trang, cái được vô hiệu hóa
theo mặc định. Khi bạn bật nó (tick chọn), tất cả các checkbox khác
sẽ được bỏ qua. Lựa chọn All pages​ có ý nghĩa nếu bạn không bật
ESI, và bạn có các widget liên quan đến bài post động hiển thị trên
từng page, nhưng trong phần lớn trường hợp, tốt nhất là không chọn
All pages​.

Để tối ưu hóa hiệu suất, người quản trị chỉ nên check các tùy chọn
cần thiết. Lấy ví dụ, với thư mục lưu trữ, nếu trang chỉ có thư mục
tháng mà không có thư mục năm hoặc thư mục ngày thì chỉ “monthly
archive” là cần được tick chọn. Nếu trang không có lưu trữ theo tác
giả (author), thì bạn không cần chọn nó vì tick chọn thêm sẽ chỉ làm
chậm quá trình này.

11
Cache > Excludes
Tôi hầu như không sử dụng bất cứ tính năng nào trong phần này.
Chúng chỉ có ích khi bạn muốn loại trừ cache cho trang nào đấy. Có
lẽ chỉ thích hợp khi bạn muốn thực hiện kiểm tra, chẩn đoán (sửa
chữa các rắc rối liên quan đến cache).

● Do not Cache URIs​ – sử dụng để loại trừ các trang không

cần cache. (Tôi khuyên các trang đó nên bao gồm trang
liên hệ, trang đã được đăng nhập, hoặc bất cứ trang thanh
toán nào. Dù vậy trang thanh toán của WooCommerce đã
được loại trừ theo mặc định rồi).
● Do Not Cache Query Strings​ – loại trừ chuỗi truy vấn
(query strings) nhất định không cần cache. Tốt trong một
số trường hợp khi một số trang có chuỗi truy vấn cần làm
mới nội dung thường xuyên (refresh content often).
● Do Not Cache Categories​ – loại trừ các thư mục không
cho cache.
● Do Not Cache Tags​ – loại trừ các tag không cho cache.
● Do Not Cache Cookies​ – loại trừ cookies nào không cần
cache.
● Do Not Cache User Agents​ – loại trừ user agents không
cần cache
● Do Not Cache Roles​ – loại trừ các user roles (vai trò
người dùng) cụ thể để nó không cần cache. Không cần
thiết trừ khi bạn thực sự muốn caching các trang riêng tư
hoặc người dùng đã đăng nhập.

Cache > ESI

Tôi thích chức năng nâng cao của ESI vì nó cho phép bạn có được
lợi ích từ việc cache ngay cả trong các trang (động) vốn không nên
cache. Đây là tính năng tuyệt vời và thường chỉ có khả năng cấu hình

12
từ phía máy chủ chứ không bao giờ có ở plugin…nhưng LiteSpeed lại
làm được, họ đặc biệt như vậy đấy!

Bạn có thể chuyển đổi bất kỳ chức năng, nội dung hoặc widget nào
thành ESI và LSC sẽ cho phép bạn quyết định xem nên cache kiểu gì:
riêng tư, công khai với TTL riêng của nó (tốt cho các nội dung cần
TTL ngắn), hoặc không cần cache chút nào (để nó động hoàn toàn).
Trong một vài cuộc kiểm tra mà tôi tiến hành, tôi nhận thấy chức năng
hoạt động hoàn hảo NHƯNG vẫn có một số vấn đề cho bất kỳ chức
năng nào dựa trên kích hoạt cụ thể của riêng nó và chức năng JS
cũng như những cái tương tự. Cần kiểm tra cẩn thận và tham khảo kỹ
tài liệu trước khi bạn quyết định sử dụng nó.

● Enable ESI​ – tôi để nó là OFF vì tôi không sử dụng nó

nhiều.
● Cache Admin Bar​ – ON vì an toàn và cũng hợp lý.
● Cache Comment Form​ – ON vì an toàn và cũng hợp lý.
● ESI Nonce​ – cho các plugin nhất định (sử dụng các tính
năng bảo mật nonce) để hoạt động thông suốt với bộ nhớ
cache riêng.
● Vary Group​ – không quan tâm trừ khi bạn hiểu nó dùng
làm gì.

Cache > Object

Caching kiểu Object (đối tượng) thường không được bật trên máy
chủ trừ khi (A) host bạn đang dùng cho phép nó hoặc (B) đó là máy
chủ của bạn và bạn bật Memcache hoặc Redis.

● Object Cache​ – OFF là an toàn với hầu hết mọi người.

Bạn có thể để nó là ON nếu (1) bạn đã cài Memcache hoặc
Redis, (2) bạn có nhiều nội dung động hoặc truy vấn cơ sở
dữ liệu (database queries).

13
● Method​ (phương thức) – Redis được ưa thích hơn so với
Memcache.
● Host​ – phải là local host trừ khi nó có địa chỉ khác (có lẽ sẽ
chậm hơn và chẳng phải ý tưởng hay khi bạn để nó ở máy
chủ bên ngoài).
● Port​ – cổng mặc định là ổn trừ khi bạn cài nó trên cổng tùy
chỉnh khác.
● Default Object Lifetime​ – mặc định 360 giây là đủ an
toàn, nhưng bạn có thể gia tăng thêm nếu nội dung động
của bạn không được làm mới nhanh như vậy.
● Username​ – thường không cần thiết trừ khi bạn sử dụng
SASL – phiên bản bảo mật fork của memcache.
● Password​ – thường không cần thiết.
● Redis Database ID​ – thường cứ để yên như mặc định thì
tốt hơn trừ khi bạn muốn sử dụng ID Redis database khác
để cải thiện hiệu suất trên database Redis bị tắc ngẽn.
● Global Groups​ – tôi không động đến nó, bạn có thể thêm
nếu thấy cần thiết.
● Do Not Cache Groups​ – phần này tôi cũng không động
đến, bạn thêm nếu thấy cần thiết.
● Persistent Connection​ – Để ON là an toàn nhất.
● Cache Wp-Admin​ – tôi thích để nó là OFF trừ khi bạn thực
sự sử dụng object cache để tăng tốc khu vực backend. Tôi
thường khuyến khích cập nhật máy chủ nếu backend của
bạn chậm chạp.
● Store Transients​ – nên để ON.
● Các mục “Persistent Connection”, “Cache WP-Admin”,
hoặc “Store Trasients”…bạn có thể bật hoặc tắt tùy thuộc
vào nhu cầu sử dụng của bạn. Lựa chọn an toàn là để
chúng OFF hoặc không sử dụng kiểu cache object ngay từ
ban đầu nếu bạn không biết bạn đang làm gì. Caching
WP-admin nên cân nhắc sử dụng khi mà khu vực admin
chạy chậm trên các trang web nặng, nhưng bạn có nguy

14
 cơ gặp phải độ trễ thông tin (thông tin không cập nhật theo
thời gian thực).

PS: Khi người dịch dùng thử host Closte (LiteSpeed) và cài
CyberPanel trên DigitalOcean thì cả hai host này không cài sẵn
Memcached và Redis. Khi cài CyberPanel trên Vultr, VPS này có tùy
chọn cho phép cài cả hai Object cache này.

Cache > Browser

Cái này có tính năng tương đương với các dòng expiry (hết hạn) của
HTML trong file .htaccess hoặc một số plugin khác.

● Browser Cache​ – Tôi thích để là ON.

15
 ● Browser Cache TTL​ – bất cứ khoảng thời gian nào từ
2592000 giây (tương đương với 30 ngày) cho đến
31557500 (tương đương với một năm) tôi đều thấy ổn.

Phần vừa nói ở trên chính là cache phía trình duyệt, rất đơn giản
nhưng đem lại cải thiện vô vùng lớn cho những ai hay ghé thăm
website của bạn.

PS: với OpenLiteSpeed, dù thiết lập thời gian cache trình duyệt là bao
nhiêu ngày trong plugin LiteSpeed cache thì bạn vẫn chỉ được cache
có 7 ngày! Để khắc phục lỗi đó bạn có thể tham khảo bài viết sửa lỗi
Browser Cache TTL trong OpenLiteSpeed​.

Cache – Advanced
Các cài đặt này chỉ dành cho người dùng nâng cao.

● Check Advanced Cache​ – thường kiểm tra trừ khi bạn sử

dụng nhiều plugin cache cùng lúc- đây là điều mà tôi đặc
biệt khuyên không nên làm. Trong trường hợp bạn sử
dụng LSC cùng với plugin cache khác, bạn có thể để tùy
chọn này hoặc bỏ chọn tùy thuộc vào plugin nào bạn cần
hoặc có ý định sử dụng file advanced-cache.php. PS: có vẻ
trong phiên bản mới nhất LiteSpeed Cache đã bỏ tính năng
này.
● Login Cookie​ – chỉ cần thiết nếu bạn có nhiều web cùng
chia sẻ chung tên miền (một cái ở trong thư mục con).
Trong đó, một trang cần nhập một định danh lookie cookie
duy nhất vì thế LSC sẽ không trộn lẫn những khách truy
cập đã đăng nhập vào trang đó

16
 ● Improve HTTP/HTTPS Compatibility​ (cải thiện khả năng
tương thích HTTP / HTTPS) – nên để OFF và dù sao thì
bạn cũng không nên có nội dung hỗn hợp vì điều đó sẽ
ảnh hưởng đến trạng thái SSL của bạn.
● Instant Click​ (*) – tôi để nó OFF. Nó cũng hay khi hoạt
động ổn, nhưng có thể gây vấn đề trên nhiều trang. Đây là
chức năng dùng để tải trước các liên kết khi người dùng
hover chuột qua nó. Nhưng nó có thế là nguyên nhân làm
việc sử dụng máy chủ bị tăng cao nếu người dùng hover
qua nhiều liên kết trước khi thực sự click. Chức năng này
cũng có thể làm xáo trộn việc theo dõi cookie của bạn (ví
dụ tiếp thị liên kết / affiliates, vân vân).

(*): Cá nhân người dịch không dùng Instant Click, nhưng tôi dùng tính
năng tương tự và mạnh mẽ hơn của plugin Flying Pages, các liên kết
chỉ cần nằm trong khung nhìn trình duyệt là được tải về (tất nhiên là
chỉ html). Bạn có thể tham khảo hướng dẫn sử dụng plugin Flying
Pages ở đây.

Cache > WooCommerce

Chú thích của người dịch: phần này bạn chỉ thấy nếu trang web của
bạn cũng cài Woo, còn không thì sẽ không thấy.

● Product Update Interval​ (Tần số cập nhật sản phẩm) –

lựa chọn đầu tiên là an toàn. Lựa chọn thứ hai tốt hơn, và
lựa chọn thứ ba cho hiệu suất tốt nhất. Cái cuối là an toàn
nhất.
● Use Front Page TTL for the Shop Page​ – ON sẽ có ích.
● Privately Cache Cart​ – OFF. Tôi không thích nó để ON
như mặc định và không tạo ra ý nghĩa gì. Tính năng này
đôi khi là nguyên nhân gây lộn xộn session giỏ hàng. Tôi
nghĩ việc caching giỏ hàng rỗng là phí phạm và dù sao đi

17
 nữa thì người mua hàng tiềm năng không thể lượn lờ giữa
các trang quá lâu. Cho dù họ mua hay không mua. Và nếu
họ có ý định mua, tôi nghĩ họ có thể kiên nhẫn đợi thêm
một giây.

---

Tiếp theo phần 1 về cài đặt plugin LiteSpeed Cache chuyên sâu khá
dài, tôi tiếp tục dịch phần hai. Bài viết gốc của tác giả Johnny Nguyen.
Tôi có bổ sung thêm thông tin một số chỗ khi thấy cần thiết để bạn
đọc hiểu các tùy chọn tốt hơn, từ đó đưa ra được các lựa chọn chính
xác, phù hợp với từng website.

Phần này là phần mà tôi có nhiều quan điểm khác biệt với Johnny,
chẳng hạn anh ấy không bao giờ thích rút gọn và gộp CSS/JS, tạo
critical CSS cũng như lazy load ảnh. Trong khi tôi thì trong đa số
website lại thích làm vậy. OK, mọi thứ đều ổn, mỗi người đều có quan
điểm riêng, quan trọng là bạn cần hiểu rõ các tùy chọn có ý nghĩa như
thế nào rồi tự quyết định.

CDN > CDN Settings

● QUIC.cloud CDN​ – Tôi nghĩ mọi người nên đăng ký tài
khoản miễn phí QUIC.cloud (QC) cho dù bạn có bật nó hay
không. Cá nhân tôi thì không bật. QC có các tính năng sau:
caching HTML trên CDN (cần thiết nếu máy chủ của bạn
chậm hoặc/và bạn không có máy chủ LiteSpeed), tối ưu
hóa ảnh (nếu bạn muốn sử dụng công cụ nén của LSC
thay vì plugin ShortPixel/Imagify/vân vân), tạo Critical CSS
(tôi không khuyến khích CCSS), CDN cho các tài nguyên
tĩnh (nếu bạn hiện không sử dụng dịch vụ CDN nào khác),
vân vân.

18
● Sử dụng CDN Mapping – Để ON nếu bạn sử dụng CDN
(những ai đang dùng Cloudflare hoặc QC nên bỏ qua lựa
chọn này).
● CDN URL​ – Nhập vào URL CDN và kiểu file bạn muốn bao
gồm. Đường dẫn phải là URL đầy đủ, bao gồm cả http://
hoặc https://. Bạn có thể sử dụng nhiều CDN cùng lúc
(chẳng hạn như bạn sử dụng dịch vụ A cho ảnh, dịch vụ B
cho video). Nếu bạn sử dụng nhiều CDN cho cùng tài
nguyên, nó sẽ thực hiện lựa chọn ngẫu nhiên. Chú thích
của người dịch: nói riêng về CDN cho video tôi thấy
BunnyCDN​ được mọi người khen có chất lượng tốt và giá
vừa phải. Dùng CDN cho video cũng là cách tăng tốc video
tốt nhất tuy nhiên không rẻ. Nếu bạn vẫn dùng YouTube,
plugin WP YouTube Lyte có thể là lựa chọn tốt để giúp
tăng tốc video mà vẫn đảm bảo SEO.
● Include File Types​ – nói thêm về cái này, mặc định nó có
các định dạng sau: aac, css, eot, gif, jpeg, js, jpg, less,
mp3, mp4, ogg, otf, pdf, png, svg, ttf, woff. Nếu website của
bạn sử dụng các định dạng khác thì bạn cần thêm vào đây
để nó được phục vụ qua CDN. Chẳng hạn nếu bạn có định
dạng ảnh mới WebP, bạn cần thêm .webp vào.
● HTML Attribute To Replace​ (thuộc tính HTML thay thế) –
Tôi không động đến phần này. Thêm nếu bạn thấy cần
thiết.
● Original URLs​ (URL gốc) – bạn thường không cần thay
đổi điều này trừ khi trang của bạn trải dài ra nhiều URL.
Lấy ví dụ một số trang multisite hoặc trang đa ngôn ngữ sẽ
sử dụng nhiều tên miền hoặc tên miền phụ.
● Included Directories​ (bao gồm các thư mục) – mặc định
là đã bao gồm rồi (wp-content, wp-includes) nhưng bạn cứ
thoải mái thêm các thư mục khác mà bạn muốn.
● Exclude Path​ (đường dẫn loại trừ) – được dùng để loại trừ
bất cứ thư mục nào nằm trong thư mục included kể trên.
Thường tôi để trống phần này.

19
 ● Load jQuery Remotely​ (tải jQuery từ các máy chủ khác) –
Tôi để nó là OFF nhưng bạn có thể để nó là ON nếu thấy
tùy chọn đó phù hợp. Chú thích của người dịch: bạn có thể
để là Google hoặc CDNJS, khi ấy website của bạn sẽ lấy
jQuery từ đây chứ không phải từ máy chủ hay CDN của
bạn nữa. Nói chung lời khuyên là thế này, nếu máy chủ
của bạn đủ mạnh và gần người dùng thì nên để OFF. Nếu
máy chủ gốc của bạn ở xa người dùng và bạn muốn tiết
kiệm tiền CDN thì nên dùng (chọn Google hoặc CDNJS).
Ngoài ra, tùy chọn này chỉ có tác dụng khi bạn không gộp
jQuery vào một file JS chung (tính năng combine
JS)…Ngày xưa việc tải jQuery từ thư viện dùng chung còn
có thể có tác dụng cache phía trình duyệt khi mà người
dùng trước đó đã vào website nào đấy khác cũng sử dụng
thư viện dùng chung này. Tuy nhiên việc Chrome thay đổi
cách cache tài nguyên của bên thứ ba, tác dụng này sẽ
không còn nữa (Safari thì áp dụng lâu rồi).
● Cloudflare API​ – chỉ dành cho người dùng của Cloudflare.
Nhập email, khóa API toàn cầu (global API key), và tên
miền. Bằng cách này, LSC sẽ purge (xóa) cache của
Cloudflare khi LSC purge cache. Chú thích của người dịch:
nếu bạn đã dùng CDN rồi thì không nên dùng Cloudflare
nữa vì như vậy sẽ là CDN 2 lần, tốn kém không cần thiết
hoặc không đem lại cải thiện có ý nghĩa về mặt tốc độ.

CDN > Manage

Phần này dùng để quản lý CDN của Cloudflare hoặc QUIC.cloud. Nếu
bạn không dùng thì không cần quan tâm. Để quản lý QUIC.cloud bạn
cần đăng ký tài khoản ở đây và thực hiện các tùy chọn trên đó.

● Cloudflare​ – tôi không động đến phần này.

20
 ● Development ​– đây là cách tiện lợi để bạn vô hiệu hóa
Cloudflare mà không cần phải đăng nhập và vã mồ hôi với
xác thực 2 yếu tố/2FA security (haha)
● Cloudflare Cache​ – cách tiện lợi để xóa (purge) cache của
Cloudflare (nhưng không xóa LSC cache của bạn), cũng có
ích khi bạn cập nhật một số ảnh hoặc tài nguyên nào khác
và muốn thay đổi này hiển thị ngay lập tức.

Image Optimization > Image Optimization Summary

Dịch vụ tối ưu hóa ảnh miễn phí của LiteSpeed thật tuyệt vời và dễ
dùng! Nó thực sự làm tôi kinh ngạc. Rất dễ sử dụng. Có đầy đủ tính
năng mà các plugin nén ảnh chất lượng hàng đầu hiện có. Và
LiteSpeed Cache làm công việc đó hoàn toàn MIỄN PHÍ!

● Gather Image Data / Send Optimization Request​ (thu

thập dữ liệu hình ảnh / gửi yêu cầu tối ưu hóa) – click vào
phần này để yêu cầu tối ưu hình ảnh miễn phí.
● Pull Images​ (kéo ảnh) – khi ảnh nén của bạn đã sẵn sàng,
click vào đây để tải chúng về trang web của bạn. (Ảnh gốc
của bạn sẽ được đưa vào thư mục backup; tôi đoán là nó
nằm ở đâu đó trong “wp-content/uploads”).
● Clean Up Unfinished Data​ (dọn dẹp dữ liệu chưa hoàn
thành) – click vào đây khi một số quá trình nén bị tắc
nghẽn và không bao giờ hoàn thành, sau đó bạn có thể gửi
các yêu cầu khác.
● Calculate Backups Disk Space​ (tính toán không gian dữ
liệu dùng vào việc backup) – công cụ tiện lợi này nói cho
bạn biết thư mục backup hiện chiếm bao nhiêu dung
lượng. Bạn có thể tải chúng xuống từ máy chủ của bạn về
máy tính cá nhân và xóa nó trên server để tiết kiệm không
gian.

21
 ● Remove Original Image Backups​ (loại bỏ ảnh backup
gốc) – chỉ làm điều này sau khi bạn backup sử dụng tùy
chọn trước đó.
● Rescan New Thumbnails​ (quét lại các thumbnails mới) –
nếu bạn thực hiện thay đổi với các ảnh đã tồn tại trước đó,
click vào đây để LSC nhận ra chúng.
● Use Original Files & Use Optimized Files​ (sử dụng file
gốc & sử dụng file đã được tối ưu hóa) – tính năng này
mới hay làm sao! Bạn có thể chuyển qua lại để thấy được
sự khác biệt. Hoặc nếu bạn muốn hoàn nguyên về như cũ
nhanh chóng. Nếu bạn muốn hoàn nguyên các ảnh cụ thể,
bạn có thể thực hiện điều đó từ thư mục media.
● Destroy All Optimization Data​ (phá hủy tất cả dữ liệu tối
ưu hóa) – trong trường hợp bạn không thích kết quả nén
của LSC và bạn muốn quay lại dùng các ảnh gốc.

Image Optimization > Image Optimization Settings

● Auto Request Cron – ​ để nó là ON nếu bạn muốn trang
của bạn tự động yêu cầu tối ưu hóa cho tất cả các ảnh mới
được thêm vào.
● Auto Pull Cron​ – để nó là ON nếu bạn muốn tự động tải
tất cả các ảnh đã tối ưu về trang của bạn. Tôi cho rằng tùy
chọn này và tùy chọn ngay bên trên nên để giống nhau
(cho dù là ON hay OFF).
● Optimize Original Images​ (tối ưu hóa các ảnh gốc và lưu
file backup trong cùng thư mục) – có lẽ nên để ON.
● Remove Original Backups​ (xóa ảnh backup gốc) – OFF
(tức là KHÔNG xóa) trừ khi bạn chắc chắn 100% rằng bạn
hài lòng với chất lượng ảnh mà bạn để LiteSpeed Cache
tối ưu. Khi tùy chọn này được bật nó sẽ tự động xóa ảnh
gốc của bạn sau khi tối ưu (và bạn không thể khôi phục lại
ảnh gốc được nữa).

22
● Optimize WebP Versions​ (tối ưu định dạng ảnh webp) –
tôi để nó OFF, nhưng bạn cứ thoải mái thử nghiệm với tùy
chọn ON nếu bạn có nhiều thời gian. PS: tùy chọn này
trong phiên bản mới nhất hiện không còn.
● Optimize Losslessly​ (tối ưu không mất chất lượng) – đây
là cách nén ảnh an toàn khi chất lượng ảnh không bị suy
giảm chút nào nhưng kích cỡ ảnh không giảm được nhiều.
Dù vậy các bức ảnh rất lớn sẽ vẫn nhận được một số lợi
ích nào đấy.
● Preserve EXIF data​ (giữ lại dữ liệu EXIF) – OFF, trừ khi
bạn cần thông tin này hoặc muốn hiển thị chúng trên giao
diện bên ngoài (frontend) thông qua plugin. EXIF là mấy
thông tin kiểu như ngày tháng, địa điểm chụp, loại
máy…thường được gắn kèm với ảnh chụp.
● Create WebP Versions​ (tạo ảnh định dạng webp) – cá
nhân tôi không sử dụng định dạng WebP nhưng nó thực
sự cho hệ số nén tốt và kích cỡ file ảnh nhỏ hơn so với
JPEG/PNG. Để nó là ON nếu bạn muốn. Nhược điểm nếu
bạn bật tùy chọn này có lẽ là trang của bạn sẽ phải tạo
nhiều ảnh hơn và chiếm không gian ổ cứng…hoặc ảnh
trên trang của bạn sẽ không dễ tải về để xem trên các thiết
bị khác (mà không hỗ trợ WebP).
● Image WebP Replacement​ (thay thế ảnh thông thường
bằng định dạng webp). Mặc định để OFF. Tôi cho rằng bạn
nên để tùy chọn này là ON nếu bạn có tạo định dạng ảnh
WebP ở tùy chọn trên.
● WebP Attribute To Replace​ (thay thế thuộc tính của
webp) – đây là cách hay để điều chỉnh các ảnh nào sẽ
được thay thế bằng định dạng WebP. Đây là cách khác để
giải quyết vấn đề lưu trữ của máy chủ nếu bạn muốn nhận
được lợi ích của WebP chỉ từ một số ảnh (chẳng hạn như
chỉ từ các ảnh thực sự lớn, và có thể là chúng sử dụng
hiệu ứng trong suốt?)

23
 ● WebP For Extra srcset​ – đây là cách hay để bạn kích
hoạt thay thế hình ảnh WebP cho các ảnh không được
quản lý thông qua thư viện đa phương tiện (media library)
của WordPress.
● WordPress Image Quality Control (​ kiểm soát chất lượng
ảnh WordPress) – sử dụng mặc định 82, hoặc kiểm tra các
tùy chọn cao hơn hoặc thấp hơn nếu bạn muốn.

Chú thích của người dịch: định dạng ảnh WebP rất thú vị, nó là định
dạng ảnh có dung lượng thấp nhất hiện nay khi so với ảnh JPG,
PNG,…với chất lượng tương đương. Tuy nhiên vấn đề của WebP là
nó không được hỗ trợ trên tất cả các trình duyệt, đặc biệt là Safari
(iPhone, MAC), do vậy người quản trị web phải sử dụng song song
hai định dạng và cần bổ sung mã phát hiện trình duyệt để đưa ra định
dạng ảnh thích hợp cho từng trình duyệt. Điều này sẽ tương đối rắc
rối khi triển khai trên NGINX, nhưng may cho chúng ta LiteSpeed
Cache lại làm điều này rất tốt. Cá nhân tôi ở thời điểm hiện tại không
mặn mà lắm với WebP dù ngày xưa bỏ công tìm hiểu nó rất nhiều
(nếu Safari cũng hỗ trợ WebP thì quan điểm của tôi sẽ khác) vì nó có
thể đem đến các rắc rối không lường trước được.

Tin mới: Safari đã bắt đầu hỗ trợ webp!

Page Optimization > CSS Settings

Phần đa các bạn sẽ nhận thấy nhiều tùy chọn thú vị trong mục này
này đã có ở plugin caching/tối ưu hóa khác rồi. Lời khuyên của tôi là
hãy cẩn thận! hầu hết các vấn đề liên quan đến caching có nguyên
nhân từ những lựa chọn này.

Vì một số lý do, trong đa số trường hợp các bạn không nên tối thiểu
hóa/rút gọn (minifying) hoặc kết hợp (combining) các file CSS/JS.
Minifying làm máy chủ phải hoạt động nhiều hơn và làm chậm lượt

24
ghé thăm đầu (initial visit). Nó sẽ tốt nếu bạn có rất nhiều người truy
cập.

Nhưng nếu bạn vẫn muốn rút gọn mã thì đừng dùng tính năng có sẵn
trong plugin này…tốt hơn là thực hiện điều đó thông qua Cloudflare
hoặc CDN khác- vốn đã được xử lý trên máy chủ của họ ở cấp độ
DNS. Nếu trang của bạn đã gọn gàng rồi (lean already), rút gọn sẽ
không đem lại ảnh hưởng tích cực nào đáng chú ý cả. Kết hợp CSS
hoặc JS thực sự không nên làm bởi vì nó thường gây ra lỗi và cũng
chẳng đem lại khả năng cải thiện tốc độ đáng kể.

PS​: bạn nào muốn tham khảo tài liệu chính thức của LiteSpeed về
phần Page Optimization thì tham khảo bài này.

● CSS Minify​ (tối thiểu hóa CSS) – OFF. Sử dụng Cloudflare

hoặc từ dịch vụ CDN nếu bạn muốn.
● CSS Combine​ (kết hợp CSS) – OFF là an toàn nhất. Nếu
bạn muốn bật, hãy kiểm tra cẩn thận!
● CSS HTTP/2 Push​ – OFF là an toàn nhất, dù bạn có để
ON nó cũng không tạo ra nhiều khác biệt trên đa số các
trang.
● Load CSS Asynchronously​ – để nó là OFF nếu không
bạn sẽ gặp vấn đề FOUC. Để ON chắc chắn sẽ giúp bạn
cải thiện điểm số Pingdom/GTmetrix nhưng sẽ gây ảnh
hưởng xấu đến trải nghiệm người dùng.
● Generate Critical CSS​ – OFF! tôi chẳng hào hứng gì với
critical CSS.
● Generate Critical CSS In Background​ – tùy thuộc vào
phần trên bạn chọn là gì, hai cái nên để giống nhau.
● Separate CCSS Cache Post Types​ – nếu sử dụng critical
CSS, bạn nên liệt kê tất cả các kiểu post mà nó có thiết kế
và CSS riêng (ví dụ tốt đó là trang sản phẩm, thư mục của
WooCommerce, trang kèm bảng giá, vân vân).

25
 ● Separate CCSS Cache URIs​ – được sử dụng tương tự
tùy chọn trước nhưng cho các URL riêng lẻ. Có thể được
dùng cho bất kỳ trang cụ thể nào sử dụng CSS khác từ
trang khác.
● Inline CSS Async Lib​ – OFF! CSS thực chất nên chặn
hiển thị (render-blocking) nếu không bạn sẽ gặp các vấn đề
về FOUC.
● Font Display Optimization​ (tối ưu hóa hiển thị font) –
dưới quan điểm về giao diện người dùng của tôi, bạn chỉ
nên sử dụng Default hoặc Block. Không bao giờ nên dùng
Swap hoặc Fallback, vì chúng là nguyên nhân gây ra vấn
đề FOUT!

Page Optimization > JS Settings

● JS Minify​ (giảm thiểu JS) – OFF. Sử dụng Cloudflare hoặc
từ CDN của bạn nếu bạn thích tính năng này.
● JS combine​ (kết hợp JS) – để OFF là an toàn nhất. Nếu
bạn muốn bật, hãy kiểm tra cẩn thận!
● JS HTTP/2 Push​ – để OFF là an toàn nhất, để ON cũng
không tạo ra nhiều khác biệt với hầu hết website.
● Load JS Deferred​ – OFF là an toàn nhất. Một số JS cần
dùng cho các tài nguyên quan trọng trên màn hình đầu tiên
và không nên defer.
● Load Inline JS​ – để như MẶC ĐỊNH là an toàn nhất. Defer
hoặc trì hoãn cho đến khi DOM tải xong có thể giúp cải
thiện điểm số trang hoặc giúp các JS được tối ưu hóa khác
hoạt động bình thường…nhưng nó cũng có thể làm thay
đổi thiết kế hoặc chức năng của website.
● Exclude JQuery​ – ON là an toàn nhất. Bạn có thể để là
OFF (cho phép trình tối ưu hóa JS áp dụng với cả thư viện

26
 jQuery) nếu bạn kiểm tra cẩn thận và thấy website không
gặp vấn đề gì.

Page Optimization > Optimization Settings

● CSS/JS Cache TTL​ – để như mặc định là đủ an toàn. Sử
dụng quãng thời gian ngắn hơn nếu bạn thực hiện nhiều
thay đổi. Hoặc dài hơn nếu bạn ít thay đổi thiết kế.
● HTML Minify​ – OFF. Thực hiện điều này thông qua
Cloudflare hoặc CDN nếu bạn muốn.
● Inline CSS Minify​ – OFF. Không tạo ra nhiều khác biệt.
● Inline JS Minify –​ OFF. Không tạo ra nhiều khác biệt.
● DNS Prefetch​ – mẹo hay để preloading DNS cho các tên
miền bên ngoài, vì thế chúng có thể tải nhanh hơn khi bạn
click vào URL hoặc khi trang của bạn tải các tài nguyên
bên ngoài từ chúng. Bạn không biết đặt cái gì vào? Đơn
giản là mở trang web của bạn trong Chrome Incognito >
Inspect > Sources…giờ gõ tất cả các nguồn là tên miền
bên ngoài mà bạn thấy. Tất cả Google Analytics và các lời
gọi font, tài nguyên mạng xã hội, dịch vụ chat, CDN, vân
vân.
● DNS Prefetch Control​ – tự động tìm nạp trước (prefetch)
tất cả tên miền được gọi từ CSS và JS. Tôi thấy đây cũng
là ý tưởng hay nhưng không cần thiết nếu tôi đã thực hiện
gọi chúng bằng cách nhập thủ công tên miền từ tùy chọn
bên trên.
● Remove Comments​ (loại bỏ các chú thích trong file
CSS/JS) – Để OFF tôi thấy an toàn hơn. Đằng nào thì nó
cũng không tạo ra sự khác biệt đáng kể nào về tốc độ.
Trong khi nó chủ yếu được dùng để giúp bạn cải thiện
điểm số hư ảo Pingdom/GTmetrix.
● Remove Query Strings​ – theo quan điểm của tôi, nó
không đem lại cải thiện nào về tốc độ khi bạn bật tính năng

27
 này (hiện tại caching hầu như có thể xử lý chuỗi truy vấn).
Hầu hết mọi người bật nó để có được điểm số kiểm tra tốt
hơn. Tôi khuyên bạn nên để là OFF nếu bạn vẫn đang điều
chỉnh thiết kế, nếu không bạn sẽ gặp phải vấn đề CSS/JS
cũ.
● Load Google Fonts Asynchronously​ (tải Google Font
theo kiểu không đồng bộ) – bạn hãy kiểm tra cẩn thận. Tôi
không thấy sự khác biệt đáng kể nào bởi vì tôi đoán rằng
hầu hết các font Google phổ biến đã được cache sẵn trong
trình duyệt của người dùng rồi khi họ ghé thăm các trang
web khác.
● Remove Google Fonts​ (loại bỏ Google Fonts) – tôi có
chút khó hiểu tại sao tùy chọn này lại tồn tại. Thông qua tài
liệu chính thức của LS thì nó dành cho những ai đã có sẵn
font tải từ host cục bộ và muốn chắc chắn tránh được bất
kỳ lời gọi Google font bên ngoài nào. Nhưng một lần nữa,
tôi nghĩ bất cứ ai có đủ kỹ năng để tải font theo kiểu cục bộ
thì cũng dễ dàng loại bỏ được lời gọi Google font.
● Remove WordPress Emoji​ (loại bỏ biểu tượng mặt cười,
mặt khóc trong WordPress) – an toàn thì bạn để nó là ON.
Nó sẽ loại trừ các lời gọi emoji JS, cái không cần thiết vào
thời điểm hiện tại vì các trình duyệt hiện đại có thể tự nó
render emoji.

Page Optimization > Media Settings

● Lazy Load Images​ – tải các ảnh chỉ khi trình duyệt cuộn
chuột đến gần chúng. Tôi (Johnny) thích để là OFF vì tôi
ghét lazyload. (Cá nhân người dịch thì vẫn thích lazy load,
và áp dụng nó trên hầu hết các blog, chỉ các trang thương
mại điện tử thì tôi không dùng. Riêng lazy load ảnh tôi thích
dùng plugin Fying Images hơn, nó cho phép điều chỉnh

28
 ngưỡng kích hoạt lên đến 3000px, giúp giảm ảnh hưởng
tối đa đến trải nghiệm người dùng).
● Basic Image Placeholder​ – đây là ảnh mà người dùng
thấy trước khi ảnh thực được tải về. Thường sử dụng ảnh
base64.
● Responsive Placeholder​ – tôi khuyến nghị để là ON nếu
bạn sử dụng lazy load ảnh. Nó chiếm giữ không gian cho
các ảnh vì thế layout không nhảy, dịch chuyển khi người
dùng cuộn chuột. Nhưng những người bật quảng cáo có
thể thích để OFF hơn vì người dùng của họ có khả năng
bấm nhầm vào quảng cáo!
● Responsive Placeholder SVG​ – ảnh SVG được dùng làm
ảnh giữ chỗ cho bạn.
● Responsive Placeholder Color​ – có lẽ là màu xám hoặc
cái gì đó không nhiễu. Chỉ cần đủ để người dùng của bạn
biết cái sẽ đó sắp xuất hiện.
● LQIP Cloud Generator​ – công nghệ ảnh chiếm chỗ nâng
cao hiển thị phiên bản ảnh chất lượng rất thấp của ảnh
(​LQIP​)-cái mà sẽ được thay thế bằng ảnh chất lượng cao
khi người dùng cuộn chuột xuống dưới. Nó rất hữu ích
trong việc giúp các trang nặng ảnh tải nhanh hơn và giúp
giảm sự phân tán của người đọc khi áp dụng lazy load
ảnh.
● LQIP Quality​ – sử dụng thiết lập mặc định là 4 hoặc bạn
kiểm tra các cài đặt khác xem có tốt hơn không.
● Generate LQIP In Background​ – bạn cần phải kiểm tra cả
khi ON và OFF trên trang không được cache để xem nó sẽ
cho ra kết quả như thế nào. ON có lẽ là lựa chọn an toàn
hơn.
● Lazy Load Iframes​ – ý tưởng tốt nếu bạn có iframe hoặc
video được nhúng dưới màn hình đầu tiên.
● Inline Lazy Load Images Library​ (nội tuyến thư viện Lazy
Load ảnh) – tôi để nó là OFF (tôi cảm thấy cách này cho
hiệu suất tốt hơn). Bạn có thể bật ON nếu bạn muốn loại

29
 bỏ yêu cầu HTTP cho mục đích cải thiện điểm số hoặc nếu
trang của bạn được thiết kế rất gọn gàng.

Page Optimization > Media Excludes

● Lazy Load Image Excludes​ (loại trừ ảnh không cần lazy
load) – loại trừ bất kỳ ảnh nào để nó không cần lazy load
nữa. Có thể là ý tưởng tốt cho các ảnh ATF (ảnh nằm
trong màn hình đầu tiên ví dụ logo, các ảnh slide đầu bài)
hoặc những trang mà người dùng cuộn chuột nhanh (quick
scrolles).
● Lazy Load Image Class Name Excludes​ (loại trừ ảnh để
nó không cần lazy load dựa trên tên class của ảnh) – một
cách thông minh để loại trừ ảnh không cần lazy-load nữa
bằng cách liệt kê tên class CSS của nó ở đây.
● Lazy Load Image Parent Class Name Excludes​ (loại trừ
ảnh để nó không cần lazy load dựa trên tên class cha của
ảnh) – cách thông minh để loại trừ ảnh không cần lazy load
mà không có class đính kèm. Thay vì thế bạn loại trừ bằng
cách sử dụng class cha của chúng.
● Lazy Load Iframe Class Name Excludes​ – đây là cách
hay để loại trừ video nào đó để nó không cần lazy load
(chẳng hạn cái ở gần phần đầu của trang). Hoặc cái mất
nhiều thời gian để tải và bạn không muốn nó bị trì hoãn.
● Lazy Load Iframe Parent Class Name Excludes​ – đây là
cách tiện lợi để loại trừ các iframe không có class CSS
đính kèm. Tương tự như mẹo với ảnh.
● Lazy Load URI Excludes​ – cách thức hay để vô hiệu hóa
chức năng lazy load trên một số trang. Chẳng hạn với
trang landing page nào đấy mà bạn muốn ảnh và video tải
càng sớm càng tốt (ASAP/As Soon As Possible).

30
Page Optimization > Discussion Settings
● Gravatar Cache​ – đây là tính năng tuyệt vời cho các trang
có hàng trăm bình luận. Nhưng không cần thiết (và quan
điểm cá nhân tôi là không nên dùng) nếu phần lớn bài viết
trên trang của bạn không có nhiều bình luận và/hoặc không
có nhiều lượt truy cập. Chú thích của người dịch: riêng
trong bối cảnh internet Việt Nam thường xuyên đứt cáp
kéo dài việc kéo ảnh về host của bạn sẽ giúp tăng tốc
tương đối tốt, ngay cả khi trang có ít bình luận.
● Gravatar Cache Cron​ – nếu bạn bật caching Gravatar thì
bạn cũng nên để cái này là ON.
● Gravatar Cache TTL​ – mặc định là 1 tuần cũng ổn nhưng
tôi thích để nó là 3 tháng hơn. Tôi cảm thấy mọi người ít
khi thay đổi Gravatar của họ.

Chú thích của người dịch: Gravatar là ảnh đại diện được dùng mỗi khi
họ để lại bình luận trên WordPress (sử dụng email để biết). Avatar
này ở Việt Nam chủ yếu có ở anh em biết một chút về công nghệ. Chị
em hầu như chẳng bao giờ dùng, vì sẽ phải đăng ký trên
gravatar.com​. Những trang có nhiều bình luận và bạn thích bố cục
đẹp mắt, có thể dùng plugin wpDiscuz​.

Page Optimization > Tuning Settings

● Combined CSS Priority​ – thường để là OFF và không
nên áp dụng trừ khi bạn cần sử dụng cả “kết hợp CSS” và
“không kết hợp CSS” (tạo bởi việc loại trừ kết hợp một số
CSS). Khi bật (ON) tính năng này sẽ tải “CSS kết hợp /
Combined CSS” trước khi tải “CSS không kết hợp /
Uncombined CSS” thay vì để như mặc định (sẽ ngược lại).
Cái này tùy thuộc vào bạn xem kịch bản nào là phù hợp
nhất. Nhìn chung chúng ta muốn tải critical CSS trước rồi

31
 mới tải CSS khác sau. Nhưng có những thời điểm chúng ta
có các lớp CSS chồng chéo nhau và muốn đảm bảo rằng
layer cuối cùng tải về phải chính xác để tránh bất kỳ kiểu
định dạng không mong muốn nào. Điều này hoàn toàn phụ
thuộc vào chiến lược của bạn để tự quyết xem có nên sử
dụng cả “CSS kết hợp” và “không kết hợp” hay không. Từ
đó quyết định xem CSS nào nên kết hợp hoặc không, và
cuối cùng tính toán xem nên tải “CSS kết hợp” trước hay là
tải “CSS không kết hợp” trước.
● CSS Excludes​ – liệt kê tất cả các file CSS mà bạn không
muốn rút gọn hoặc kết hợp. Bạn có thể liệt kê tên đầy đủ
của chúng (chẳng hạn “elementor-builder.css”) hoặc một
phần tên (ví dụ “elementor”).
● Combined JS Priority​ – chức năng tương tự cái ở trên
đầu nhưng là cho JS.
● JS Excludes​ – liệt kê tất cả các file JS mà bạn không
muốn rút gọn/kết hợp
● Max Combined File Size​ – tôi chắc rằng phần cài đặt này
có các sắc thái khác nhau. Về mặt cá nhân tôi không thích
kết hợp CSS hoặc JS chút nào. Nhưng nếu bạn có làm,
cách an toàn nhất là kết hợp tất cả vào một file. Nhưng nếu
bạn muốn tiến hành sâu hơn nữa, bạn có thể giảm kích cỡ
tối đa và cắt nó thành nhiều phần nhỏ hơn để xem xem liệu
trình duyệt có xử lý nó nhanh hơn hay không. Tôi cho rằng
nó có thể hữu ích trên các thiết bị cấu hình yếu hoặc tốc độ
kết nối internet chậm chạp.
● Critical CSS Rules​ – nếu bạn sử dụng tính năng “Load
CSS asynchronously / Tải CSS không đồng bộ”, copy
paste bất cứ quy tắc critical CSS nào vào đây để đảm bảo
rằng chúng được tải trước tiên. Chú thích của người dịch:
tính năng này rất giống với critical CSS miễn phí trên
plugin Autoptimize, bạn có thể sử dụng trang này​ để lấy
được critical CSS của trang.

32
 ● JS Deferred Excludes​ – nếu sử dụng tính năng “Load JS
Deferred / Trì hoãn tải JS”, bạn có thể loại trừ bất kỳ JS cụ
thể nào ở đây để giữ chúng tải như bình thường (ý tưởng
tốt là cho bất cứ file JS nào dùng để render nội dung quan
trọng).
● URI Excludes​ – liệt kê bất cứ URL nào ở đây mà bạn
muốn loại trừ không cần tối ưu hóa trang. Ý tưởng tốt là liệt
kê các trang bị hỏng thiết kế hoặc chức năng gây ra bởi
các tối ưu hóa đó.
● Role Excludes​ – bạn có thể loại trừ tối ưu hóa cho những
người dùng cụ thể nào đó đã đăng nhập. Bạn có khả năng
không bao giờ sử dụng tính năng này ngoại trừ khi cần
dùng vào một số mục đích thử nghiệm, kiểm tra nhất định.

Database > Manage

Phần này gồm các công cụ tối ưu hóa và làm sạch cơ sở dữ liệu có
chất lượng rất tốt (incredible). Một số thậm chí có thể tách riêng ra
đem bán được. Có vài ý kiến đóng góp của tôi đã được LiteSpeed ghi
nhận triển khai. <3

● Clean All​ (làm sạch tất cả) – thực hiện tất cả công việc tối
ưu hóa trong danh sách.
● Post Revisions​ – xóa tất cả post revisions.
● Auto Drafts​ – bạn cần kiểm tra trước khi xóa các bản
nháp này.
● Trashed Posts​ – bạn cần kiểm tra trước khi xóa các bài
trong thùng rác.
● Spam Comments​ – xóa các bình luận spam, đôi khi bình
luận thông thường cũng bị đưa vào đây, nếu cẩn thận thì
bạn nên kiểm tra trước khi xóa.
● Trashed Comments​ (bình luận trong thùng rác) – cái tên
đã nói lên tất cả (self-explanatory).

33
 ● Trackbacks/Pingbacks​ – xóa được.
● Expired Transients​ – đủ an toàn để xóa .
● Optimize Tables​ (tối ưu hóa bảng) – không cần lăn tăn.
● Clean CSS/JS Optimizer​ – không cần lăn tăn.
● Database Table Engine Converter > Convert to InnoDB
– ổn cả, bạn nên làm điều này cho tất cả các bảng! InnoDB
là định dạng bảng MySQL tốt hơn so với dạng cũ MyISAM.
● Database Summary​ (tổng quan về cơ sở dữ liệu) – tôi rất
thích xem thông tin những gì đang tự động tải trên trang
của tôi. Bạn nên giữ tổng dung lượng tự động tải dưới
1MB, tốt nhất là dưới 500KB.

Database > DB Optimization Settings

● Revisions Max Number​ (số lượng revisions tối đa) – thiết
lập giới hạn nếu database của bạn quá lớn và bạn có
nhiều bài post. Cá nhân tôi để nó là 0 để trang web được
gọn gàng, sạch sẽ. Nhưng các trang khác thận trọng hơn
có thể để từ 10 đến 50.
● Revisions Max Age​ (tuổi tối đa của revision) – bạn có thể
thiết lập để nó tự động xóa các revision sau một khoảng
thời gian nhất định. Cá nhân tôi nghĩ điều này thật đáng sợ
khi bài post của bạn gặp vấn đề và bạn không để ý đến nó
suốt một thời gian dài.

Crawler > Summary

PS: Ngoài phần hướng dẫn bên dưới của Johnny Nguyen, bạn có thể
đọc tài liệu về Crawler từ chính chủ LiteSpeed, link ở đây.

Phần này sẽ không có nhiều hiệu quả trừ khi bạn có máy chủ của
riêng mình, phần lớn công ty host cài LiteSpeed không cho phép tùy

34
chọn crawler (vì nó có thể chiếm dụng một lượng lớn tài nguyên). Bạn
không cần phải mó máy (mess) bất cứ điều gì ở đây trừ khi bạn muốn
crawler tạo trước cache (precache) tích cực hơn. Và bây giờ, có rất
nhiều tùy chọn tích cực! Bạn có thể tăng tần số crawl (quét, thu thập
dữ liệu) hoặc thread-use, thậm chí là precrawl cho các cookies và
người dùng đã đăng nhập, vân vân.

PS: cá nhân người dịch từng dùng host ở Closte, có chất lượng rất
ổn, nhưng họ cũng không bật tính năng này.

Nếu bạn tự cài LiteSpeed/OpenLiteSpeed chẳng hạn trên

DigitalOcean hoặc Vultr, tính năng này sẽ được mở theo mặc định.

● Summary > Reset position​ – reset nó nếu bạn muốn bắt

đầu lại từ đầu, giống như sau khi bạn xóa cache.
● Summary > Manually run​ – khởi động lại thủ công crawler
thay vì đợi cho đến khi cron job kế tiếp chạy.
● Map > Clean Crawler Map​ – một crawler map giống như
một sitemap cho crawler (trình thu thập dữ liệu) của bạn.
Bạn có thể xóa nó bất cứ khi nào bạn muốn để tạo ra cái
mới (chẳng hạn sau khi các trang mới được thêm vào).
● Map > Refresh Crawler Map​ – có thể là ý tưởng hay khi
refresh lại cái này sau khi trang thay đổi hoặc sau khi bạn
reset “cleaned” crawler map. Sau đó bạn có thể xem các
trang nào đã được crawled hoặc không, cũng như thêm
vào blacklist để ngăn các trang không được tự động crawl.
● Blacklist > Empty blacklist​ – xóa sạch blacklist của bạn
nếu cần thiết.

Crawler > General Settings

● Crawler​ – bật nó nếu bạn muốn xây dựng cache tự động.
Cái này cần sử dụng tài nguyên vì thế có thể không phải là

35
 ý hay nếu bạn dùng trên máy chủ bận rộn mà nhiều
website không phải của bạn (làm ảnh hưởng đến người
khác). Tất nhiên, nếu đó là máy chủ của bạn và chạy các
website của bạn thì bạn nên bật nó để sử dụng nhiều tài
nguyên nhất có thể!
● Delay​ – mặc định là ổn rồi. Cái này chỉ cần điều chỉnh nếu
bạn có trên 30 ngàn trang trên toàn máy chủ!
● Run Duration​ – giá trị mặc định cũng ổn nhưng bạn có thể
tăng nó lên cho các trang quan trọng.
● Interval Between Runs​ – giá trị mặc định cũng ổn nhưng
bạn có thể giảm nó cho các trang quan trọng hoặc/và máy
chủ rảnh rỗi.
● Crawl Interval​ – giá trị khuyến nghị là 302400 (3,5 ngày)
hoàn toàn ổn nhưng bạn có thể tăng nó lên thành 86400 (1
ngày) nếu trang web của bạn không quá lớn (dưới 3K
trang) hoặc bạn đang dùng máy chủ riêng.
● Threads​ – giá trị mặc định 3 là ổn. Thiết lập giá trị crawl
cao hơn sẽ nhanh hơn nhưng để như mặc định cũng
không thành vấn đề trừ khi bạn có ít nhất vài trăm page.
Nó cũng sử dụng nhiều CPU hơn vì thế đừng thiết lập chỉ
số này cao quá nếu bạn có máy chủ bận rộn với nhiều
website.
● Server IP​ – chức năng thực sự thú vị giúp giảm công sức
crawl. Thực sự hữu ích nếu bạn có trên 1K trang.
● Server Load Limit​ – giá trị khuyến nghị 1 là giới hạn an
toàn tốt. Nhưng tôi thích để nó là 2 hoặc 3 nếu bạn đang
có máy chủ riêng (ý là không phải sharehost).

Crawler > Simulation Settings

36
Phần này chỉ cần nếu bạn muốn crawl trước các trang cho người
dùng đã đăng nhập (chức năng crawl thông thường đã bao gồm
người dùng không đăng nhập).

● Role Simulation​ – tạo cache trước cho các trang ứng với
người dùng cụ thể.
● Cookie Simulation​ – crawl trước cho các cookies cụ thể.

Crawler > Sitemap Settings

● Custom Sitemap​ – LSC có thể crawl trước website của
bạn tự động nhưng tôi thích nhập vào sitemap với các
website lớn hoặc có nhiều kiểu bài post, cần phải đảm bảo
là nó không phí thời gian cho các url không quan trọng.
Bạn có thể sử dụng sitemap của riêng bạn chẳng hạn như
cái được tạo từ plugin XML sitemap. Hoặc có thể nếu bạn
muốn sử dụng crawler sitemap riêng (chẳng hạn như loại
trừ một số mục nhất định không cần pre-crawl).
● Drop Domain from Sitemap​ – cứ để nó là ON trừ khi bạn
có nhiều tên miền trong sitemap (chẳng hạn như multisite,
multi-lingual).
● Include Posts/Pages/Cats/Tags​ – thường bạn nên để là
ON, trừ khi bạn muốn loại trừ một số mục có lưu lượng
truy cập thấp không cần crawling trước.
● Exclude Custom Post Types​ – phần này bao gồm các
mục mà bạn không muốn đưa vào trong sitemap của bạn.
Bạn nên loại trừ tất cả liên kết mà bình thường URL của
chúng không được truy cập trực tiếp. Lấy ví dụ, nếu bạn có
trang “FAQs / Các câu hỏi thường gặp” nhưng nó thường
được duyệt qua các trang khác, thế thì bạn có thể loại trừ
chúng ở đây. Ý tưởng ở đây là loại bỏ càng nhiều link khỏi
sitemap thì càng tốt để các crawler (như LSC hoặc Google)

37
 có thể tập trung vào các nội dung có lưu lượng truy cập
cao hơn.
● Order links by​ – “Date, descending / Ngày, giảm dần” là
cái có hữu ích nhất đối với tôi trừ khi trong một số trường
hợp mà nội dung cũ lại có giá trị hơn, hoặc nội dung của
bạn được sắp xếp theo bảng chữ cái abc.

Toolbox > Purge

Tôi thích khu vực này vì nó có các tùy chọn purge chuyên sâu; nó có
khả năng lựa chọn purging tinh tế vì thế bạn không làm quá tải trên
các máy chủ có lưu lượng truy cập cao (khi hàng ngàn người dùng sẽ
truy cập vào các trang chưa được cache). Nhưng trên đa số website
tôi không bao giờ dùng tính năng này. Tôi đơn giản là purge mọi thứ
một lần.

● Tất cả các tùy chọn ở đây đều đã tự giải thích ý nghĩa của
nó khi bạn chỉ cần nhìn vào tên của chúng.
● Những cái đáng chú ý có lẽ là pages, CSS/JS, và Opcode
cache. Đây là những thứ phổ biến nhất mà các trang web
lớn hay purging hàng ngày (day-to-day).
● Lưu ý thêm: nếu bạn có ý định cấu hình trang của bạn chỉ
để purging thủ công, đừng quên vô hiệu hóa các quy tắc
purge tự động trong mục cache!

Toolbox > Import/Export

Đây là khu vực tiện lợi cho việc kiểm tra và lưu các cấu hình khác
nhau mà bạn có. Tôi có sử dụng nó không? Không, bởi vì tôi đã cấu
hình LSC trên hàng trăm website nên thạo lắm rồi.

38
Một câu hỏi mà tôi được hỏi rất nhiều là bạn có thể lưu một cấu hình
chung và nhập nó vào tất cả các trang web của bạn? Bạn có thể
nhưng chỉ cho các cấu hình không có nhu cầu tùy chỉnh riêng. Tôi
không bao giờ sử dụng nó, tôi thích cài đặt thủ công để đảm bảo chắc
chắn.

● Export​ – lưu tất cả các cài đặt thành file LSC tiện lợi
● Import –​ nhập cài đặt từ file cài đặt LSC.
● Reset Settings​ – resets tất cả các cài đặt LSC về mặc
định.

Toolbox > Edit .htaccess

Tôi thích tính năng này. Rất tiện lợi để xem và sửa nhanh file .htacess
mà không cần phải vào máy chủ thông qua FTP. Thực sự hữu ích khi
muốn xử lý sự cố hoặc khi bạn muốn dọn dẹp hoặc chỉnh sửa
.htaccess​.

● .htaccess Path Settings​ – tự động phát hiện nên hoạt

động tốt. Chỉ định đường dẫn thường không cần thiết trừ
khi website của bạn nằm trong một số thư mục không tiêu
chuẩn hoặc đang dùng tên file .htaccess không chuẩn.
● Current .htaccess Contents​ – hãy sử dụng nó cẩn thận!

Toolbox > Heartbeat Control

Trước khi bạn máy mó mày mò với heartbeat controls trong
WordPress, bạn cần phải hiểu nó được dùng vào việc gì đã.
WordPress heartbeat là lời gọi AJAX sử dụng file
“/wp-admin/admin-ajax.php”. Hầu hết các trang không bao giờ phải tối

39
ưu hóa cái này trừ khi nó gây ra vấn đề sử dụng CPU cao (nhìn thấy
các lời gọi admin-ajax.php chậm từ waterfalls khi kiểm tra tốc độ).

Trong trường hợp bạn cần tối ưu hóa nó, hãy cẩn trọng về cách thực
hiện. Bạn không nên vô hiệu hóa nó hoàn toàn trừ khi các lời gọi
không cần thiết đến từ một số plugin cồng kềnh. Thường thì, chúng ta
tối ưu hóa tăng tần số ở những nơi nó được dùng và vô hiệu hóa nó
từ các trang không sử dụng.

Hai trường hợp sử dụng phổ biến nhất cho heartbeat là (A) các bài
viết tự động lưu trong khi bạn biên tập và (B) cập nhật số lượng hàng
trong giỏ ở WooCommerce khi mọi người thêm/bớt sản phẩm. Có rất
nhiều trường hợp sử dụng khác nữa nhưng nó sẽ thay đổi từ trang
này sang trang khác phụ thuộc vào plugin nào được sử dụng. Bạn chỉ
cần cẩn thận trước khi vô hiệu hóa nó!

● Frontend Heartbeat Control​ – để nó là ON nếu bạn muốn

thay đổi interval.
● Frontend Heartbeat TTL​ – có thể nhân đôi lên thành 120
giây nếu nó vẫn được dùng trên frontend hoặc thiết lập là 0
để vô hiệu hóa.
● Backend Heart Control​ – bật nó là ON nếu bạn muốn
thay đổi interval.
● Backend Heartbeat TTL​ – thường thì backend đủ an toàn
để vô hiệu hóa hoàn toàn heartbeat vì phần lớn chức năng
không dựa vào nó.
● Editor Heartbeat​ – tôi đặc biệt khuyến cáo bạn nên để nó
là OFF vì WordPress sử dụng nó để tự động lưu công việc
của bạn. Nếu chẳng may internet của bạn bị cắt đột ngột
hoặc bạn chẳng may đóng trang, vân vân…công việc của
bạn sẽ vẫn được lưu.

40
 ● Editor Heartbeat TTL​ – bạn có thể gia tăng interval nếu
bạn có nhiều người viết trên trang cùng một lúc, nhưng
đừng bao giờ vô hiệu hóa nó!

Toolbox > Report

● Install DoLogin Security​ – plugin hữu ích cho phép người
khác truy cập vào WP-admin sử dụng liên kết tạm thời
(thay cho việc sử dụng đăng nhập user/pass).
● LiteSpeed Report​ – hữu ích cho việc gửi thông tin đến
trung tâm hỗ trợ chính chức của LS.
● Passwordless Link​ – tạo ra liên kết đăng nhập tự động
cho WP-admin. Yêu cầu cài plugin bảo mật DoLogin đề
cập ở trên.
● Notes​ – đưa thêm vào bất cứ thông tin hữu ích nào.
Chẳng hạn bạn làm gì, bạn thay đổi cái gì, bạn thấy vấn đề
ở đâu và cách để tạo lại nó.
● Send to LiteSpeed​ – gửi báo cáo cho LiteSpeed. Sau đó
bạn trích dẫn số của báo cáo trong diễn đàn hỗ trợ hoặc
bất cứ chỗ nào mà bạn tạo ra được yêu cầu hỗ trợ.

Toolbox > Debug

Bạn không nên thay đổi bất cứ điều gì ở đây trừ khi bạn đang
debugging (gỡ lỗi) vấn đề với trang của bạn. Thành thật mà nói, tôi
chưa bao giờ phải sử dụng nó vì hầu hết các vấn đề liên quan đến
caching tôi có thể sửa chữa dễ dàng.

● Disable All Features​ – chỉ để nó là ON khi bạn gỡ lỗi vấn

đề.

41
 ● Debug Log​ – để nó là ON chỉ khi bạn gỡ lỗi. Sử dụng tùy
chọn Admin IP nếu bạn có rất nhiều lưu lượng truy cập
khiến cho debug log quá lớn.
● Admin IPs​ – nhập vào IP ngoài của bạn để chạy debug từ
trình duyệt.
● Debug Level​ – lựa chọn Basic hoặc Advanced tùy thuộc
vào nhu cầu của bạn.
● Log File Size Limit​ – tăng chỉ khi bạn cần nó.
● Log Cookies​ – để ON nếu cần thiết.
● Collapse Query Strings​ – để ON nếu cần.
● Debug URI Includes​ – nhật ký trên các trang được liệt kê.
Hữu ích nếu bạn chỉ có một số vấn đề trên một trang cụ
thể nào đó.
● Debug URI Excludes​ – lợi trừ các trang khỏi debug log
của bạn.

Toolbox > Log View

● [D] Clear Log​ – xóa log.
● Clear Log​ – xóa log.

Toolbox > Beta Test

Đây là tùy chọn hữu ích nếu bạn muốn kiểm tra các phiên bản khác
nhau của LiteSpeed Cache (tốt nhất là trên trang staging) và chuyển
đổi qua lại giữa BETA và các phiên bản ỔN ĐỊNH. Tôi nghĩ nó cũng
có thể hữu ích cho việc quay trở lại phiên bản trước đó nếu phiên bản
mới gặp vấn đề.

● Use latest GitHub commit​ – click vào để thử phiên bản

mới nhất trên GitHub.

42
 ● Use latest WordPress release version​ – click vào để sử
dụng phiên bản ỔN ĐỊNH nhất của LSC.

Bước 3 – Kiểm tra xem LiteSpeed Cache có hoạt

động bình thường hay không?
1. Mở trang web của bạn trên trình duyệt bất kỳ (không đăng
nhập)
2. Tải và tải lại một vài trang.
3. Sau đó xem mã nguồn, cuộn chuột xuống dưới cuối và
xem xem liệu LiteSpeed Cache có để lại chú thích không.

Chú thích của nó sẽ có kiểu như thế này (chỉ cache):

<!-- Page generated by LiteSpeed Cache 3.2.4 on 2020-07-24 18:13:20 -->

Hoặc thế này (cache và rút gọn HTML):

<!-- Page optimized by LiteSpeed Cache @2020-07-22 13:17:33 -->

<!-- Page generated by LiteSpeed Cache 3.2.4 on 2020-07-22 20:17:33 -->

Trong đó 3.2.4 là phiên bản của plugin, còn đoạn đằng sau là ngày
giờ nó tạo cache.

Đương nhiên, trang có thể chậm đôi chút với lần ghé thăm lần đầu
tiên nhưng phải phải nhanh thấy rõ với các lần truy cập tiếp theo.

Bước 4 – Giải quyết lỗi

● LiteSpeed cache comment not showing​ (không hiển thị
chú thích của LiteSpeed) – có thể vì LSC không hoạt động

43
 hoặc bạn đang bật đang bật tính năng loại bỏ chú thích
HTML của Cloudflare.
● CSS trì hoãn gặp vấn đề (FOUC hoặc FOUT) – bạn
không sử dụng critical CSS và đừng kết hợp các file CSS
nữa!
● Broken visuals or functions​ (hỏng giao diện hoặc chức
năng) – thử thôi không kết hợp CSS hoặc JS. Hoặc bạn có
thể sử dụng các bước chuẩn đoán mà tôi trình bày dưới
đây để phát hiện và loại trừ CSS/JS có vấn đề.
● Contact forms not working​ (form liên hệ không hoạt
động) – nếu form liên hệ của bạn không hoạt động cách
sửa đơn giản nhất là loại trừ (exclude) trang đó hoàn toàn.
Cách khác là cần đảm bảo loại trừ kết hợp CSS/JS khỏi
trang liên hệ. (Tôi cũng khuyến cáo luôn là bạn không nên
sử dụng Contact Form 7).
● WSOD hoặc lỗi error 500 – thật không may nhưng không
phải mọi plugin đều tương thích với nhau. Bạn có thể khôi
phục trang của bạn bằng cách xóa phần thông tin của
LScache trong htaccess, xóa các file
“advanced-cache.php” và “object-cache.php” trong thư mục
“wp-content”. Bạn cũng có thể gia tăng giới hạn của bộ
nhớ WP.
● Admin area showing incorrectly​ (khu vực quản trị hiển
thị không chính xác) – điều này có thể là do caching dành
cho người dùng đã đăng nhập, caching nội dung riêng tư,
hoặc object-caching. Thử vô hiệu hóa tất cả và bật lại dần
từng cái một cho đến khi bạn tìm ra vấn đề.

Làm thế nào tìm và loại trừ được các vấn đề đến từ việc kết hợp
CSS/JS:

1. Phương thức cô lập A – vẫn bật chế độ KẾT HỢP CSS

hoặc JS, mở website trong trình duyệt Chrome >

44
 Developer Tools > Network (tab), và tải lại trang. Click vào
vòng tròn lỗi nhỏ màu đỏ để xem CSS/JS nào bị thiếu. Loại
trừ chúng không cho gộp và xem mọi thứ có hoạt động
bình thường không.
2. Phương thức cô lập B – vô hiệu hóa KẾT HỢP CSS
hoặc JS (hoặc thậm chí là cả caching), và quét trang của
bạn trong Pingdom​. Cuộn xuống bảng waterfall và sắp xếp
các mục tải về theo kiểu file (hiển thị gọn gàng tất cả
CSS/JS). Giờ bạn quay lại cài đặt của LiteSpeed và gộp
file CSS/JS lần nữa nhưng loại trừ thủ công bất cứ file
CSS/JS nào mà bạn nghĩ là nguyên nhân gây lỗi. (Gợi ý:
bất cứ cái gì bị hỏng có thể liên quan đến vấn đề. Có phải
một plugin hoặc chức năng theme nào đó ngừng hoạt
động? Thử vô hiệu hóa các file CSS/JS đó)​ . Vâng bạn sẽ
phải thực hiện nhiều thử nghiệm và thất bại. Nó có thể có
nguyên nhân từ bất cứ đâu, có thể là plugin, có thể là
theme.

Có nhiều cái tôi không muốn nói ra vì nó quá kỹ thuật và chỉ nên được
xử lý với người dùng trình độ cao. Nếu bạn có nhiều vấn đề với việc
gộp CSS/JS, bạn không nên sử dụng tính năng này nữa. Đó chẳng
phải lỗi của ai cả…không phải của bạn, không phải của plugin cache,
cũng không phải của theme hay plugin. (Chắc chắn bạn có thể thử
plugin gộp CSS/JS khác như Autoptimize​ và nó có thể hoạt động cho
cài đặt của bạn bây giờ nhưng sau đó có thể gặp vấn đề vào hôm xấu
trời nào đó). Tôi thực sự thực sự không khuyến khích gộp CSS/JS!

Bước 5 – Thực hành với tối ưu hóa mức cao

Chiến lược kết hợp CSS/JS

Một lần nữa, tôi ghét kết hợp CSS/JS nhưng nếu bạn thực sự muốn
làm nó…Tôi nghĩ bạn nên thử nghiệm kết hợp CSS/JS với các trang

45
thực sự nhỏ hoặc thực sự lớn. Nếu trang của bạn nằm đâu đó ở giữa,
bạn có thể có được hiệu suất tốt hơn nhiều và vận hành không rắc rối
bằng cách không quan tâm đến kết hợp CSS/JS chút nào cả. Nếu
trang của bạn thực sự nhỏ (giả sử với 5 file CSS nhưng chỉ tổng dung
lượng chỉ 7KB), kết hợp chúng thành một yêu cầu duy nhất không có
gì rắc rối (ít có khả năng xảy ra mâu thuẫn), và cũng giúp tăng tốc bởi
vì có ít yêu cầu HTTP hơn. Còn nếu trang của bạn thực sự lớn (giả
sử với 20 file CSS và tổng dung lượng lên đến 800 KB), nó có thể
đem lại lợi ích nhỏ cho một số trang nhưng không phải tất cả.

Giờ, đây là lý do tại sao tôi không khuyến khích kết hợp tất cả
CSS/JS hoặc trên các website lớn: đó là bởi vì chúng có quá nhiều
CSS/JS mà không thể tải trong một lần. Và làm trì hoãn quá trình kết
xuất (rendering) trang bằng cách đợi tất cả chúng tải về thật ngớ
ngẩn. Đó là lý do tại sao chúng ta nên kết hợp một số nhưng không
phải tất cả. Và điều quan trọng hơn, chúng ta quyết định cái nào cần
tải trước tiên.

Có 2 chiến thuật cơ bản:

● Kết hợp tất cả và loại trừ một số – điều này có ý nghĩa nhất
và phù hợp nhất với cách plugin cache vận hành. Tôi gợi ý
bạn nên kết hợp tất cả CSS/JS và loại trừ cái nào cần thiết
nhất cho việc kết xuất phần đầu của trang.
● Kết hợp một số, loại trừ phần còn lại – cái này thậm chí
còn an toàn hơn khi chỉ vài file CSS/JS sẽ được kết hợp,
hạn chế xảy ra mâu thuẫn, nhưng sẽ yêu cầu bạn làm việc
vất vả hơn một chút để chỉ định thủ công các file nào cần
loại trừ.

Bạn có thể lưu ý đến chuyện tôi không đề cập đến critical CSS chút
nào trong phần trên. Lý do tôi ghét tạo critical CSS vì nó có thể rất
khó khăn, kỳ công (finicky). Đừng sử dụng nó trừ khi bạn chắc chắn

46
biết bạn đang định làm gì. Và nếu bạn đang sử dụng nó rồi, thì tôi sẽ
không giải thích cách sử dụng nó ở đây nữa.

Chiến lược Object-Caching

Tôi chỉ khuyến khích điều này cho các trang web lớn với nhiều truy
vấn cơ sở dữ liệu và nội dung động có thể cache trong ngắn hạn
(short-term). Bất cứ cái gì có số lượng lớn thông tin và tương đối
“sống/live” hoặc “động” là dấu chỉ tốt cho object caching. Bật nó và sử
dụng redis. Sau đó hãy thoải mái thử nghiệm với thời gian hết hạn
của object cache phù hợp với bạn và không phục vụ nội dung quá
hạn (outdated content). Tôi cũng nghe nói hiệu suất tốt hơn khi sử
dụng redis trong socket Unix (mặc dù tôi chưa bao giờ làm điều này).
Đây là ​hướng dẫn dành cho người quản trị hệ thống (admin-guys).

Lưu ý: nếu phần lớn nội dung của bạn là tĩnh và số lượng nội dung
không bao giờ thay đổi, thế thì bạn không cần object caching!

Bật crawler (hoặc các chức năng làm ấm cache thay thế khác)

Bạn có bao giờ để ý là các plugin cache khác cho phép caching
trước, tải trước, hoặc làm ấm cache? Tôi chắc chắn thích tính năng
đó vì nó ngăn lượt ghé thăm đầu tiên bị chậm. Thật không may,
LiteSpeed Cache được xây dựng để hỗ trợ cho máy chủ LiteSpeed
thường được dùng cho các trang có lưu lượng truy cập cao mà ở đó
không cần lo lắng về việc làm ấm cache (vì lượt ghé thăm đầu tiên đã
làm ấm/tạo cache cho tất cả những người còn lại)…nhưng với các
trang có lưu lượng truy cập thấp, cache thường không có trong một
thời gian cho đến khi có ai đó ghé thăm.

Vì thế bạn có 2 lựa chọn:

● Bạn có thể bật LS cache crawler từ máy chủ – nhưng điều

này yêu cầu truy cập vào máy chủ và một số kỹ năng Linux

47
 để cài đặt/cấu hình nó. Một khi được cài đặt, bạn sau đó có
thể thiết lập crawler tích cực hoặc vừa phải trong chuyện
thu thập như ý bạn muốn.
● Sử dụng chức năng làm ấm thay thế – tôi giả định là bạn
không có khả năng truy cập vào máy chủ và web host của
bạn không muốn bật tính năng crawler. Họ sợ bạn làm tổn
hao tài nguyên của máy chủ. Vì thế lựa chọn thay thế cho
bạn là sử dụng plugin kiểu như Warm Cache​ cái cache
trước trang của bạn được xác định trong sitemap XML (từ
plugin SEO của bạn như YOAST, hoặc plugin sitemap như
Google XML Sitemap​) sử dụng cron jobs đặt ở tần số bạn
chọn.

Caching nội dung riêng tư

Có rất nhiều thông tin bạn có thể tham khảo. Tôi sẽ để nó ở đây cho
bạn (và/hoặc lập trình viên của bạn).

● Lựa chọn Cache công khai, Cache riêng tư, và ESI

● Cache riêng tư vs Cache công khai
● ESI và LiteSpeed Cache

Cần sự giúp đỡ từ chuyên gia?

Tôi đã làm hết sức mình để cung cấp lời khuyên chi tiết cho tất cả mọi
người. Nhưng luôn luôn có các trang cần cấu hình riêng. Bạn vẫn
gặp rắc rối? Hãy ghé thăm một trong các kênh hỗ trợ cho LiteSpeed
đề cập bên dưới đây.

● Hỗ trợ miễn phí hiện có trong nhóm cộng đồng WordPress

LiteSpeed trên Facebook​ (tiện lợi, có nhóm hỗ trợ chính
thức và bản thân tôi/Johnny cũng có trên đó), nhóm Slack

48
 (nhiều hoạt động hơn, người dùng có kỹ năng tốt hơn so
với nhóm FB), trên trang WordPress của plugin LiteSpeed
Cache​ (phản hồi chậm hơn), hoặc trên trang hỗ trợ chính
thức của LiteSpeed (lựa chọn tốt hơn và riêng tư hơn cho
người dùng trả phí).
● Nhiều giải thích hơn về các tính năng có thể được tìm thấy
trên t​ ài liệu, wiki và diễn đàn chính thức của LiteSpeed.
● Trang plugin chính thức của LiteSpeed.
● Hướng dẫn cho người mới, tài liệu chính thức của
LiteSpeed.
● Nếu bạn cần giúp đỡ nhưng vẫn muốn tự mình thực hiện
thì lời khuyên chân thành của tôi là hãy tôn trọng khả năng
của bạn, và tránh nghịch ngợm với các cài đặt mà bạn
không hiểu. LiteSpeed có các tính năng cho người mới
cũng như cho nhà lập trình và các chuyên gia về máy chủ.

(Dịch từ bài viết: LiteSpeed Cache WordPress Plugin – UNOFFICIAL

GUIDE của Johnny Nguyen,​ người dịch: Nguyễn Đức Anh)

49