🚀 Tăng tốc WordPress – Hãy thử và tăng tốc độ web x10 lần

Bạn đã dính bẫy giật tít của Thạch 🪤

Trong lúc xây dựng lại bài viết Học WordPress Tinh Gọn 2024 với các kiến thức và quy trình hoàn toàn mới phù hợp với xu hướng hiện đại hiện nay, thì mình có đọc lại một số bài cũ thì kiến thức hầu đã “già” không khác gì đang xài điện thoại cùi bắp trong năm 2024. Trong đó có bài về tăng tốc WordPress toàn tập nhưng qua sự thay đổi và nâng cấp của WordPress lẫn các công nghệ hỗ trợ đời mới, cách làm cũng khác đi kha khá. Vậy nên mình sẽ viết lại bài này theo hướng chi tiết và phù hợp nhất hiện nay.

Trong bài viết này mình sẽ chia làm 2 phần, bao gồm:

• Phần 1 mình sẽ tập trung đi vào phân tích để đi tìm cho câu hỏi tưởng nghe rất đơn giản nhưng lại rất chung chung: tại sao website WordPress của tôi bị chậm? Hãy làm cho nó nhanh lên đi.
• Những công việc tối ưu tốc độ cho website mà mọi website cần phải làm.

Vấn đề tăng tốc webiste WordPress tưởng chừng như rất đơn giản như vậy, cũng chỉ là cài mấy cái plugin vào thôi mà, việc gì phải dài dòng? Đây mới là vấn đề. Vì qua thời gian rất dài điều hành doanh nghiệp, mình gặp rất nhiều người mà đa phần là đang ngộ nhận về website WordPress bị chậm, từ đó chúng ta chỉ đi xử lý phần ngọn thông qua các plugin, nhưng không xử lý tận gốc.

Vậy thì rõ rồi, bài này mình viết ra với mục đích cung cấp cho bạn một cái nhìn lòng vòng hơn về một vấn đề đơn giản, từ đó khi website WordPress của mình nếu có bị chậm thì có các phương án hợp lý cụ thể, chứ không phải vớ được bao nhiêu plugin hỗ trợ tối ưu là cài hết vào.

Thông tin thêm: Bài này mình viết dựa vào các trải nghiệm cá nhân của mình, nhưng được tinh chỉnh lại các phần cần tinh chỉnh thì đa phần sẽ sử dụng plugin hỗ trợ để đảm bảo ai cũng có thể tự thao tác được.

Vì sao website WordPress của bạn bị chậm?

Thành thật công tâm mà nói, nếu so bản thân mã nguồn WordPress với các tech stack đời mới hiện nay như các website sử dụng Node.js, hay thậm chí là so với cả Laravel thì WordPress ít nhiều bị đánh giá thấp về hiệu năng. Điều này hoàn toàn có cơ sở khi mỗi website WordPress hiện nay “được trang bị” rất nhiều plugin, khiến việc xử lý dữ liệu trong đó trở nên cồng kềnh và đôi khi là rất khó hiểu.

Nhưng đó là câu chuyện của một website thật sự lớn, nhiều dữ liệu đến mức mà WordPress có thể chưa phù hợp để đáp ứng được. Còn nếu website của bạn là trang giới thiệu về công ty, hay một trang thông tin vài nghìn bài viết, một website bán hàng sử dụng WooCommerce vài trăm sản phẩm với lượt truy cập vài nghìn mỗi ngày, thì không nên bàn sâu vào việc chỉ trích website chậm là do mã nguồn WordPress.

Việc một website của bạn đang bị chậm, đó không phải là triệu chứng mà đó là kết quả của rất nhiều nguyên nhân sâu xa bên trong, mà việc đi tìm những nguyên nhân đó cần sự phân tích rõ ràng. Để bạn dễ hình dung, mình có cố gắng vẽ sơ đồ những gì mà trình duyệt và máy chủ website sẽ thực hiện khi một người dùng truy cập vào website (mình tạm lược bỏ những quy trình liên quan tới xác thực hay các giao thức mã hoá thông tin).

Ghi chú: Trong bài này mình sẽ không nói về website chậm do yếu tố khách quan như chất lượng mạng của người dùng, máy chủ website khác quốc gia của người dùng,…. Và cũng không đề cập đến việc tăng độ chịu tải của website với các kỹ thuật như Load Balancing.
Mình cũng sẽ không đề cập đến phần tối ưu điểm số PageSpeed Insights vì nó sẽ thuộc phạm trù tối ưu trải nghiệm người dùng trên website. Tuy nhiên việc thực hành các kiến thức trong bài có thể giúp bạn cải thiện một chút điểm Google Pagespeed. Mình sẽ viết bài về tối ưu Google PageSpeed hoàn chỉnh sau.

Đầu tiên khi một người nào đó mở trình duyệt thân quen của họ lên và gõ thachpham.com vào thanh địa chỉ, thì trình duyệt sẽ tiến hành bắt tay nói chuyện với máy chủ website qua các bước sau.

Trường hợp ở bốn bước trên mà có vấn đề ở đâu đó, thì có nhiều trò để nói. Ví dụ như nếu máy chủ phân giải tên miền của bạn tự nhiên “mất hứng” thì tốc độ tải trang sẽ còn chậm hơn là chờ trà sữa tan đường. Hay ở bước ba nếu máy chủ web nhận tín hiệu kết nối nhưng làm việc chậm chạp trong việc trả dữ liệu về thì cũng làm chậm website.

Nhưng còn tệ hơn là ba bước đầu đã qua hết trơn rồi, đến bước cuối cùng thì trình duyệt lại “quay xe” không render được đúng ý. Thử tưởng tượng nha, bạn chèn một cửa sổ chat của công cụ Abc.xyz vào website, rồi một hôm đẹp trời Abc.xyz gặp trục trặc. Trình duyệt của bạn vẫn chăm chỉ kết nối tới nhưng đợi hoài, đợi mãi, đợi như ngồi hóng người yêu nhắn tin lại mà cuối cùng thì… timeout. Lúc đó, trình duyệt mới chịu nhận ra Abc.xyz không thèm tải lên, rồi ngậm ngùi tiếp tục xử lý các phần còn lại. Nghe nó cứ sai sai kiểu gì.

Còn nữa chưa hết, giả sử mọi thứ trên trang của bạn tải rất mượt mà rồi nhưng tự nhiên bạn chèn một tấm ảnh dung lượng 30MB vào website. Nó giống như bạn đang nhờ shipper gửi hoả tốc một đơn hàng cho khách, nhưng đơn hàng đó là một cái tủ lạnh ☠️.

Đó thấy chưa, ngay kể cả nói về chuyện tình giữa anh trình duyệt và webserver thôi thì đã có vô số vấn đề rồi, nhưng đó là trường hợp giữa anh trình duyệt và chị webserver giao tiếp một cách suôn sẻ. Nhưng trên thực tế, để anh trình duyệt nhận được dữ liệu từ chị webserver thì còn phải thông qua cô dì chú bác nữa, hãy xem ảnh bên dưới.

Theo đúng thực tế trong WordPress hiện nay, khi webserver nhận tín hiệu “yêu cầu” (cụm từ chuyên nghành là Request) từ người dùng gửi thông qua trình duyệt thì nó sẽ cần phải đi xử lý các logic về yêu cầu đó trong mã nguồn. Dựa vào sơ đồ mình bịa ra ở trên, bạn gặp vấn đề trong bất kỳ khâu nào cũng sẽ kéo tốc độ website đi xuống.

Những bước kiểm tra website bị chậm

Khi một website bị chậm và muốn xử lý triệt để chúng ta sẽ cần kiểm tra hết mọi nguyên nhân để từ đó có hướng xử lý đúng đắn. Việc này có thể sẽ tiết kiệm kha khá chi phí nâng cấp dịch vụ máy chủ website của bạn đó.

Máy chủ nameserver không gặp trục trặc

Hiện nay bất kỳ máy chủ phân giải nameserver nào cũng phải có ít nhất là hai máy chủ, đó là lý do tại sao khi bạn cập nhật nameserver thì lại luôn có hai địa chỉ nameserver. Một số hệ thống nameserver phức tạp còn có số lượng máy chủ rất nhiều dù người dùng chỉ cần sử dụng hai địa chỉ nameserver, ví dụ như CloudFlare. Việc xảy ra lỗi chậm website do máy chủ nameserver rất hiếm nhưng không phải không có, vậy nên khi có website bị chậm thì bạn có thể thử dùng công cụ DNS Performance Tool của DNSPerf hoặc DNSWatch kiểm tra bản ghi tên miền và để ý tốc độ phân giải của bản ghi là bao nhiêu (bỏ qua máy chủ nameserver gốc nhé), thường thì con số này không cao hơn 400ms.

Thông tin thêm: Kết quả kiểm tra tại các công cụ này là tương đối vì đó là tốc độ phân giải từ máy chủ DNSWatch đến máy chủ nameserver, không phản ánh tốc độ thực tế trên máy của bạn. Ví dụ các máy chủ nameserver tại Việt Nam sẽ có tốc độ trên DNSWatch từ khoảng 150ms đến 300ms. Tuy nhiên đây là cách đơn giản để kiểm tra xem tốc độ phân giải có bất thường hay không, hoặc xác định tên miền có đang gặp sự cố phân giải.

Mạng của máy chủ không chập chờn hoặc bị “tạch”

