Cách dùng plugin Swift Performance (bản pro có key): Hướng dẫn chi tiết để tăng tốc website WordPress

Hôm nọ tôi có viết bài về cách sử dụng Swift Performance ở mức cơ bản, hôm nay tôi sẽ viết bài chi tiết hơn dành cho những ai muốn đào sâu.

Ở thời điểm hiện tại Swift Performance nằm trong nhóm các plugin cache tốt nhất cùng với LiteSpeed Cache, FlyingPress và WP Rocket.

Swift phù hợp nhất trên các kiểu trang thế nào? Nếu website của bạn rơi vào các kịch bản sau, lựa chọn Swift có thể rất có ích:

• VPS, host nhỏ nhưng có ít bài viết.
• Website nhiều bài viết & có lưu lượng truy cập cao.
• Website có cấu trúc phức tạp, nhiều bài viết & host khỏe.

1. Website của bạn có cấu trúc phức tạp & có trên 500 bài viết, ít người truy cập, host-không-khỏe.
2. Website của bạn có nhiều bài viết & thường xuyên cập nhật nội dung cũng như yêu cầu các cập nhật, xuất bản, bình luận phải nhanh chóng được cache lại càng sớm càng tốt, host-không-khỏe.
3. Website của bạn có nhiều bài viết & môi trường hosting của bạn là sharehost hoặc VPS giá rẻ (5 – 10$/tháng, tức cũng là host-không-khỏe).

General

General > General

• General > Purchase Key: mã mua hàng bản quyền của bạn. Nó sẽ ở dạng ẩn với dấu chấm tròn hoặc hoa thị để tránh những người quản trị khác sao chép mã này.
• General > Use Compute API: BẬT- để tăng tốc độ gộp CSS, JS, tạo critical CSS,…và giảm thiểu sử dụng CPU. Đặc biệt có ích trên trang có nhiều bài viết hoặc máy chủ không mạnh.
• General > Beta Tester: TẮT- đối với các trang web quan trọng không nên bật, vì bật tùy chọn này đồng nghĩa với việc bạn sẽ nhận được bản cập nhật của plugin ở giai đoạn beta (chưa phải ổn định nhất).

General > Tweaks

• Tweaks > Normalize Static Resources: dịch nôm là bình thường hóa các tài nguyên tĩnh, nó có tác dụng loại bỏ các chuỗi query trên file CSS, JS và ảnh. Tuy nhiên nó không hữu dụng nếu bạn đã bật “Merge Scripts/ Gộp JS” và “Merge Styles / Gộp CSS”. Nó sẽ giúp cải thiện điểm số tốc độ, nhưng không tăng tốc trong thực tế. Tôi chỉ bật tùy chọn này trên các trang không thường xuyên cập nhật giao diện. Nhiều công cụ caching (trong đó có Cloudflare) đã có cách cache thông minh tài nguyên tĩnh bao gồm cả chuỗi truy vấn.
• Tweaks > Gravatar Cache: BẬT- mặc định WordPress sử dụng ảnh từ Gravatar (tài nguyên bên thứ ba) để làm ảnh đại diện cho người bình luận. Tuy nhiên đôi khi tốc độ tải ảnh này không nhanh bằng so với tải từ máy chủ của chính bạn (nhất là khi đứt cáp). Trong trường hợp đó bạn nên cache các ảnh từ Gravatar (lôi chúng về và lưu tại host của bạn) để tăng tốc website.
• Tweaks > Gravatar Cache Expiry: 1 month- thời gian hết hạn cache của ảnh. Nó chỉ hiện tùy chọn này nếu Gravatar Cache ở trên cũng được bật. Bạn nên để một tháng, vì mọi người hiếm khi thay đổi ảnh đại diện trên Gravatar. Nếu để là 1 month, thì sau một tháng, Swift sẽ tải lại ảnh đại diện của người dùng để cache lại dù ảnh đó có thay đổi hay không.
• Tweaks > Custom Htaccess: nơi bạn thêm các rule (quy tắc) tùy chỉnh đứng trước các rule của Swift Performance trong .htaccess. PS: File .htaccess là file rất quan trọng với website, gõ nhầm là có thể trang không truy cập được! Bạn nên backup file này để dự phòng, một plugin tốt để hạn chế lỗi khi sửa .htaccess là Htaccess Editor – Safely Edit Htaccess File.

