Chắc chắn Swift Performance phải tìm cách cải tiến hơn nữa tốc độ tạo cache trên các host có chất lượng trung bình & thấp

Trong nhóm các plugin mạnh nhất trong việc tạo cache cho WordPress (ngoài Swift Performance còn LiteSpeed cache và WP Rocket) thì Swift có tốc độ tạo cache chậm nhất.

Swift tạo cache chậm cả ở phần prebuild cache (tạo trước cache) & tạo cache khi người dùng truy cập.

Họ gặp vấn đề lớn cả ở hai khía cạnh, thế có khổ không!

  • Với prebuild cache thì Swift Performance phải yêu cầu máy chủ có cấu hình tốt thì quá trình tạo mới nhanh hoặc/và không bị gián đoạn giữa chừng. Trong khi đa số chủ website chỉ thuê VPS hoặc host có giá 5 – 10$/tháng, và cái này không đủ với Swift để xây dựng trước cache nhanh.
  • Với tạo cache khi người dùng truy cập họ còn gặp vấn đề lớn hơn khi có độ trễ kết xuất trang có thể lên đến 4 – 5s (may là chỉ lượt xem đầu bị chậm, các click tiếp theo của người dùng đó không còn bị như vậy nữa, do cache phía trình duyệt đã đỡ cho rất nhiều?).
tốc đọ tạo trước cache của Swift chậm

Những vấn đề trên đặc biệt đúng trên các trang phức tạp & nhiều bài viết, trên các trang đơn giản dạng blog (kể cả nhiều bài) thì Swift tạo cache với tốc độ chấp nhận được.

Website phức tạp làm thời gian tạo cache kéo dài ra. Ví dụ nếu trang đơn giản bạn có thể chỉ mất 30s để tạo cache tự động và 2s để tạo cache khi người dùng truy cập thì trên trang phức tạp con số này có thể nhân lên 3 tới 4 lần. Kết hợp với việc nó có từ 300 bài viết đổ lên thì công việc lại càng thêm vất vả.

Nói thêm về prebuild cache ở các plugin khác, trên nhiều hosting dùng LiteSpeed cache, người quản trị web bị khóa tính năng tạo trước cache để tránh lạm dụng tài nguyên máy chủ (làm ảnh hưởng đến các website khác chung host đó), nhưng bù lại tốc độ tạo cache khi người dùng truy cập của LScache rất ổn, chỉ 1-2s, không khác gì mấy truy cập thông thường, ngay cả với các cài đặt tối ưu phức tạp.

Swift do vậy đang rơi vào tình trạng tiến thoái lưỡng nan trên các trang phức tạp có nhiều bài viết & không có nhiều người truy cập vào các bài viết trên trang đó.

Giải thích thêm: Nếu có nhiều người truy cập vào các bài viết trên trang (chẳng hạn trung bình một bài nhận được 20 view thì mới phải tạo cache mới) thì chỉ người đầu tiên gặp vấn đề về tốc độ truy cập, 19 người còn lại truy cập vào trang đó sẽ nhanh, tức là phần ảnh hưởng chỉ 5%. Nhưng nếu trung bình chỉ có 2 view, thì đến 50% phần lượt xem bị ảnh hưởng! Trong khi số lượng website có trung bình view trên bài viết cao trước khi cache hết hạn không nhiều.

Nói về tình thế tiến thoái lưỡng nan: nếu Swift chỉ xây dựng cache theo cách người dùng truy cập thì tốc độ tải lần đầu sẽ rất chậm, còn nếu chỉ để prebuild cache thôi thì cũng chẳng khá hơn bao nhiêu, khi quá trình này cũng chẳng nhanh và hay bị gián đoạn trên host yếu.

Swift có tính năng Optimize Prebuild Only, tức là chỉ xây dựng cache trong quá trình tạo trước cache nhằm tránh ảnh hưởng đến người dùng khi vấn đề xây cache trong khi truy cập bị kéo dài trong lượt đầu tiên. Tuy nhiên bản thân tốc độ xây trước cache của Swift cũng không tốt, làm việc bật tính năng này sẽ làm trang rất lâu mới xây dựng được hết cache của toàn website (nhất là trên trang nhiều bài viết).

Ngay cả khi tôi áp dụng các biện pháp giúp tăng tốc xây dựng prebuild cache, cải tiến cũng không đáng để ăn mừng, ước chừng chỉ 20 – 30%.

Hết hy vọng rồi chăng!

KHÔNG. Vẫn còn! Thật đáng tiếc nếu vì nhược điểm này (dù tôi biết là nó không nhỏ chút nào) mà bạn rời bỏ Swift Performance.

Tại sao phải tiếc? Để tôi kể ra vài ưu điểm nội trội của Swift:

Nàng xinh, nhưng nàng hơi khó tính & nấu ăn hơi tệ phải không ?!


Ngoài các cách cải tiến tốc độ xây cache ở link trên, tôi mới phát hiện ra vài mẹo để hạn chế điểm yếu này của họ.

  • Nếu trang của bạn ít khi cập nhật và xuất bản bài mới thì hãy để tự động xóa cache toàn bộ website ở dạng dựa trên hành động (cập nhật, xuất bản, có bình luận mới): Cache Expiry Mode > Action based mode
  • Nếu trang của bạn thường xuyên cập nhật và xuất bản bài mới hãy để tự động xóa cache toàn bộ website ở dạng dựa trên thời gian: Cache Expiry Mode > Time based mode (tối đa là 2 ngày).

Với lựa chọn như vậy, thời gian sống của cache của bạn sẽ dài ra tối đa, và tỷ lệ người phải chịu tốc độ truy cập thấp trong lần đầu vào trang sẽ giảm xuống tối thiểu.

Tùy chọn số hai, nếu máy chủ của bạn yếu và kết quả là việc tạo trước cache bị gián đoạn quá lâu, hãy sử dụng API tạo trước cache của Swift, nó sẽ hỗ trợ cho host của bạn.

Cách làm, bạn bật chế độ hiển thị nâng cao Advanced view > Caching > Warmup > Enable Remote Prebuild Cache rồi bật tùy chọn này lên (nó nằm ở cuối).

Cuối cùng theo tài liệu hướng dẫn chính thức của Swift về prebuild cache, để trang quản trị admin mở là cách tự động xây dựng cache nhanh hơn – đây cũng là biện pháp tự chủ tôi nhận thấy giúp cải thiện tốc độ xây trước cache tốt nhất.

Tôi sẽ tiếp tục tìm cách cải tiến tốc độ xây cache của Swift, chứ xinh nhưng có phần khó tính và nấu ăn không ngon lắm thế này thì nếu không có điều kiện cưng chiều tiệc tùng, quán xá lại bỏ nhau sớm thôi!