Sau khi đã phân giải thành công địa chỉ máy chủ website của tên miền, thì trình duyệt sẽ tiến hành gửi kết nối đến máy chủ web. Ở bước này bạn cần đảm bảo là máy chủ web đang hoạt động tốt, cụ thể là nếu bạn dùng Web Hosting thì hosting đang không bị chậm hay có sự cố, còn nếu dùng máy chủ riêng/VPS thì đảm bảo không bị nghẽn mạng.

Hiện nay nhiều người dựa vào chỉ số TTFB (Time To First Bytes), tức là thời gian từ khi trình duyệt gửi yêu cầu đến phản hồi bytes đầu tiên từ máy chủ để đánh giá tốc độ xử lý của máy chủ. Tuy nhiên theo quan điểm cá nhân của mình, việc sử dụng chỉ số TTFB có thể gây ra một số nhầm lẫn hoặc không đánh giá đúng, bởi vì:

• Nếu trang có chuyển hướng (hay gặp nhất là tự chuyển hướng từ HTTP qua HTTPS) hay chuyển hướng từ tên miền thachpham.com đến thachpham.com/vi chẳng hạn. TTFB sẽ bao gồm thời gian mà chuyển hướng thực hiện xong.
• Vẫn phải đợi máy chủ xử lý code trong mã nguồn và xử lý dữ liệu từ cơ sở dữ liệu và trả về bytes dữ liệu đầu tiên sau khi xử lý xong. Giả sử nếu có lỗi trong code mà đánh giá thời gian xử lý của server chậm dựa vào TTFB thì thật không công bằng 🫨.

Nếu như sử dụng công cụ DevTools ở trình duyệt Google Chrome/Edge thì ta phân tích kết quả dưới đây.

Đây là hình ảnh báo cáo các giai đoạn xử lý của trang chủ thachpham.com, bạn sẽ thấy khi mất 1.11 mili-giây ở giai đoạn phân giải DNS, sau đó tới bước thiết lập kết nối đến máy chủ là mất 90.38 mili-giây, oke sau đó thời gian TLS/SSL handshake để thiết lập kết nối an toàn là mất thêm 49.63 mili-giây. Như vậy tổng thời gian mà tốc độ máy chủ phản hồi ở giai đoạn này là khoảng 140 mili-giây.

Sau đó yêu cầu gửi đi, và thời gian waiting for server response ở đây là 437.32 giây, đây chính là chỉ số TTFB. Nhưng bạn có nhận ra nghịch lý là nếu chúng ta cho rằng TTFB phản ánh đúng tốc độ phản hồi của máy chủ, thì tại sao nó hoàn thành Initial connection và TLS/SSL handshake chỉ bằng phân nửa? Vì nửa còn lại là thời gian mà máy chủ xử lý code và trả dữ liệu về.

Trường hợp nếu máy chủ đang gặp trục trặc về mạng, thì chỉ số Initial connection và SSL/TLS Handshake sẽ khá cao. Vì vậy khi kiểm tra TTFB bạn phải đặc biệt lưu ý vào các chỉ số này để đánh giá chính xác. Nếu thời gian phản hồi của máy chủ nhanh, nhưng TTFB quá cao thì sẽ kiểm tra thêm những nguyên nhân phía dưới.

Vậy làm sao để đo thời gian phản hồi đầu tiên của máy chủ mà không bao gồm thời gian đợi máy chủ xử lý hoàn tất? Có một cách nhưng nó hơi lòng vòng một xíu, đó là sử dụng cURL để kiểm tra.

Bây giờ bạn tạo một tập tin tên curl-format.txt trên máy tính với nội dung sau:

time_namelookup:  %{time_namelookup}\n
time_connect:  %{time_connect}\n
time_appconnect:  %{time_appconnect}\n
time_pretransfer:  %{time_pretransfer}\n
time_redirect:  %{time_redirect}\n
time_starttransfer:  %{time_starttransfer}\n
time_total:  %{time_total}\n