General > Google Analytics

• Google Analytics > Bypass Google Analytics: tải cục bộ mã Google Analytics, cache và gộp nó với JS của trang (và về lý thuyết giúp bạn loại bỏ được một lời gọi bên ngoài đến Google- tức là bớt được thời gian tìm kiếm DNS, thực hiện kết nối https). Dưới khía cạnh tốc độ, điều này không có nhiều ích lợi nhưng nó sẽ cho bạn điểm số ngon mắt hơn (chỉ là lợi ích bề ngoài). Chỉ có một vấn đề duy nhất GA không hoạt động trên trang uncached/excluded (hiện vẫn chưa được cache/loại trừ). Để đảm bảo 100% chức năng của GA trong suốt quá trình prebuild cache (xây dựng trước cache) và trên trang chưa được cache, tôi dùng plugin CAOS hoặc chỉnh sửa theme để xử lý GA.

Media

Media > Images

• Images > Optimize Images on Upload: bật tùy chọn này nếu bạn muốn tối ưu hóa các ảnh khi bạn upload lên website, sử dụng API tối ưu ảnh của Swift Performance. Khi dùng plugin cache tôi thường sử dụng luôn dịch vụ tối ưu ảnh của họ, tôi nhận thấy các dịch vụ tối ưu ảnh, nhất là với tối ưu kiểu lossless (không mất dữ liệu) không chênh lệch nhau đáng kể. Tốc độ tối ưu ảnh của cả Swift và LiteSpeed đều khá nhanh, lại miễn phí- đây là ưu điểm so với plugin WP-Rocket, plugin tên lửa không tích hợp sẵn dịch vụ tối ưu ảnh miễn phí, bạn phải mua thêm dịch vụ của họ thì mới dùng được!
• Images > Image Optimizer: thiết lập chất lượng ảnh muốn tối ưu hóa. Tôi thường để tùy chọn lossless- tức là nén không mất chất lượng. Các tùy chọn về sau (Slightly Lossy, Moderate, Agressive) giảm được nhiều dung lượng hơn nhưng ảnh sẽ bị mất chất lượng đáng kể, nên dùng thận trọng và cần kiểm tra kỹ lưỡng. Chất lượng ảnh thấp là điều rất tệ hại đối với trải nghiệm người dùng.
• Images > Keep Original Images: giữ lại ảnh gốc. Lúc nào bạn cũng nên bật tùy chọn này trên bất kỳ plugin nén ảnh nào để dự phòng trường hợp ảnh tối ưu có chất lượng không cao như mong muốn thì vẫn còn ảnh gốc để khôi phục lại. Tất nhiên điều này sẽ làm tăng sử dụng dung lượng ổ đĩa, nếu bạn muốn tiết kiệm, bạn có thể xóa backup của ảnh gốc- nhưng chỉ khi đã đảm bảo được rằng chất lượng ảnh đã tối ưu đạt tiêu chuẩn (thường thì sẽ ổn nếu bạn dùng kiểu nén không mất chất lượng).
• Images > Generate WebP: nếu bạn bật tùy chọn này các ảnh của bạn sẽ được tạo thêm phiên bản webp. Ảnh webp rất có tiềm năng, Safari cũng mới hỗ trợ nó. Tuy nhiên hiện tại tôi chỉ áp dụng webp rất hạn chế. Ngoài vấn đề không tương thích 100% với các trình duyệt và làm tăng dung lượng ổ đĩa, webp đôi khi gặp vấn đề về chất lượng, dung lượng tăng hơn ảnh gốc (dù vấn đề này hiếm khi xảy ra, và có thể sửa được nhưng có thể gây khó khăn cho người ít có kinh nghiệm). Tham khảo thêm bài viết: năm 2020 định dạng ảnh WebP đã phổ biến chưa.
• Images > Serve WebP: phần trên mới chỉ tạo ảnh webp trên trang, nếu bạn muốn website đưa ảnh này đến người dùng cuối thì bạn phải để tùy chọn này khác “Don’t use WebP”. Có hai cách là dùng <picture> hoặc rewrites. Lựa chọn dùng picture elements tốt hơn dùng rewrites- vì rewrite sẽ không ổn nếu bạn dùng CDN hoặc Cloudflare. Nên kiểm tra cẩn thận các tùy chọn này.
• Images > Inline Small Images: nội tuyến các ảnh nhỏ. Sử dụng ảnh được mã hóa theo kiểu base64 để nội tuyến nó vào trang (chèn trực tiếp mã). Điều này giúp bạn giảm được số lượng yêu cầu http. Tuy nhiên nên tắt tùy chọn này nếu bạn không hiểu rõ tác dụng của nó là gì, hoặc rơi vào những trường hợp sau, (1) các ảnh nhỏ của bạn không ở phần đầu của trang, (2) website của bạn có nhiều bài viết, (3) bạn quan tâm đến việc đẩy nhanh tốc độ xây dựng trước cache (giống tôi). Bạn có thể thử bật nó nếu bạn có nhiều ảnh nhỏ thuộc màn hình đầu tiên (các icon mạng xã hội hoặc thương mại điện tử), không dùng FontAwesome, hoặc chỉ có vài trang. Nó có lẽ có ích hơn trên các website nhỏ.
• Images > File Size Limit (bytes): ở đây bạn đặt giới hạn kích cỡ tính theo byte cho ảnh muốn inline. Để 1000 tức là ảnh xấp xỉ 1KB. Nghĩa là chỉ ảnh dưới 1KB mới được inline, hơn thì vẫn để như bình thường.
• Images > Lazyload Images: bật nếu bạn muốn tải lười ảnh, tuy nhiên tôi nhận thấy nó không mạnh bằng plugin Flying Images hoặc a3 Lazy Load vì chỉ ảnh trong khung nhìn trình duyệt mới được tải, thay vì tải trước khi đi vào viewport.
• Images > Exclude Images URL: có một số ảnh bạn không muốn lazy load vì nó nằm trong màn hình đầu tiên, ví dụ như logo, ảnh giỏ hàng. Bạn cần loại trừ nó ra, điều này giúp giao diện màn hình đầu tiên đỡ bị xáo trộn. Bạn chỉ thấy tùy chọn này nếu Lazyload Images được bật.
• Images > Exclude Images by CSS classname: loại trừ ảnh khỏi lazy load thông qua tên class của ảnh. Rất có tác dụng nếu bạn muốn loại trừ cả loạt ảnh thay vì chỉ một ảnh cụ thể nào đấy thông qua URL. Bạn chỉ thấy tùy chọn này nếu Lazyload Images được bật.
• Images > Inline Lazy Load Images: đặt nội tuyến phiên bản ảnh nhỏ kiểu base64 của website trong lazy load thay vì để nó ở file riêng, điều này giúp giảm số lượng kết nối. Nên dùng. Đây là kiểu lazyload LQIP, LiteSpeed Cache cũng có kiểu lazy này. Bạn chỉ thấy tùy chọn này nếu Lazyload Images được bật.

