Professional Documents
Culture Documents
đặ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 //
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.
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ụ).
2
Breeze, Comet Cache, Cache Enabler và Speed of Light
cũng có chất lượng tốt.
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!
(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).
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ó!
Yêu cầu:
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.
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.
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).
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.
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).
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ó.
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.
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.
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.
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.
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.
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 độ.
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.
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.
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.
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.
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!
26
jQuery) nếu bạn kiểm tra cẩn thận và thấy website không
gặp vấn đề gì.
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.
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.
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.
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.
● 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.
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.
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).
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ể.
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.
● 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!
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.
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ó!
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ó!
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.
42
● Use latest WordPress release version – click vào để sử
dụng phiên bản ỔN ĐỊNH nhất của LSC.
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.
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:
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!
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.
● 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.
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.
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.
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).
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ủ.
49