Sau đó bạn chạy lệnh curl như sau để kiểm tra và nó sẽ hiển thị kết quả chi tiết (nhớ điều chỉnh path đến tập tin curl-format.txt cho chính xác.

curl -w "@curl-format.txt" -H "Cache-Control: no-cache" -o /dev/null -s "https://thachpham.com"

Kết quả phản hồi giống như sau (giá trị thời gian sử dụng là giây).

• time_namelookup: 0.001735
• time_connect: 0.043327
• time_appconnect: 0.089643
• time_pretransfer: 0.089719
• time_redirect: 0.000000
• time_starttransfer: 0.136304
• time_total: 0.136474

Ở kết quả trên, bạn có thể nhìn vào kết quả của time_pretransfer nghĩa là thời gian hoàn thành tất cả các bước chuẩn bị để gửi yêu cầu đến máy chủ nhưng chưa gửi đến máy chủ xử lý, bao gồm thời gian truy vấn DNS (time_namelookup), thời gian hoàn tất kết nối TCP với máy chủ (time_connect), thời gian hoàn tất thiết lập giao thức kết nối an toàn nếu có (time_appconnect). Con số này có thể đánh giá thời gian phản hồi ban đầu của máy chủ. Sau đó, bạn có thể sử dụng kết quả của time_starttransfer là chỉ số TTFB để đánh giá có gì bất thường hay không.

Tham khảo: A Question of Timing – CloudFlare Blog

Thông tin thêm: Chỉ số TTFB sẽ thay đổi nếu như website có dùng cache hay không.

Kiểm tra quá trình xử lý mã nguồn và database

TTFB sẽ bị ảnh hưởng nếu như quá trình xử lý bên trong mã nguồn gặp vấn đề. Mà khi nói đến việc xử lý bên trong mã nguồn thì lại có thể bắt nguồn từ nhiều tác nhân khác nhau, nhưng trong WordPress thì thường xảy ra lỗi từ trong plugin hoặc theme đang sử dụng chưa tối ưu.

Bật WP_DEBUG để kiểm tra lỗi của PHP

Debug trong WordPress là bước đầu tiên cần làm để có thể kiểm tra và loại trừ một số nguyên nhân gây chậm website do lỗi PHP gây ra. Bắt đầu bằng việc mở tập tin wp-config.php tìm define('WP_DEBUG', false) và chỉnh thành define('WP_DEBUG', true) và chèn thêm đoạn sau để lưu log debug vào thư mục wp-content/.

define('WP_DEBUG_LOG', true);

Lúc này bạn có thể theo dõi thư mục wp-content/ để xem tập tin debug.log có sinh ra nội dung lỗi hay không và lúc này sẽ cần đọc lỗi để dò tìm xem có các lỗi nghiêm trọng (Fatal Error) nào, xảy ra ở tập tin plugin hay theme nào và thử vô hiệu hoá chúng.

Ngoài ra việc sử dụng phiên bản PHP không phù hợp cũng gây ra các cảnh báo ở đây, nếu bạn đang sử dụng phiên bản PHP thấp như PHP 7, thì hãy cân nhắc nâng cấp lên phiên bản PHP 8.2 theo khuyến nghị của WordPress.

Sử dụng WP_Debug để kiểm tra truy vấn database

Một thao tác nữa cũng rất cần thiết khi kiểm tra website WordPress bị chậm đó là sử dụng plugin Query Monitor để dò tìm trên website có truy vấn đến database gây chậm cho website hay không, hay website có đang quá nhiều action hook cần thực hiện mỗi khi tải lại trang.

Khi cài Query Monitor xong thì bạn có thể truy cập vào trang đang chậm nhất và nhấp vào kết quả của Query Monitor trên thanh công cụ quản trị để xem chi tiết các báo cáo. Ở đây nó sẽ hiển thị thời gian tải trang, khi ấn vào xem chi tiết nó sẽ cho bạn biết tổng số lượng các truy vấn đến database cùng thời gian xử lý truy vấn, và danh sách các action hook mà trang sẽ kích hoạt

Nếu website WordPress do bạn hoàn toàn tự làm theme và viết plugin thì sẽ có thể tận dụng được nhiều hơn, còn ở đây đa phần chúng ta sử dụng theme có sẵn và các plugin cũng được “bày” sẵn nên thường sẽ không nên (hoặc không thể) tinh chỉnh lại dựa vào kết quả của Query Monitor. Nhưng ít nhất nếu website của bạn đang có Database Queries với thời gian trên 2 giây thì ít nhiều trên website đang có phần nào đó sử dụng truy vấn chưa tối ưu, hoặc database quá nặng dẫn tới các truy vấn bị chậm.

Khi xem chi tiết ở mục Database Queries, bạn có thể xem query nào đang cần nhiều thời gian xử lý nhất và từ đó cân nhắc xem query đó đến từ tính năng nào (ví dụ query select lấy bài viết ra hiển thị có thể do một tính năng hiển thị bài viết trên trang đang xem gây ra) từ đó cân nhắc bỏ nó đi, hoặc xem lại dung lượng database có quá lớn hay không dẫn đến trang bị chậm.

Tổng thời gian truy vấn đến database trong trang theo mình là không nên vượt quá 1 giây.

Thông tin thêm: Hình ảnh chụp ở trên là tổng thời gian xử lý truy vấn ở trang chủ azdigi.com/blog có hơn 2.200 bài viết.

Trường hợp website của bạn là bắt buộc phải có nhiều truy vấn lấy dữ liệu, số lượng bài viết rất nhiều thì cân nhắc sử dụng cấu hình web hosting hoặc VPS/máy chủ mạnh hơn. Ví dụ như dịch vụ Turbo Business Hosting sinh ra để giải quyết vấn đề này, mình xin quảng cáo chút 😍. Cùng với đó là sử dụng thêm kỹ thuật Object Cache để website không thực hiện gửi truy vấn liên tục đến database để lấy dữ liệu, phần này mình sẽ nói rõ hơn ở phần hai của bài viết này, nhưng bạn cẩn thận vì Object Cache chỉ có tác dụng với một website đang bị nghẽn cổ chai liên quan đến database, còn nếu trang của bạn đang có thời gian truy vấn database nhanh thì không cần thiết, đó là lý do tại sao ở ảnh trên của mình bạn sẽ thấy là trang đó không dùng Object Cache.

Kiểm tra plugin/theme gây chậm với Code Profiler

Thời gian qua mình có biết thêm một plugin khác trong việc xác nhận xem trên website thành phần gây chậm là do theme hay do plugin nào, plugin đó mang tên Code Profiler.

Sau khi cài plugin này xong, bạn có thể tiến hành profiling để thu thập dữ liệu xử lý. Khi chạy profiling bạn lưu nên chạy với một người dùng để đánh giá chính xác vì khi chạy với người dùng thì sẽ bỏ qua cache của website. Đồng thời nên chạy ở trang mà bạn đang gặp vấn đề chậm.

Kết quả trả về sẽ là đồ thị so sánh thời gian xử lý của theme và các plugin đang kích hoạt. Thường thì kết quả cao nhất sẽ là của theme, vì các phần hiển thị nội dung ra bên ngoài là theme quyết định và một theme độ phức tạp cao sẽ cần nhiều thời gian xử lý hơn, điều tương tự cũng xảy ra với plugin. Bạn đừng vội đánh giá các plugin và theme này chưa tối ưu, vì vấn đề đôi khi là do website của bạn quá nhiều nội dung thì kết quả cũng cao hơn với một website dùng plugin tương tự nhưng ít nội dung hơn.

Nhưng ít ra dựa vào kết quả này cũng cho bạn cái nhìn tổng thể phần nào trên trang đang tiêu thụ công suất nhiều nhất.

Kiểm tra dữ liệu máy chủ trả về cho trình duyệt

Sau khi máy chủ đã hoàn tất lấy dữ liệu cần thiết thì nó sẽ trả dữ liệu về cho trình duyệt nhằm render hiển thị ra bên ngoài cho chúng ta xem. Một drama khác sẽ bắt đầu.

Bạn đã từng tải một file gì đó trên mạng về rồi đúng không, vi dụ bạn tải một tập tin nặng 10MB về máy thì sẽ mất bao lâu? Khi chúng ta thực hiện truy cập vào website, thực chất là trình duyệt đang tiến hành tải nội dung trên trang về và hiển thị ra, giả sử trang của bạn có tấm ảnh nặng bằng cái tủ lạnh mình có nhắc tới ở đầu bài thì trình duyệt sẽ cần nhiều thời gian tải trang hơn.

Để kiểm tra phần này ta sẽ dùng tính năng Network trong công cụ DevTool của trình duyệt hệ Chromium như Google Chrome, Microsoft Edge trên trình duyệt ẩn danh, thao tác như video bên dưới.

Và khi chạy xong bạn để ý con số kết quả trả về ở phía dưới như thế này.

Ở đây chúng ta sẽ biết được tổng dung lượng các tài nguyên trên website đang sử dụng là bao nhiêu, trong đó có bao nhiêu đã tải về. Nếu trang của bạn đang có dung lượng tài nguyên tải về lên đến 20, 30MB thì có thể xem chi tiết các tập tin nào có dung lượng cao bằng cách lọc theo cột Size ở trên.

Kế tiếp bạn để ý chỉ số DOMContentLoaded và so sánh nó với Load và Finish. Ý nghĩa các thông số là:

• DOMContentLoaded: Thời gian mà trình duyệt hoàn tất tải cấu trúc nội dung HTML để hoàn tất xây dựng cấu trúc DOM và không bao gồm thời gian tải các tài nguyên khác như CSS, Javascript, hình ảnh. Con số này sẽ cho bạn biết cấu trúc HTML của trang được render ra có quá nặng hay không, và cấu trúc này sẽ do theme hoặc các plugin builder khác như Elementor quyết định. Ngoài ra ta cũng lưu ý, các thẻ <scripts> trong trang mà không có thuộc tính defer hay async thì cũng sẽ được tính vào DOMContentLoaded.
• Load: Thời gian mà trình duyệt tải toàn bộ tài nguyên trên website bao gồm cấu trúc DOM, CSS, Javascript, Iframe,…Đây là con số hiệu quả nên dùng để đánh giá thời gian tải thực tế của website ở ngoài trình duyệt.
• Finish: Trước khi nói sâu mình xin phủ đầu bằng việc khuyến nghị không nên dựa vào con số Finish này để đánh giá tốc độ website. Vì con số này sẽ tính từ lúc request đầu tiên của phiên làm việc trình duyệt đến sự kiện cuối cùng của các tài nguyên được nhận từ máy chủ. Điều này có nghĩa là sau khi website được tải, nếu trên trang có các request sử dụng công nghệ AJAX để lấy dữ liệu thì nó sẽ tiếp tục tính lên, hoặc nếu website của bạn có dùng Lazy Load để tối ưu thời gian tải các thành phần trên trang thì con số Finish cũng sẽ cộng thêm mỗi khi trang tiếp tục tải thành phần đó.

Tóm lại:

• Nếu dung lượng transferred quá cao thì cần giảm bớt tài nguyên trên website (chủ yếu là hình ảnh, các tập tin .js bên thứ ba).
• Nếu DOMContentLoaded quá cao thì nghĩa là cấu trúc trang của bạn đang quá cồng kềnh, nên tối ưu lại hoặc lược bỏ bớt các cấu trúc không cần thiết. Cái này sẽ cần yêu cầu kinh nghiệm kỹ thuật để xử lý. Nếu bạn đang dùng Elementor hoặc các page builder khác thì cân nhắc không nên dùng quá nhiều container để chia cấu trúc trang, hoặc lược bỏ các phần không cần thiết. Có thể sử dụng kỹ thuật minify HTML để làm gọn cấu trúc DOM và lược bỏ các phần không cần thiết.
• Nếu số Load quá cao thì cân nhắc giảm bớt lượng request ở trình duyệt bằng cách áp dụng kỹ thuật minification cho CSS, Javascript, bật Lazy Load cho hình ảnh để giảm bớt số lượng request kết nối.

Ở trên là một số kiểm tra cần thiết để xác định nguyên nhân làm chậm cho webiste WordPress. Phần tiếp theo trong bài này sẽ nói về các giải pháp xử lý cho từng phần gây chậm.

Các giải pháp tăng tốc website WordPress

Sở dĩ mình mất công trình bày một cách dài dòng ở trên cốt yếu cũng chỉ muốn làm rõ vấn đề sâu xa tại sao website WordPress trở nên chậm chạp. Một khi vấn đề đã được làm rõ thì sẽ dễ dàng trong việc áp dụng các biện pháp xử lý thật chi tiết như bên dưới. Hãy cùng nhìn lại sơ đồ mình bịa ra ở đầu bài để chúng ta sẽ từng bước giải quyết các nút thắt trong sơ đồ này, lúc này website của bạn sẽ nhanh mất kiểm soát 🫨.

Biện pháp 1. Sử dụng nameserver tốt

Nameserver tốt nghĩa là một máy chủ nameserver có khả năng truy vấn phân giải các bản ghi DNS một cách nhanh chóng nhất, thẳng thắn luôn là bạn nên sử dụng nameserver của CloudFlare đi (có thể không cần bật proxy CloudFlare nếu thích) vì họ là một dịch vụ Web Application Firewall thông qua máy chủ proxy tốt hàng đầu hiện nay, nên dĩ nhiên hệ thống nameserver của họ phải thật sự tốt để gánh.

Biện pháp 2. Tối ưu hoá kết nối TCP và thời gian SSL/TLS Handshake

HIện nay hầu hết các website đều phải sử dụng giao thức HTTPS để mã hoá thông tin gửi và nhận trong kết nối để đảm bảo an toàn, dù muốn hay không, chứ không dùng thì vào website không qua giao thức HTTPS nó sẽ hiện dòng chữ “Không An Toàn” ở thanh địa chỉ là muối mặt.

Dĩ nhiên quá trình SSL/TLS Handshake sẽ không tốn quá nhiều thời gian trong cả quy trình chuẩn bị kết nối, nhưng nếu bạn thích trải nghiệm thì có thể thử đổi qua chứng chỉ SSL sử dụng mã hoá ECC thay vì RSA phổ biến hiện nay.

Và quan trọng nhất, website của bạn phải nên sử dụng HTTP/3 để cải thiện tốc độ thông qua việc sử dụng giao thức UDP thay cho TCP, từ đó tổng thể website sẽ giảm lượng kết nối TCP và cho phép tải nhiều tài nguyên hơn trên cùng một kết nối khi sử dụng giao thức an toàn HTTPS.

Để kiểm tra máy chủ website của bạn có đang hoạt động với HTTP/3 hay chưa thì có thể kiểm tra thông qua công cụ http3check.net, nếu chưa có thì có thể hỏi đơn vị cung cấp hosting hoặc cấu hình lại webserver trên máy chủ.

Lưu ý: Tính năng chặn BOT trên CloudFlare có thể sẽ chặn truy cập kiểm tra.

Biện pháp 3. Tối ưu hoá xử lý mã nguồn trên server

Quá trình xử lý trên server sẽ bao gồm việc xử lý các logic trong mã nguồn, xử lý truy vấn trong database. Quá trình này sẽ chiếm phần lớn thời gian trong cả quá trình kết nối tới website nên bạn cần lưu ý hơn nhé.

Trong WordPress, đầu tiên bạn cần cân nhắc nên tắt bớt các plugin không cần thiết hoặc đang không sử dụng, chỉ giữ lại các plugin mà website bạn đang bắt buộc phải có để giảm thiểu thời gian xử lý các action hook và truy vấn vào database liên quan mỗi khi trang được tải.

Thông qua việc bật WP_DEBUG như mình có đề cập ở trên, bạn sẽ biết được website đang có các cảnh báo (warning) hay lỗi nghiêm trọng (fatal error) nào đang có hay không và cố gắng dọn sạch chúng (đôi khi mình cũng hay xử lý bằng cách…tắt luôn plugin đang cảnh báo cho xong nếu có quá nhiều cảnh báo ☠️).

Kỹ thuật Object Cache

Trường hợp nếu website của bạn có quá nhiều truy vấn vào database, hoặc database nặng thì nên sử dụng Object Cache để giảm tần suất mã nguồn gửi truy vấn vào database để lấy dữ liệu. Trường hợp đặc trưng cụ thể là các trang tạp chí, blog nhiều bài viết, WooCommerce nhiều sản phẩm,…

Object Cache là một hệ thống lưu trữ tạm thời các đối tượng dữ liệu (Object) vào bộ nhớ và tái sử dụng khi cần thiết để tránh phải xử lý lại hoặc gửi lại truy vấn vào database. Đối tượng ở đây trong WordPress là các dữ liệu liên quan tới bài viết, các tuỳ chỉnh lưu trong bảng wp_options,…Bạn lưu ý ở đây đối tượng bài viết mình nhắc tới sẽ bao gồm tất cả các dữ liệu của post type trong WordPress, bao gồm các sản phẩm nếu sử dụng WooCommerce vì bản chất các post type này cũng đều được lưu trữ vào bảng wp_posts và wp_postmeta.

Để kích hoạt Object Cache, bạn có thể hỏi đơn vị cung cấp Hosting bạn đang sử dụng có đang hỗ trợ Redis (AZDIGI có nè) hoặc Memcached hay không. Nếu có hỗ trợ Redis thì bạn cài plugin Redis Object Cache, nếu có hỗ trợ Memcached thì cài plugin Memcached Object Cache. Nếu đang dùng VPS/Máy chủ thì tự cài đặt hoặc nhờ chuyên gia để cài đúng cách dựa vào các phần mềm đang sử dụng là gì sẽ có các cách cài khác nhau.

Nếu website WordPress của bạn chỉ có vài trang nội dung giới thiệu thì Object Cache sẽ chưa phát huy hiệu quả. Còn với các website có khả năng làm mới dữ liệu liên tục theo thời gian thực thì tránh sử dụng Object Cache vì lúc này dữ liệu lưu trong bộ nhớ sẽ phải làm mới liên tục, có khi từ bệnh thành què luôn.

Nếu bạn đang sử dụng VPS/Máy chủ với số bộ nhớ RAM hạn chế thì cũng không nên dùng Object Cache vì Redis hay Memcached sẽ lưu bộ nhớ tạm vào RAM.

Sử dụng Opcache cho PHP

Có thể sẽ hơi thừa khi nói lại rằng WordPress là mã nguồn được viết bằng PHP, nên việc tối ưu PHP xử lý nhanh cũng là tăng tốc mã nguồn WordPress chạy mượt hơn. Nhưng mình cứ nói lại cho chắc vì nhiều khi đang nói về WordPress mà nghe phân tích về PHP hơi lùng bùng.

Lưu ý: Trong bài có nhắc đến Opcache và Opcode. Trong khi Opcode để nói đến mã lệnh trong nghành khoa học máy tính, còn Opcache là một kỹ thuật lưu bộ nhớ đệm cho các Opcode. Quá trình tạo ra và xử lý Opcode mình có giải thích ở dưới.

PHP là một ngôn ngữ thông dịch (Interpreted Language) nên khi hoạt động nó sẽ thực thi từng đoạn mã thông qua một trình thông dịch (Interpreter) mà không cần chuyển qua mã máy. Trình thông dịch đóng vai trò biên dịch từng phần và thực thi ngay lập tức, thay vì trải qua giai đoạn tiền biên dịch (pre-compilation) như các ngôn ngữ biên dịch khác.

PHP sử dụng Zend Engine làm engine và quá trình thực thi một đoạn mã PHP sẽ trải qua các bước như sau:

• Bước 1. Trình thông dịch bên trong PHP bắt đầu đọc mã.
• Bước 2. Zend Engine tham gia vào việc parsing (phân tích cú pháp), kiểm tra lỗi và thực thi. Nếu trót lọt không có lỗi phải gì nó sẽ tạo ra một Cây cú pháp trừu tượng (AST) cho đoạn mã đó.
• Bước 3. Zend Engine sẽ thực hiện chuyển AST đã tạo ra ở bước 2 và biên dịch thành Opcode.
• Bước 4. Zend Engine thực thi các opcode đã tạo ra và gửi kết quả phản hồi.

Và nếu chúng ta có sử dụng Opcache thì lần thực thi đầu tiên sẽ bao gồm 4 bước trên, nhưng sau khi thực hiện bước 3 nó sẽ lưu các opcode đó vào bộ nhớ RAM. Các lần thực thi sau nó chỉ cần đọc mã ở bước 1 và lấy dữ liệu opcode đã lưu trữ trong bộ nhớ để xử lý ở bước 4, không có bước 2 và bước 3.

Mình tin là bạn không cần phải biết tí gì về khoa học máy tính (mình cũng vậy) cũng hiểu được là khi dùng Opcache nó sẽ giúp chúng ta tăng tốc quá trình xử lý PHP rồi đó.

Để bật Opcache trên Web Hosting, bạn có thể nhờ kỹ thuật của nhà cung cấp dịch vụ kiểm tra hoặc truy cập vào tính năng Select PHP Version trên cPanel/DirectAdmin và xem đã bật extension opcache hay chưa và đánh dấu bật nó lên.

Nếu bạn dùng VPS/Máy chủ riêng thì hãy kiểm tra PHP được cài đặt đã có opcache hay chưa và tìm tài liệu bật lên dựa theo phần mềm sử dụng. Có thể kiểm tra bằng lệnh php -i | grep "opcache.enable" để xem opcache có On hay không.

Làm gọn database và kiểm tra liên kết khoá ngoại

Khi chúng ta truy cập một trang (trong trường hợp là trang không sử dụng kỹ thuật Page Cache) thì các truy vấn đến database được xác định trong mã nguồn sẽ thực hiện để lấy dữ liệu và hiển thị ra bên ngoài. Đây là một ví dụ cú pháp truy vấn dữ liệu của một bài viết có ID là 123.

SELECT * FROM wp_posts WHERE ID = 123;
SELECT * FROM wp_postmeta WHERE post_id = 123;

Lúc này, MySQL sẽ đi tìm dữ liệu bài viết trong database có cột ID với giá trị là 123 và hiển thị ra ngoài, đây là cách mà tính năng Indexing hoạt động trong MySQL với mục đích lấy đúng dữ liệu cần lấy (ở đây là chỉ quét cột ID tìm ra giá trị 123) thay vì phải quét toàn bộ dữ liệu trong bảng wp_posts và wp_postmeta để tìm ra giá trị ID = 123.

Nhưng có một số trường hợp mình có thấy nhiều website bị mất thuộc tính INDEXES trên cột ID mặc dù nó vẫn tồn tại, thì website vẫn hoạt động nhưng hiệu năng bị chậm đi đáng kể. Vì vậy nếu bạn thấy website của bạn bị chậm bất thường ở database thì hãy kiểm tra các bảng đang dùng trong website có bị thiếu thuộc tính INDEXES không, bằng cách tạo một tập tin ví dụ tên check_indexes.php ở thư mục gốc website WordPress và copy đoạn mã này vào:

Lưu ý: Sau khi dùng file này thì xoá ngay để tránh rò rỉ thông tin không mong muốn.

<?php
// Đảm bảo rằng tập tin chỉ được chạy thông qua trình duyệt
if (php_sapi_name() !== 'cli') {
    // Load môi trường WordPress
    require_once('wp-load.php');

    global $wpdb;

    // Lấy danh sách tất cả các bảng trong cơ sở dữ liệu hiện tại
    $tables = $wpdb->get_results("SHOW TABLES", ARRAY_N);

    echo "<h1>Kiểm tra chỉ mục (Indexes) trong các bảng cơ sở dữ liệu</h1>";

    foreach ($tables as $table) {
        $table_name = $table[0];
        echo "<h2>Bảng: $table_name</h2>";

        // Lấy thông tin các chỉ mục (Indexes) cho bảng hiện tại
        $indexes = $wpdb->get_results("SHOW INDEXES FROM $table_name", ARRAY_A);

        if (!empty($indexes)) {
            echo "<table border='1' cellpadding='5' cellspacing='0'>";
            echo "<tr><th>Tên chỉ mục</th><th>Cột</th><th>Loại chỉ mục</th></tr>";

            foreach ($indexes as $index) {
                echo "<tr>";
                echo "<td>{$index['Key_name']}</td>";
                echo "<td>{$index['Column_name']}</td>";
                echo "<td>" . ($index['Non_unique'] == 0 ? 'Unique' : 'Non-Unique') . "</td>";
                echo "</tr>";
            }

            echo "</table>";
        } else {
            echo "<p>Bảng này không có chỉ mục nào.</p>";
        }

        echo "<hr>";
    }
} else {
    echo "Tập tin này không nên chạy từ dòng lệnh.";
}
?>

Sau đó truy cập file này trên trình duyệt với đường dẫn https://tên-miền-của-bạn.tld/check_indexes.php để có kết quả kiểm tra, nếu bảng database đã có INDEXES thì nó sẽ hiển thị cấu trúc ra như ảnh dưới, còn nếu bạn thấy tên bảng hiển. thị nhưng không có gì thì đã bị mất thuộc tính INDEXES và gây chậm website.

Để khôi phục lại INDEXES thì bạn có thể sử dụng lệnh sau để tái tạo lại thuộc tính INDEXES cho cột, ví dụ áp dụng với cột meta_id trong bảng wp_postmeta. Nhớ thay wp_ thành tiền tố bảng database phù hợp.

ALTER TABLE wp_postmeta
ADD PRIMARY KEY (meta_id);

Bạn có thể tra cứu các cột INDEXES trong các bảng thuộc mã nguồn WordPress tại đây.

Sử dụng plugin tạo Full Page Caching

Full Page Caching được sử dụng rất rộng rãi trong WordPress, nó sẽ hoạt động bằng cách lưu toàn bộ nội dung của một trang nào đó thành một tập tin .html và lưu vào hosting/máy chủ để sử dụng khi người dùng truy cập. Nếu bạn đã từng nghe nói đến các plugin như WP Rocket, LiteSpeed Cache, WP Fastest Cache,…thì nó đều sử dụng kỹ thuật này để giúp tăng tốc website.

Cách hoạt động của nó là ở lần truy cập đầu tiên trên một trang (ví dụ như nội dung của 1 bài viết) thì nó sẽ thực hiện lưu nội dung cả trang đó thành tập tin .html vào ổ cứng máy chủ, gọi là cache. Ở các truy cập sau khi vào một trang đã có dữ liệu cache của nó thì máy chủ sẽ mang tập tin đó ra cho trình duyệt đọc thay vì thực thi mã PHP và truy vấn MySQL. Điều này giúp giảm đáng kể áp lực xử lý trên máy chủ, đồng thời người dùng cũng sẽ tải trang nhanh hơn vì nội dung gửi cho trình duyệt là tập tin HTML đã được “bày” sẵn nội dung mà không cần đợi logic trong PHP và database xử lý. Ngoài ra, kỹ thuật này còn giúp giảm đáng kể thời gian TTFB ở trình duyệt.

Nếu bạn cần một plugin miễn phí hỗ trợ đủ các tính năng cần thiết thì nên sử dụng plugin WP Fastest Cache hoặc LiteSpeed Cache, sau khi kích hoạt thì bạn bật tuỳ chọn Cache System là xong. Nó cũng có hỗ trợ một số tính năng hay khác mà bạn có thể bật lên. Các phần khác trong bài viết này sẽ có vài tính năng mà plugin này có hỗ trợ.

Thường xuyên tối ưu dung lượng database

Dung lượng database của website theo thời gian sẽ dần trở nên to ra, và đôi khi cũng do một số plugin nào đó gây ra tình trạng dung lượng database của bạn trở nên to bất thường mà không hay biết.

Để kiểm tra dung lượng database, bạn có thể thực hiện kiểm tra tại giao diện phpMyAdmin tích hợp sẵn trong hosting, hoặc sử dụng plugin Advanced Database Cleaner để kiểm tra dung lượng đồng thời có tính năng xoá các thành phần không cần thiết trong cơ sở dữ liệu được sinh ra theo thời gian.

Biện pháp 4. Tối ưu hoá thời gian phản hồi TTFB

Thời gian phản hồi TTFB của website sẽ phụ thuộc vào hai yếu tố đó là tốc độ xử lý mã nguồn trên máy chủ và nội dung trả về cho trình duyệt. Ở phần giải pháp 3, nếu bạn đã tối ưu đúng cách thì chỉ số TTFB cũng sẽ được cải thiện. Trong phần này, mình sẽ nói về các kỹ thuật có thể áp dụng để tối ưu nội dung gửi về cho trình duyệt, để làm sao trình duyệt render nội dung nhanh nhất có thể.

Kỹ thuật Minification

Minification là một thuật ngữ chung được sử dụng để giúp loại bỏ các ký tự không cần thiết, khoảng trắng trong mã,…để giúp việc đọc mã nhanh hơn, giảm kích thước tập tin của mã.

Trong WordPress thì chúng ta sẽ ứng dụng kỹ thuật minifcation này vào việc tối ưu tập tin CSS, Javascript và cấu trúc HTML của trang, nó được gọi là Minify CSS, Minify Javascript và Minify HTML ở nhiều nơi.

Hiện nay các plugin hỗ trợ tạo cache cho website như WP Fastest Cache, LiteSpeed Cache hay WP Rocket đều có hỗ trợ thêm tính năng minify, vì vậy bạn có thể bật nó lên. Rất tiếc là tính năng minify cho Javascript chỉ có trên bản trả phí của WP Fastest Cache, nhưng thôi kệ không cần.

Tính năng Minify này theo mình thấy là khá hữu ích trong nhiều trường hợp và khuyên mọi người nên dùng, trừ trường hợp nó không thể giải quyết vấn đề render-blocking mà mình sẽ đề cập ở dưới.

Sử dụng Gzip/Brotli

Gzip là một công nghệ nén các tập tin HTML, CSS, Javascript và HTML lại để gửi tới trình duyệt nhanh hơn nhờ vào việc giảm dung lượng của các tài nguyên này. Điều này sẽ giúp máy chủ vừa tiết kiệm băng thông mà trình duyệt cũng render nhanh hơn.

Nói về các công nghệ nén thì có rất nhiều như Gzip, Brotli, Zstandard (Zstd), LZ4,…nhưng số đó Gzip vẫn phổ biến hơn nhưng Brotli hiện tại là lựa chọn tốt hơn vì ưu điểm có độ nén cao hơn Gzip và quan trọng là phù hợp với website vì nó hỗ trợ tập tin HTML, CSS, Javascript tốt hơn. Tuy nhiên Brotli có nhược điểm là tốc độ nén ở tập tin ở cấp độ nén cao chậm hơn Gzip, nhưng với website thì không cần vì cấp độ nén sử dụng trong nén các tập tin trong website thường là cấp độ thấp.

Để kiểm tra website của bạn đã có Brotli chưa thì hãy sử dụng công cụ kiểm tra tools.keycdn.com/brotli-test. Nếu bạn đang dùng Web Hosting mà lại chưa có Brotli thì hãy hỏi nhà cung cấp dịch vụ.

Sử dụng DNS-Prefetch và Prefetch cho tài nguyên bên thứ ba

Hiện nay hầu hết website nào ít nhiều sẽ có kết nối ra một website khác bên ngoài, ví dụ sử dụng Google Fonts, Google Analytics,…và tất cả các tài nguyên này sẽ có tác động đến hiệu năng của website.

Trong trường hợp này, chúng ta có thể sử dụng tới tính năng dns-prefetch và prefetch được hỗ trợ bởi các trình duyệt để tối ưu hơn.

DNS-Prefetch và cách dùng

Như ở đầu bài viết mình có đề cập, bước đầu tiên để trình duyệt thực hiện một kết nối khi truy cập vào website là phân giải địa chỉ máy chủ của tên miền được khai báo trong các bản ghi DNS thông qua Nameserver. Nếu website của bạn có chèn các liên kết ra bên ngoài trong website thì trình duyệt cũng thực hiện quy trình tương tự để kết nối.

DNS-Prefetch sinh ra là để giải quyết nhu cầu muốn ra lệnh cho trình duyệt thực hiện phân giải trước tên miền của bên thứ ba để để sử dụng trong tương lai. Nghĩa là sau khi dns-prefetch cho một tên miền được xử lý, các request sau nó sẽ bỏ qua bước phân giải mà kết nối trực tiếp.

Để sử dụng tính năng này, bạn sẽ cần khai báo tên miền cần thực hiện dns-prefetch trước thông qua thẻ HTML <link rel="dns-prefetch" href="DOMAIN" /> trong website. Ví dụ:

<link rel="dns-prefetch" href="//fonts.googleapis.com">

Phải lưu ý rằng, dns-prefetch sẽ phân biệt sub-domain và domain chính. Nghĩa là nếu bạn khai báo dns-prefetch cho sub-domain thì nó sẽ chỉ phân giải trước đúng sub-domain đó, và ngược lại nó sẽ không phân giải sub-domain nào nếu bạn chỉ khai báo domain chính.

Cấu trúc đường dẫn domain trong dns-prefetch khai báo nên dùng cú pháp tương đối là //domain.ltd thay vì cú pháp tuyệt đối https://domain.ltd. Điều này sẽ làm trình duyệt thực hiện yêu cầu đến HTTPS hay HTTP thay vì thực tế là không cần. Cú pháp này sẽ sử dụng giao thức mà người dùng đang truy cập vào website của bạn.

Cảnh báo: Chúng ta chỉ nên khai báo dns-prefetch chính xác với những website thứ ba đang kết nối, không nên lên mạng copy một danh sách bỏ vào vì sẽ làm gánh nặng phân giải DNS ở trình duyệt của người dùng.

Câu hỏi đặt ra: “Tôi còn không nắm rõ website của tôi đang kết nối qua bên thứ ba nào để dùng dns-prefetch“.

Câu trả lời là bạn copy đoạn code bên dưới và mở DevTool trên trình duyệt lên, chọn Console và paste vào rồi enter, thanh-kiu ChatGPT:

(function() {
  const thirdPartyDomains = new Set();
  const currentDomain = window.location.hostname;

  // Thu thập tất cả các tài nguyên từ Performance API
  performance.getEntriesByType('resource').forEach((resource) => {
    const resourceURL = new URL(resource.name);
    const resourceDomain = resourceURL.hostname;
    
    // Chỉ lưu các domain không phải domain hiện tại
    if (resourceDomain !== currentDomain) {
      thirdPartyDomains.add(resourceDomain);
    }
  });

  // Tạo thẻ <link> cho mỗi domain bên thứ ba
  let links = "";
  thirdPartyDomains.forEach((domain) => {
    links += `<link rel="dns-prefetch" href="//${domain}">\n`;
  });

  console.log(links);
})();

Sau đó bạn chèn kết quả trả về vào cặp thẻ <head></head> trong theme đang dùng. Có thể sử dụng plugin Insert Scripts to Header and Footer để chèn vào cặp này nhanh chóng.

Cũng xin nói thêm rằng, kết quả phân giải ở DNS ở trình duyệt sẽ lưu vào bộ nhớ tạm của trình duyệt và thời gian lưu vào sẽ quyết định bởi thông số TTL (Time to Live) của bản ghi DNS. Đây cũng là câu trả lời cho bạn nếu như trước đó bạn có sửa DNS và thấy TTL nhưng không rõ nó là gì.

Sử dụng Preload

Nếu dns-prefetch là thực hiện phân giải DNS trước của các tên miền bên thứ ba, thì preload là một thao tác tải trước các tài nguyên quan trọng để sẵn sàng cho quá trình render nội dung của trang. Điều này sẽ giúp đảm bảo các tài nguyên thật sự quan trọng tải ra trước tránh tình trạng có độ trễ gây cản trở trải nghiệm mượt mà của người dùng.

Trường hợp sử dụng thiết thực nhất cho tính năng preload này là sử dụng nó để tải trước các font chữ ở Google Fonts và preload cho hình ảnh lớn xuất hiện đầu trang (Above-the-Fold) để cải thiện điểm số LCP trong PageSpeed.

Các tập tin được preload hỗ trợ hiện nay là font chữ, .css, .js, hình ảnh, video, audio, iframe và tập tin .html.

Bây giờ bạn có thể thực hiện preload bằng cách chèn đoạn sau vào cặp <head></head> của website hoặc thông qua plugin Insert Scripts in Footer and Header theo cấu trúc sau:

<link rel="preload" as="image" href="//domain.ltd/banner.jpg" crossorigin="anonymous" />

Trong đó bạn thay as="image" thành loại tập tin đang cần chèn (audio, document, style, script, font) và liên kết tới thành phần cần preload trước.

Bạn không nên lạm dụng preload quá nhiều mà chỉ nên preload thành phần nào chắc chắn cần ưu tiên tải trước khi trình duyệt render, vì nếu preload nhiều quá nhưng không dùng đến không làm website tối ưu hơn mà còn làm chậm hơn.

Nếu bạn chưa biết trên trang của mình cần preload cái gì thì có thể lấy danh sách thứ cần preload dựa vào các nội dung tải ra trong tầm mắt người dùng trước khi cần cuộn trang (Above the Fold), sau đó đưa hình ảnh, font, Google Font, background vào thẻ <link> để bạn copy và chèn vào website, thông qua code bên dưới và dán vào công cụ Console ở DevTool để sử dụng:

(function() {
  const preloadedResources = new Set();

  // Lấy chiều cao khung nhìn (viewport) để xác định Above-the-Fold
  const viewportHeight = window.innerHeight;

  // Lấy tất cả các phần tử hình ảnh và có hình nền trong khung nhìn
  const elementsAboveFold = Array.from(document.querySelectorAll('img, [style*="background"], [style*="src"]')).filter(el => {
    const rect = el.getBoundingClientRect();
    return rect.top >= 0 && rect.top < viewportHeight;
  });

  // Tìm tài nguyên hình ảnh và background-image
  elementsAboveFold.forEach(element => {
    let src;

    // Tìm tài nguyên hình ảnh từ thẻ img
    if (element.tagName === 'IMG' && element.src) {
      src = element.src;
    }

    // Tìm tài nguyên từ background-image
    const bgImage = window.getComputedStyle(element).getPropertyValue('background-image');
    if (bgImage && bgImage !== 'none') {
      src = bgImage.slice(4, -1).replace(/"/g, "");  // Lấy URL từ background-image
    }

    if (src) {
      // Chuyển đổi URL thành dạng //domain.ltd thay vì https://domain.ltd
      src = src.replace(/^https?:/, '');
      preloadedResources.add(src);
    }
  });

  // Tìm các link Google Fonts (chỉ lấy các tệp CSS thực sự)
  const googleFontsLinks = Array.from(document.querySelectorAll('link[href*="fonts.googleapis.com/css"]'));
  googleFontsLinks.forEach(link => {
    let href = link.href.replace(/^https?:/, ''); // Chuyển đổi thành dạng //domain.ltd
    preloadedResources.add(href);
  });

  // In ra console các thẻ <link rel="preload">
  let preloadLinks = '';
  preloadedResources.forEach(resource => {
    let asType = 'image'; // Mặc định là image
    if (resource.endsWith('.woff2') || resource.endsWith('.woff')) {
      asType = 'font';
    } else if (resource.includes('fonts.googleapis.com/css')) {
      asType = 'style'; // Google Fonts sử dụng 'style'
    }
    preloadLinks += `<link rel="preload" href="${resource}" as="${asType}" crossorigin="anonymous">\n`;
  });

  console.log(preloadLinks);
})();

Nhớ xem kỹ lại và lược bỏ bớt những cái gì không cần preload nhé, ví dụ hình ảnh của mấy bài viết.

Sử dụng Speculative Loading

Gần đây WordPess có ra mắt một plugin do chính team WordPress Performance Team mà nó sẽ sử dụng thuộc tính <link rel="prefetch" /> và <link rel="prerender" /> để tải trước một trang tiếp theo sẽ cần tải để tiết kiệm thời gian.

Để tránh bài này dài hơn, bạn có thể đọc qua bài viết Sử dụng Speculative Loading trên blog AZDIGI để tìm hiểu thêm, cũng do mình viết luôn.

Tối ưu hoá hình ảnh trên website

Tới đây thì mình đã nhắc lại về việc tối ưu hoá hình ảnh sử dụng trên website tận 3 lần vì nó là nguyên nhân chính làm tổng dung lượng mà trình duyệt cần tải tăng cao bất thường. Một tập tin CSS hay Javascript chưa nén có thể có dung lượng to, nhưng so với một tấm ảnh 4k thì nó phải gọi bằng…điện thoại.

Với các hình ảnh sử dụng trên website, bạn cân nhắc phải luôn nén (compress) nó lại để dung lượng nó luôn phải thấp nhất nhưng không ảnh hưởng nhiều đến chất lượng hiển thị. Thực tế một tấm ảnh hiển thị trên website sẽ không cần độ phân giải quá cao lên đến 4k hay 8k, nên cũng nên cân nhắc giảm kích thước (resize) của tấm ảnh xuống mà thường là căn cứ theo chiều ngang không nên vượt quá 2000px, lý do là chiều ngang hiển thị nội dung trên một website lớn lắm là cỡ 1600px là cùng. Blog bạn đang đọc bài này có chiều rộng nội dung chỉ 799px.

Yếu tố thứ hai nữa đó là nên sử dụng định dạng ảnh tối ưu cho trình duyệt thay vì các định dạng ảnh JPEG/PNG/GIF thường thấy mà cụ thể là sử dụng định dạng WebP (.webp) do Google mua lại từ On2 Technologies và phát triển cho đến ngày nay. WebP có ưu điểm là hỗ trợ nén ảnh không mất dữ liệu (Lossless Compression, giống như định dạng FLAC cho audio) và nén mất dữ liệu (Lossy Compression, giống như định dạng MP3 cho audio), đồng thời rất đa năng hỗ trợ nhiều định dạng ảnh khác nhau, kể cả ảnh GIF và ảnh trong suốt.

Liệt kê ra ở trên nghe thì phức tạp vậy thôi nhưng WordPress có nhiều plugin hỗ trợ bạn tự động làm tất cả các việc từ resize ảnh (tuỳ chọn không bắt buộc), đến nén ảnh, rồi chuyển đổi qua .webp và hiển thị ra ngoài website hoàn toàn tự động mà không cần thao tác gì. Hiện nay nếu bạn muốn miễn phí thì sẽ có plugin Smush Image Optimization làm việc rất tốt, còn trả phí thì cũng là plugin đó luôn, nhưng phiên bản Pro Max 💸.

Plugin Smush mình đang dùng trên hầu hết các website WordPress mà mình đang quản lý hiện nay vì nó làm việc rất hiệu quả với các tính năng mình đánh giá là đáng tiền:

• Hiệu năng nén rất tốt khi so sánh với các plugin nén ảnh khác.
• Tự động xử lý ảnh khi đăng lên website mà không cần làm trước ở máy.
• Hỗ trợ chạy ngầm để nén xử lý các ảnh cũ đã có trên website (bản Pro).
• Có thể linh hoạt giữ hoặc không giữ lại ảnh gốc để nếu cần nó sẽ hỗ trợ bạn khôi phục lại nhanh.
• Dĩ nhiên là có hỗ trợ tự động tạo một phiên bản .webp và hiển thị nó ra ngoài website một cách đơn giản.

Bạn nghĩ mỗi hình ảnh khi nén lại sẽ giảm bao nhiêu dung lượng? Chắc cỡ 30%, 40% là nhiều chứ sao giảm được nhiều. Không má ơi, giảm đến 75, 80% với một tấm ảnh mình chụp màn hình.

Việc tối ưu hoá hình ảnh này có thể chưa giúp bạn tiết kiệm dung lượng lưu trữ trên máy chủ (nếu có bật tính năng lưu lại bản gốc của hình ảnh), nhưng nó sẽ giúp giảm dung lượng của trang cần tải ra đáng kể, mình khuyến khích bạn áp dụng ngay càng sớm càng tốt nếu chưa từng.

Trường hợp nếu bạn có website bắt buộc phải hiển thị ảnh chất lượng cao trong bài viết thì chỉ nên nén ảnh mà không cần giảm độ phân giải của nó, có thể tải lên bình thường nhưng khi chèn vào bài viết thì chỉ cho hiển thị ở kích thước độ phân giải thấp hơn, và cần chèn một link vào ảnh đến ảnh gốc để khi người dùng cần xem chất lượng nét như Sony thì sẽ có hiệu ứng phóng to khi nhấp vào ảnh (WordPress gọi là Lightbox, tính năng mặc định ở các phiên bản mới hiện nay).

Mình ngoài lề một xíu là từ khi có plugin Smush, mình hầu như còn chẳng thèm mở xem lại ảnh chụp màn hình (nếu có thì sửa để thêm mấy cái chỉ dẫn) sau đó giữ nguyên vậy và đưa lên thẳng website, tên còn không thèm đổi mà, thao tác chụp ảnh màn hình và tải lên website rất nhanh như video dưới.

Giải quyết vấn đề render-blocking: Combine, Critical CSS, Defer, Async

Trong phần nói về preload ở trên mình có nhắc qua khái niệm Above the Fold, thuật ngữ này trước đây được dùng trong thiết kế báo giấy để ám chỉ vùng nội dung mà nó hiển thị ra khi gấp đều lại với nhau.

Sau này khi website phát triển, người ta vẫn dùng lại tên gọi này để ám chỉ nội dung sẽ hiển thị ra trong tầm mắt của người dùng khi vào website trước khi họ cuộn trang. Thường phần nhận diện thương hiệu và thông tin quan trọng được ưu tiên đưa lên ở đây.

Dĩ nhiên là sẽ không có quy chuẩn chung nào xác định kích thức của vùng above the fold có chiều cao là bao nhiêu mà nó sẽ do kích thước cửa sổ trình duyệt đang tải website. Ngay cả các công cụ như PageSpeed Insights cũng chỉ xác định khu vực Above the Fold dựa vào việc mô phỏng tải trang trên một thiết bị tiêu chuẩn ở điều kiện tiêu chuẩn nào đó.

Như vậy ta sẽ tạm ngầm hiểu rằng nội dung ở khu vực above the fold rất quan trọng và phải cần hiển thị trước và rõ ràng khi người dùng truy cập.

Vậy Above the Fold có vai trò gì ở khúc này trong bài viết? Chắc chắn là có rồi, vì mình sẽ nói đến một kỹ thuật áp dụng tăng tốc độ của thời gian tải trang thông qua việc hiểu rõ bản chất tải render-blocking của các tài nguyên CSS và Javascript rồi kết hợp nó với above the fold để tăng tốc thời gian tải trang.

Mặc định các tài nguyên CSS sẽ tải với dạng render-blocking (chặn hiển thị), nghĩa là khi trình duyệt tiến hành render trang từ trên xuống dưới, nếu gặp đoạn CSS hoặc tập tin .css nào thì nó sẽ dừng lại xử lý, gửi kết nối để tải về và tiếp tục render cho đến khi kết thúc. Việc này sẽ đồng nghĩa nếu trang của bạn có quá nhiều tập tin .CSS thì sẽ ảnh hưởng đến quá trình render sẽ lâu hơn, ảnh hưởng trực tiếp đến tốc độ tải trang tổng thể.

Đối với Javascript thì cũng tương tự như vậy, nhưng dễ dàng xử lý hơn vì có thể chèn tham số defer hoặc async vào thẻ <script> trong quá trình nhúng nên cách xử lý cũng đơn giản.

Vấn đề to bự ở đây đối với WordPress là trong theme và plugin sẽ đa phần là có những tập tin CSS và Javascript riêng của nó rồi chèn vào website, vì vậy việc kiểm soát render-blocking thường khá khó khăn.

Xử lý render-blocking với CSS

Để xử lý vấn đề render-blocking với CSS thì chúng ta có thể dùng một hoặc nhiều cách kết hợp bên dưới với các kỹ thuật bao gồm tạo CSS quan trọng ưu tiên để cho nó tải hoàn thiện ở phần Above the Fold, các đoạn CSS còn lại sẽ tải không đồng bộ hoặc đưa xuống dưới tài liệu HTML để nó tải sau cùng.

Tuy nhiên với kỹ thuật Critical CSS để ứng dụng vào WordPress thì khá khó ứng dụng hoàn chỉnh nếu bạn đang mong muốn tìm plugin làm việc này, vì mỗi plugin sẽ có các tập tin CSS riêng, rồi theme cũng có CSS riêng, chưa kể hiện nay nếu dùng Elementor thì khả năng gây ra lỗi xung đột cho Critical CSS rất cao trừ khi làm thủ công. Khi có thời gian mình sẽ có một hướng dẫn phần này riêng.

Vậy nên phương pháp khả dĩ nhất mà ai cũng làm được đó là sử dụng kỹ thuật combine CSS để gộp nhiều tập tin .css trên trang lại thành một (hoặc một vài) tập tin .css để giảm thiểu tối đa số lượng kết nối xử lý tập tin kiểu này trên website. Nhưng phương pháp này lại gây ra một vấn đề khác, đó là việc gộp tập tin lại như vậy thì bạn sẽ có một tập tin to bự hơn, trình duyệt cũng cần thêm thời gian tải và quan trọng là không cần thiết hiện nay khi có sự hỗ trợ của HTTP/2 và HTTP/3 vốn đang là tiêu chuẩn mặc định hiện nay, nó có thể gửi nhiều kết nối cùng lúc để xử lý các tập tin CSS này.

Cả hai phương pháp trên đều không xong, vậy thì làm sao? Mình chợt loé lên ý tưởng là sẽ làm sao đó để biến CSS thực hiện tải độc lập không đồng bộ với trình duyệt khi render sau khi DOM hoàn tất (Defer), nhưng việc này có thể gây ra lỗi vì tải async sẽ không kiểm soát được thứ tự tải, và có thể gây ra lỗi hiển thị website xấu hoắc trong 1-2 giây rồi mới trở lại như bình thường. Nhưng chung quy thì dùng cách này sẽ có lợi hơn so với dùng Critical CSS hay combine CSS.

Thông tin thêm: CSS không hỗ trợ defer giống Javascript ở mặc định mà sẽ cần thủ thuật để tinh chỉnh, trường hợp ở dưới là chúng ta sẽ sử dụng plugin hỗ trợ để làm việc này.

Để giải quyết vấn đề trải nghiệm người dùng không tốt khi áp dụng tải defer, chúng ta chỉ cần cho một vài tập tin .css quan trọng vào để preload trước khi trình duyệt render là xong, phần preload mình có nói ở trên rồi.

Đây là hướng dẫn chi tiết cách chuyển CSS tải với kiểu defer và preload tập tin .css quan trọng trước, thông qua hỗ trợ của plugin CSS JS Manager, Async JavaScript, Defer Render Blocking CSS supports WooCommerce và plugin Insert Scripts in Header and Footer.

Lưu ý: Bạn nên tắt các tính năng combine và Minify CSS đang có nếu có bật lên ở plugin tạo cache như WP Rocket, LiteSpeed Cache, WP Fastest Cache,…khi sử dụng phương pháp defer CSS.

Đầu tiên chúng ta cần phải xác định được trên trang đang phải tải những tập tin .css nào, bằng cách truy cập vào trang chủ và chạy đoạn Javascript sau ở Console trong công cụ DevTools.

(function() {
  const cssFiles = [];
  const linkElements = document.querySelectorAll('link[rel="stylesheet"]');

  linkElements.forEach(link => {
    let href = link.getAttribute('href');
    if (href) {
      // Chuyển đổi các liên kết thành dạng //domain.tld
      href = href.replace(/^https?:/, '');
      cssFiles.push(href);
    }
  });

  console.log(cssFiles.join('\n'));
})();

Bạn sẽ nhận được danh sách tập tin .css tải trên trang bao gồm các tập tin trong nội bộ website và bên thứ ba, được sắp xếp theo thứ tự tập tin tải đầu tiên nằm ở trên.

Bây giờ bạn đã có danh sách tập tin cần xử lý, việc của bạn là tự dựa vào kinh nghiệm của mình để phân loại ra như sau:

• Danh sách 1: Các tập tin CSS của bên thứ ba và cần thiết cho phần hiển thị chính trên trang (ví dụ Google Font), để mục đích preload.
• Danh sách 2: Các tập tin CSS bên trong website mà bạn cho là cần thiết để hiển thị chính trên trang, để mục đích preload.
• DAnh sách 3: Các tập tin CSS còn lại mà bạn cho rằng nó nên tải sau cùng, để mục đích tải defer.

Sau khi có danh sách rồi, bạn soạn một nội dung để preload theo cú pháp như bên dưới và lặp lại cho đến khi đủ các link .css trong Danh sách 1 và Danh sách 2 ở trên.

<link rel="preload" href="//domain.tld/TẬP-TIN-CSS" as="style" crossorigin="anonymous">
<link rel="preload" href="//domain.tld/TẬP-TIN-CSS" as="style" crossorigin="anonymous">
<link rel="preload" href="//domain.tld/TẬP-TIN-CSS" as="style" crossorigin="anonymous">

Sau khi soạn xong bạn cài plugin Insert Scripts to Header and Footer (nếu chưa có) và vào Settings =>
Insert Scripts to Header and Footer chèn vào mục Scripts in Header là xong.

Tiếp tục bạn sẽ cần cài plugin CSS JS Manager, Async JavaScript, Defer Render Blocking CSS supports WooCommerce vào website, sau đó truy cập vào CSS JS Manager trên giao diện quản trị.

Sau đó ấn vào nút Add New Resources.

Sau đó copy link tập tin CSS ở danh sách 3 vào đây, chọn Method là Defer và lưu lại. Nếu bạn có tập tin .css nào đó mà bạn cho là thừa thải không cần dùng tới thì chọn Remove this ở mục Selection Logic nhé.

Lặp lại cho đến khi hoàn tất.

Về bản chất, plugin này sử dụng một thủ thuật để tải tập tin .css theo kiểu defer là cũng sử dụng preload để cho trình duyệt tải trước tiên, sau khi tập tin này được preload xong thì nó thực hiện thay đổi thuộc tính từ rel="preload" thành rel="stylesheet" để trình duyệt hiểu đây là tập tin `.css và áp dụng vào việc render trang.

Xử lý render-blocking với Javascript

Không giống như CSS, Javascript có thể dễ dàng chuyển đổi kiểu thực thi của nó để không chặn hiển thị trên trình duyệt thông qua dễ dàng thêm thuộc tính defer hoặc async vào thành phần tải Javascript. Tuy nhiên ở WordPress để làm phần này tốt thì cũng sẽ cần phải sử dụng tới plugin, ở đây ta sẽ sử dụng luôn plugin CSS JS Manager, Async JavaScript, Defer Render Blocking CSS supports WooCommerce mà ta đã cài ở trên.

Đầu tiên bạn cũng sẽ cần xác định các tập tin .js trên website mình đang sử dụng, thông qua thực thi đoạn code dưới đây ở Console trong DevTools trên trình duyệt.

(function() {
  // Lấy tất cả các mục từ Performance API
  const resources = performance.getEntriesByType('resource');
  const jsFiles = [];

  // Lọc các mục là JavaScript từ danh sách tài nguyên
  resources.forEach(resource => {
    if (resource.initiatorType === 'script') {
      let jsFile = resource.name;
      // Chuyển đổi các liên kết thành dạng //domain.tld
      jsFile = jsFile.replace(/^https?:/, '');
      jsFiles.push(jsFile);
    }
  });

  // In ra danh sách các tệp JavaScript theo thứ tự thực tế mà chúng được tải
  console.log(jsFiles.join('\n'));
})();

Nó sẽ sinh ra một danh sách các tập tin .js được tải trong website theo thứ tự trước đó mà nó đã tải. Mục đích là để ta dễ nhận biết để lấy 2-3 tập tin đầu tiên để đưa nó qua dạng async và các tập tin còn lại sẽ dạng với kiểu defer. Thường thì chúng ta sẽ cho thư viện jQuery tải async để đảm bảo nó được tải ra sớm hơn so với các tập tin tải kiểu defer.

Sau khi đã có danh sách tập tin cần chèn kiểu defer và async, bạn truy cập lại vào trang CSS JS Manager trong trang quản trị WordPress, ấn vào nút Add New Resources, điền link tập tin .js, chọn loại tập tin là JS và tuỳ chỉnh kiểu Async hoặc Defer tương ứng.

Sử dụng Edge Caching/CDN

Phương pháp này có thể không cần thiết bắt buộc phải dùng, nhưng nếu website của bạn phục vụ người dùng từ nhiều quốc gia khác nhau thì nên cân nhắc.

Trước khi nói đến Edge Caching thì bạn cần biết qua thuật ngữ về Edge server (hoặc Edge network), nghĩa là một máy chủ sử dụng hệ thống mạng gần với bạn nhất tính theo khoảng cách địa lý. Sở dĩ cần sự phân biệt về thuật ngữ là vì thực tế website của bạn sẽ được đặt trong máy chủ của nhà cung cấp hosting, và các máy chủ đó đặt trong một trung tâm dữ liệu nào đó và sử dụng hệ thống mạng của trung tâm dữ liệu để kết nối với Internet bên ngoài.

Ví dụ website Facebook của họ đặt tại trung tâm dữ liệu của họ tận bên Mỹ, nhưng bạn ở Việt Nam truy cập vào thì có khả năng dữ liệu bài viết nào đó trên Facebook được lấy từ một máy chủ từ hệ thống Edge server của họ đặt tại Việt Nam, thay vì bạn phải trực tiếp kết nối với máy chủ tại Mỹ để truy cập. Điều này sẽ giúp tránh được nhược điểm gây truy cập chậm khi máy chủ đặt ở quá xa người dùng.

Các hệ thống Edge server này chủ yếu sở hữu bởi các big tech lớn trên thế giới, nên việc của chúng ta là đi tìm dịch vụ hỗ trợ để sử dụng nếu có chi phí.

Nếu bạn đã từng nghe qua cụm từ “CDN – Content Delivery Network” là một cụm từ ám chỉ một mạng lưới phân phối nội dung đến người dùng thông qua các Edge server. Nói gần gũi hơn là nếu bạn dùng CDN, thì bạn đang gửi dữ liệu của mình lên các Edge server của CDN đó để giúp phân phối đến toàn bộ người dùng trên thế giới.

Và thuật ngữ “Edge Caching” ở đây đang nói về việc đưa toàn bộ nội dung WordPress lên hệ thống CDN để phân phối cho người dùng, không chỉ là các tập tin tĩnh mà còn là cả nội dung của website lên hệ thống Edge server/CDN để trình duyệt người dùng truy cập nhanh ở mọi nơi, khác với hiểu lầm rằng CDN chỉ áp dụng cho các tập tin tĩnh như hình ảnh, Javascript hay CSS.

Hiện nay nói về dịch vụ có thể hỗ trợ bạn sử dụng Edge caching cho WordPress như CloudFlare, Fastly nhưng phổ biến nhất, dễ dùng nhất và rẻ nhất chắc chỉ có CloudFlare.

Cloudflare cung cấp một dịch vụ gọi là APO (Automatic Platform Optimization for WordPress) dành riêng cho WordPress để tự động lưu bộ nhớ đệm cho các trang trong WordPress thành một tập tin .html và đẩy nó lên hệ thống CDN của CloudFlare để phân phối tới người dùng khi có ai đó truy cập vào website.

Khi bật tính năng APO ở CloudFlare, bạn sẽ cần một plugin hỗ trợ tự động xoá cache trong APO và tương thích với các plugin Full Page Caching mà bạn đang dùng. Hiện tại mình thấy plugin WP Rocket và WP Fastest Cache đã hỗ trợ kết nối với tài khoản CloudFlare để thực hiện xoá cache trên APO khi full page caching được xoá.

Ưu điểm của phương pháp này sẽ giúp máy chủ hạn chế tối đa nhận yêu cầu kết nối từ người dùng, nếu như họ đang xem nội dung đã được lưu cache tại hệ thống CDN của họ, giúp website có cơ hội nhận được nhiều truy cập hơn do việc giảm tải vào máy chủ. Đồng thời nếu kết hợp với CloudFlare thì tận dụng được các tính năng bảo mật và chống DDoS của họ.

Nhược điểm khi sử dụng CloudFlare APO là tốn thêm ít chi phí cho nó, và người dùng khi truy cập vào website thực tế sẽ phải kết nối đến CloudFlare. Đôi lúc sẽ gây chậm nếu hệ thống mạng tại Việt Nam bị đứt cáp ra quốc tế, hay hy hữu hơn là CloudFlare sập như hồi tháng 07/2023 khiến hàng triệu website đi bụi vì phụ thuộc vào họ.

Cũng phải nói thêm là khi website của bạn sử dụng CloudFlare và có bật proxy cùng với tính năng APO, bạn không cần sử dụng thêm dịch vụ CDN khác cho các tập tin tĩnh vì thực tế mọi tập tin của website khi tải ở trình duyệt đã tải từ CDN của CloudFlare.

Kết bài

Ở trên là những gì mình cần viết cho việc tối ưu tốc độ của một website WordPress. Thực tế là tới đây mình cũng hơi lười vì bài quá dài rồi nên hẹn gặp lại bạn ở serie Học WordPess Tinh Gọn 2024 và bài viết tối ưu Google PageSpeed chi tiết sắp tới.