Optimization

Optimization > General

• General > Enable Server Push: TẮT- tính năng này cho phép bạn gửi các tài nguyên của trang đến trình duyệt trước cả khi trình duyệt yêu cầu chúng. Tôi khuyên là bạn nên vô hiệu hóa nó. Nó tăng tốc trang bằng cách tải trước các tài nguyên CSS và JS của các trang khác, vì thế chúng sẽ tải nhanh hơn khi được click vào. Nó có khả năng có ích trên các trang có nhiều CSS/JS, nhưng cũng làm tăng rắc rối gặp phải trên các trang như vậy (vỡ giao diện, lag, sử dụng CPU cao). Nếu bật, bạn nên kiểm tra cẩn thận. Điểm số trang có thể thấp hơn vì giờ mỗi trang phải tải nhiều tài nguyên hơn. Tôi cũng nghĩ rằng nó không cần thiết nếu trang của bạn tải cùng CSS/JS cho các trang (cái đã được trình duyệt cache sẵn).
• General > Optimize Prebuild Only: TẮT- trong một số trường hợp việc tối ưu hóa trang mất thời gian. Nếu bạn bật tùy chọn này plugin sẽ chỉ tối ưu hóa trang khi quá trình xây dựng trước cache đang chạy. Bạn nên bỏ chọn tính năng này để trang luôn được tối ưu hóa. Bật nó sẽ làm giới hạn quá trình tạo cache (không cần thiết trên hầu hết website).
• General > Optimize in Background: trong một số trường hợp việc tối ưu hóa trang có thể mất thời gian. Nếu bạn bật tùy chọn này plugin sẽ tối ưu trang ở chế độ background. Nó giúp ngăn việc thời gian tải trang kéo dài trong lần ghé thăm đầu tiên (khi trang hiện vẫn chưa được cache). Nó có thể hữu ích trên các trang web lớn hoặc trên máy chủ VPS.
• General > Minify HTML: TẮT- loại bỏ các khoảng trắng không cần thiết trong HTML. Tôi đoán rằng nó sẽ làm chậm lại việc xây dựng cache (và không đem lại lợi ích đáng kể). Vì thế tôi thường vô hiệu hóa nó trên website có nhiều trang hoặc máy chủ không được nhanh.
• General > Disable Emojis: BẬT- vô hiệu hóa các biểu tượng mặt cười, mặt mếu, hầu hết các trang không sử dụng biểu tượng này. Ngoài ra các trình duyệt hiện đại đã có sẵn các biểu tượng đó giúp bạn rồi.
• General > Limit Simultaneous Threads: TÙY- giới hạn số lượng luồng tối đa đồng thời. Nó có thể hữu ích trên môi trường share host để tránh các lỗi 508. Bạn có thể không cần bật tính năng này nếu bạn đang dùng máy chủ riêng hoặc trang web nhỏ (100 trang hoặc ít hơn). Bật nó với các thiết lập 1,2 hoặc 3 nếu bạn đang ở trên môi trường shared server hoặc muốn ngăn Swift ăn quá nhiều tài nguyên máy chủ. Lý tưởng nhất, bạn muốn sử dụng tất cả tài nguyên có thể để xây dựng trước cache nhanh chóng (tức là không bật tính năng giới hạn).

Optimization > Scripts

• Scripts > Merger Scripts: gộp các file JS lại để giảm số lượng kết nối.
• Scripts > Exclude Scripts: bạn thêm tên file JS vào đây nó sẽ loại trừ không gộp những file này. file jQuery là cái tên cần lưu ý. Vì jQuery thường phải tải trước cho các mã nội tuyến trên trang dùng.
• Scripts > Footer Scripts: loại trừ các scripts khỏi gộp và chuyển nó xuống chân trang, bạn chỉ cần đưa tên file vào là được.
• Scripts > Deferred Scripts: loại trừ các script bạn thêm vào đây để không cần gộp chúng, nhưng thiết lập thuộc tính defer cho chúng. Defer giúp mã JS đỡ chặn hiển thị.
• Scripts > Exclude Inline Scripts: loại trừ script inline (nội tuyến) không cần gộp.
• Scripts > Footer Inline Scripts: loại trừ mã inline JS không cần gộp và đẩy nó xuống chân trang.
• Scripts > Minify JavaScripts: nên bật, cái này dùng để rút gọn file JS.
• Scripts > Separate Scripts: nếu bạn bật tùy chọn này, Swift sẽ lưu file kết hợp cho các trang theo cách riêng biệt. Theo tôi thì không nên bật vì nó sẽ làm giảm tác dụng của cache phía trình duyệt.

Optimization > Styles

• Styles > Merge Styles: nên Bật- gộp các file CSS để giảm số lượng yêu cầu HTTP.
• Styles > Generate Critical CSS: nên BẬT- được trích xuất từ CSS đầy đủ, nên dùng, đây là một trong các tính năng giúp cải thiện tốc độ nhận thức tốt nhất, đặc biệt trên các theme không được viết mã tốt.
• Styles > Critical CSS method: lựa chọn phương thức cho critical CSS, có hai lựa chọn là Unused CSS và Viewport based. Trong khi Unsed CSS là việc loại trừ các CSS không sử dụng, thì Viewport based là cách trích xuất CSS chỉ cho phần nội dung thuộc màn hình đầu tiên. Cá nhân tôi thường chọn Viewport based, tuy nhiên bạn nên thử nghiệm để biết lựa chọn nào tốt hơn cho website cụ thể của bạn.
• Styles > Extra Critical CSS: nếu bạn muốn bổ sung thêm các quy tắc cho critical CSS thì bạn thêm nó vào đây. Thường chỉ cần nếu bạn thấy việc tạo critical CSS của Swift Performance có vấn đề. Tôi hiện vẫn chưa cần dùng tính năng này, vì khả năng tạo critical CSS của Swift rất tốt.
• Styles > Load Full CSS On Scroll: TẮT- tải đầy đủ CSS *chỉ* khi người dùng cuộn chuột. Quan điểm của tôi là CSS nên được tải và phân tích sớm nhất có thể để giao diện không bị lỗi hiển thị.
• Styles > Print critical CSS inline: nên BẬT- bật tùy chọn này nếu bạn muốn nội tuyến critical CSS vào phần header thay vì sử dụng file CSS riêng. Bạn nên chọn vì critical CSS theo kiểu viewport thường khá nhẹ.
• Styles > Print full CSS inline: nên TẮT- chỉ bật tùy chọn này nếu bạn muốn đưa toàn bộ mã CSS nội tuyến vào phần chân trang, chứ không tách file riêng. Trong đa số trường hợp không nên chọn. Dù nó có thể cải thiện tí chút điểm số nhưng sẽ làm bạn thiệt hại nhiều về băng thông và đặc biệt là cache phía trình duyệt.
• Styles > Separate Styles: bật nếu bạn muốn phục vụ file CSS gộp riêng biệt trên từng trang. Cá nhận tôi khuyên không dùng, lý do tương tự trường hợp với JS.
• Styles > Minify CSS: rút gọn dung lượng file, loại bỏ các khoảng trống không cần thiết, mã màu rút gọn, và font weights. Nếu chọn bạn nên sử dụng tùy chọn “basic”. Nếu bạn muốn quá trình xây dừng cache nhanh hoặc đã bật sẵn tính năng này trên Cloudflare thì hãy để là “Don’t minify / Không rút gọn”.
• Styles > Bypass CSS Import: bao gồm các file CSS kiểu imported vào trong style gộp. Bạn nên để là BẬT như mặc định.
• Styles > Exclude Styles: loại trừ các file CSS này không cần gộp nếu tên các file đó được thêm vào ở đây.
• Styles > Exclude Inline Styles: loại trừ các style CSS nội tuyến không cần gộp nếu thành phần của nó được đưa vào trong khung này.

Caching

Caching > General

• General > Enable Caching: BẬT- dĩ nhiên chúng ta phải bật nó rồi! Không bật cái này thì dùng Swift Performance làm gì chứ?!
• General > Caching Mode: để là Disk Cache with Rewrites sẽ cho tốc độ phục vụ cache tốt hơn, Disk Cache with PHP chậm hơn một chút nhưng có thể ít gặp lỗi hơn. Một số plugin cache (ví dụ CommetCache) thích kiểu PHP hơn. Họ cho rằng nó tốt hơn, nhưng phần quan tâm của tôi là tốc độ của cái nào cao nhất. Memcache with PHP chắc chắn rất nhanh nhưng nó phụ thuộc vào môi trường hosting của bạn. Memcached hoạt động tốt hơn trên VPS so với shared hosting.
• General > Early Loader: Bật- phải được tick chọn. Giúp tăng tốc độ xử lý PHP.
• General > Cache Path: đường dẫn lưu các trang cache. Hãy kiểm tra thư mục này nếu caching hoặc prebuild (xây dựng trước cache) không hoạt động; có thể là do sai đường dẫn từ máy chủ cũ khi bạn chuyển host. (Vào cPanel “File Manager” để có đường dẫn chính xác).
• General > Cache Expiry Mode: kiểu xác định cache hết hạn, có 2 kiểu là dựa vào hành động (Action based mode) hoặc dựa vào thời gian (Time based mode). Tôi thích kiểu “Action based mode” trên 99% website. Bạn có thể chọn “Time based mode” nếu trang của bạn không cập nhật nội dung thường xuyên (chẳng hạn như ít khi có bình luận mới hoặc thay đổi trạng thái sản phẩm)
• General > Cache Expiry Time: nếu bạn bật tùy chọn Cache Expiry Mode theo kiểu Time based thì mới có tùy chọn này, lựa chọn tối đa là 2 ngày.
• General > Garbage Collection Interval: tần số kiểm tra các trang cache hết hạn. Trên các trang lớn bạn nên để thời gian này thấp, ví dụ 10 phút. Tùy chọn này cũng chỉ có khi bạn chọn Time based.
• General > Enable Caching for logged in users: tùy chọn này có thể làm tăng dung lượng cache, tùy thuộc vào số lượng người dùng. Cá nhân tôi không chọn.
• General > Separate Mobile Device Cache: bạn có thể tạo cache tách biệt cho thiết bị di động, nó có thể hữu ích nếu trang của bạn không phải dạng đáp ứng, nhưng có giao diện di động riêng (ví dụ AMP). Nhưng nếu trang bạn là dạng đáp ứng rồi thì không nên dùng.
• General > Enable Browser Cache: nên BẬT. Nếu bạn bật tùy chọn này nó sẽ tạo ra các rule cho cache phía trình duyệt (các header expire cũng phải được cấu hình trên máy chủ của bạn).
• General > Enable Gzip: BẬT- nếu bạn bật tùy chọn này, nó sẽ tạo các rules htaccess/nginx cho mục đích nén gzip (chức năng nén cũng phải được cấu hình trên máy chủ web của bạn). Nên bật. PS: dù kiểu nén gzip không mạnh như nén brotli nhưng nó được hầu hết máy chủ web cũng như trình duyệt cũ lẫn mới hỗ trợ. Nếu bạn dùng OpenLiteSpeed nó chỉ hỗ trợ gzip, phải dùng bản LiteSpeed Enterprise mới có brotli. PS: dùng LiteSpeed Enterprise với một website và RAM từ 2GB trở xuống bạn vẫn được free.
• General > Cache 404 pages: chỉ bật tính năng này nếu bạn có trang web nhỏ hoặc/và có URL không tồn tại thường xuyên được ghé thăm. Còn không nó có thể nhanh chóng làm đầy & tắc nghẽn bảng warmup (bảng xây dựng trước cache).
• General > Enable Dynamic Caching: một trong các tính năng cao cấp rất hay của Swift, nhưng nếu không phải là người am hiểu thì tốt nhất là bạn không động đến nó. Có thể cache hoặc cho phép tương thích với các tính năng như đa tiền tệ, vân vân. Tôi sẽ giải thích nó sau.
• General > Cacheable AJAX Actions: một tính năng nâng cao khác. Bạn cũng không nên động đến nó.
• General > AJAX Cache Expiry Time: bạn cứ để nó như mặc định.

Caching > Tweaks

• Tweaks > Avoid Mixed Content: VÔ HIỆU HÓA. Nó có thể gây vấn đề cho các URL! Chỉ cần thiết nếu trang của bạn vẫn sử dụng HTTP nhưng có một số yêu cầu gửi đến bên thứ ba là HTTPS (chẳng hạn như GoogleMaps). Giờ thì hầu hết các trang đã có HTTPS đầy đủ rồi.
• Tweaks > Keep Original Headers: Tôi bật tùy chọn này.

Caching > Exceptions

• Exceptions > Exclude Post Types: bạn cần phải loại trừ tất cả các kiểu post NGOẠI TRỪ posts, pages, products, và bất cứ kiểu post nào hiển thị trên front-end kèm với URL slug duy nhất của riêng nó. (Nếu bạn không loại trừ những kiểu post không liên quan; trang sẽ cache tất cả các mục thậm chí nếu chúng không hiển thị ra ngoài front-end, hơn nữa nó làm trì hoãn xây dựng trước cache cho tài nguyên quan trọng hơn. Các website lớn cần phải xác định rõ và loại trừ các kiểu post không cần thiết!).
• Exceptions > Exclude Pages: bạn cần loại trừ bất cứ kiểu trang nào đi kèm với “live info”, “private data”, hoặc không hoạt động đúng khi được cache. Ví dụ tốt là về các trang kiểu như form, trang WooCommerce (tài khoản/account, giỏ hàng/cart, thanh toán/checkout, wishlist), các trang sales (với mã theo dõi), và bất cứ trang động/riêng tư nào.
• Exceptions > Exclude URLs: loại trừ bất cứ URL nào không thể chọn ra được bằng cách sử dụng kiểu post hoặc page kể trên. Bạn có thể sử dụng REGEX để loại trừ nhiều URL cùng lúc. (Tôi khuyến khích thêm các mục “#revision#”, “#autosave#”, và “#json#” vào phần này để ngăn các mục như vậy caching. Bạn cũng có thể thêm “/feed” hoặc các cái khác.
• Exceptions > Exclude Cookies: ngăn một số người dùng với cookies cụ thể nào đấy xem các trang cache. Hữu ích để hiển thị nội dung mới nhất cho một nhóm người dùng cụ thể.
• Exceptions > Exclude Content Parts: hữu ích trong trường hợp bạn muốn loại trừ nội dung hoặc bài đăng cụ thể nào đấy không hiển thị nhiều trang. Chỉ cần thêm đoạn văn bản ở đầu vào.
• Exceptions > Exclude User Agents: ngăn một số thiết bị xem các trang đã được cache.
• Exceptions > Exclude Crawlers: ngăn các máy tìm kiếm cụ thể hoặc các bọ tìm kiếm nói chung truy cập vào trang cache. Chúng sẽ chỉ nhìn thấy các trang ở dạng chưa được cache, vì vậy sẽ có được nội dung mới nhất, nhưng điều đó có thể làm gia tăng hoạt động của máy chủ nếu bọ ghé thăm thường xuyên.
• Exceptions > Exclude Author Pages: Tôi tick chọn. Trang tác giả thường không được ghé thăm nhiều, vì thế bạn nên tập trung nhiệm vụ cache vào các trang khác.
• Exceptions > Exclude Archive – Tôi thường BỎ CHỌN. Các trang chuyên mục thường được ghé thăm thường xuyên, và sẽ tải chậm nếu không được cache. Không cache chúng sẽ đảm bảo cho trang hiển thị được bài đăng mới nhất nhưng điều này không cần thiết vì Swift Performance xây dựng cache khá chăm chỉ.
• Exceptions > Exclude REST URLs: BẬT. Bạn không cần precache những mục này.
• Exceptions > Exclude Feed. BẬT. Bạn không cần precache những mục này. Chúng tải đủ nhanh và không được ghé thăm thường xuyên. Ngoài ra nó có thể nhân đôi số lượng item trong bảng cache của bạn (điều đó mới lộn xộn làm sao).

Caching > Warmup

• Warmup > Prebuild Cache Automatically: BẬT- tùy chọn này sẽ xây dựng trước cache sau khi nó đã được xóa. Đây là một trong các tùy chọn đáng giá nhất của Swift Performance và nên được bật. Trường hợp bạn nên tắt prebuild là khi bạn có rất nhiều trang, chẳng hạn như trên 1000 trang, khi đó máy chủ sẽ thường xuyên bận rộn với quá trình prebuild, hoặc khi bạn có lượng traffic rất lớn, và nhờ vậy bạn sẽ nhanh chóng có được trang đã prebuild). Nếu bạn nào thắc mắc tại sao lưu lượng truy cập lớn lại có ích, giả dụ nếu trang bạn đang đọc chưa được cache, vào một ngày nó có 100 người truy cập vào, thì chỉ người đầu tiên bị vấn đề chưa được cache, 99 người còn lại khi vào trang sẽ được cache. Với prebuild thì ngay người đầu tiên trang đã được cache sẵn rồi.
• Warmup > Prebuild Speed: bạn có thể giới hạn tốc độ xây dựng trước cache ở phần này. Bạn nên dùng trên các gói share host với các lựa chọn như moderate (trung bình), reduced (giảm trừ), slow (chậm), nếu không công ty hosting có thể phạt bạn vì sử dụng quá mức CPU/tài nguyên. Với trường hợp bạn có máy chủ riêng/đang dùng VPS hoặc có dưới 400 bài viết hãy thử bật tùy chọn “Unlimited/Không giới hạn” hoặc “Multi thread / Đa luồng”.
• Warmup > Prebuild Author Pages: TẮT- xây dựng trước trang tác giả. Trong đa số trường hợp không cần thiết, vì ít người truy cập trang này.
• Warmup > Prebuild Archive: BẬT- xây dựng trước các trang chuyên mục (category), nên bật vì trang category rất thường xuyên được ghé thăm.
• Warmup > Prebuild Terms: TÙY- xây dựng trước các trang kiểu như tag, tùy tình huống mà bạn có nên bật hay không (ví dụ nên bật nếu người dùng của bạn thường xuyên truy cập vào các tag). Còn nếu ngược lại thì nên vô hiệu hóa nó, vì có những website chỉ có vài trăm bài viết mà có cả hàng ngàn tag (về cơ bản bạn không muốn phí thời gian để prebuild các trang tag, thời gian đó nên dành cho các trang content, nơi người dùng ghé thăm thường xuyên hơn).
• Warmup > Prebuild REST URLs: tôi không bật tùy chọn này, nó không phải là tính năng quan trọng.
• Warmup > Prebuild Feed: tôi cũng không bật tùy chọn này.

Caching > Varnish

• Varnish > Enable Auto Purge: nếu bạn sử dụng phương thức cache phía máy chủ là Varnish, bạn cần bật tùy chọn này. PS: Varnish có chất lượng tốt, ngày xưa tôi dùng gói DreamPress của Dreamhost thấy website dùng varnish rất khỏe. Tuy nhiên cài đặt cache phía máy chủ mà không thông qua control panel dạng đồ họa thường không dễ dàng gì, nó đòi hỏi bạn có kỹ năng tốt về máy chủ nếu muốn tự làm.

CDN

CDN > General

• General > Enable CDN: nếu bạn sử dụng CDN thì bật tính năng này, còn không thì thôi. Tuy nhiên có điểm cần lưu ý là tính năng này không thay thế plugin CDN của bạn (ví dụ CDN Enabler). Swift Performance với thiết lập này chỉ làm nhiều vụ purging CDN, chứ không phải bật nó (lạ thế chứ lại)! (PS: Cloudflare không được xem là CDN theo nghĩa truyền thống, để chỉnh nó bạn cần sử dụng tab Cloudflare).

Các phần sau chỉ có nếu bạn bật CDN.

• General > CDN Hostname: nhập tên miền CDN vào đây, không cần thêm https đằng trước.
• General > CDN Custom File Types: sử dụng CDN cho các kiểu file tùy chỉnh. Chỉ định định dạng cụ thể, ví dụ như pdf.
• General > Exclude File Types from CDN: vô hiệu hóa CDN cho các kiểu file mà bạn muốn. Cần chỉ định định dạng cụ thể, ví dụ như mp3 (file âm thanh).

CDN > Cloudflare

• Cloudflare > Enable Auto Purge: tick tùy chọn này nếu bạn dùng Cloudflare. Nếu dùng Cloudflare mà không tick thì bạn sẽ phải purge Cloudflare theo cách thủ công mỗi khi bạn thay đổi điều gì đó trên trang hoặc Swift cache. (Cần đảm bảo là bạn nhập đầy đủ tài khoản email và API key).
• Cloudflare > Cloudflare Account Email: nhập tài khoản email của bạn
• Cloudflare > Cloudflare API Key: nhập vào khóa API Cloudflare toàn cầu của bạn.
• Cloudflare > Cloudflare Host: nhập tên miền của bạn.

Export/Import

Phần này không tác động gì đến hiệu suất tốc độ của website cả. Nó có ích trong trường hợp bạn muốn tái sử dụng lại các cài đặt trên nhiều website khác nhau. Chỉ hữu ích nếu bạn có các trang có cài đặt na ná nhau, ngoài ra cần kiểm tra lại các thông tin đặc thù như tên file cần loại trừ, CDN, vân vân vì những thông tin này là riêng biệt trên mỗi trang.

• Export Settings > Download: tải xuống các cài đặt mà bạn đã tiến hành ở trên.
• Import Settings > Choose file: tải lên file cài đặt mà bạn đã xuất trước đó.