Hướng dẫn tối ưu hoá hosting để tăng tốc WordPress

Có một trang web kinh doanh nhanh là điều cần thiết cho cả xếp hạng của Google và tỷ lệ chuyển đổi tổng thể. Do Kissmetrics, 40% khách truy cập trang web sẽ bỏ qua một trang mất ba giây trở lên để tải. Trước đó, BBC đã tính toán rằng họ mất thêm 10% người dùng cho mỗi giây thêm mà trang web của họ tải. 

Để giúp độc giả và khách hàng của chúng tôi đạt được kết quả tốc độ cao hơn, chúng tôi quyết định xuất bản một bộ bài viết dành riêng cho việc cải thiện hiệu suất trang web bằng cách sử dụng các gợi ý tuyệt vời từ Hướng dẫn tối ưu hóa tốc độ WordPress cuối cùng do Johnny Nguyễn viết . 

“Các trang web nhanh hơn kiếm nhiều tiền hơn, xếp hạng tốt hơn và cải thiện trải nghiệm người dùng tổng thể!” 

Johnny Nguyễn

Hôm nay chúng ta sẽ bắt đầu với phần tối ưu hóa lưu trữ web. Mỗi điểm sẽ được đánh dấu mức độ các kỹ năng cần thiết để thực hiện và tác động mà nó sẽ mang lại về:

KỸ NĂNG:

• BEGINNER – có thể Google và làm theo hướng dẫn.
• INTERMEDIATE – làm việc với tư cách là nhà thầu WordPress.
• ADVANCED – lập trình viên hoặc quản trị viên máy chủ.

TÁC ĐỘNG:

• LOW – có thể chênh lệch 100-200ms. Có thể không đáng chú ý.
• MEDIUM – chênh lệch khoảng 500ms.
• HIGH – chênh lệch 1 giây hoặc hơn.

Tốc độ web hosting của bạn xác định tốc độ nó có thể xử lý mã và số lượng khách truy cập mà nó có thể xử lý. Hãy so sánh trang web của bạn với một chiếc xe hơi. Để làm cho chiếc xe chạy nhanh hơn, bạn phải A) lắp động cơ mạnh hơn và / hoặc B) giảm trọng lượng. Đối với các trang web, máy chủ web là “động cơ” và mã nguồn là “trọng lượng”.

Mục tiêu của chúng tôi là cải thiện “công cụ” máy chủ web trong khi giảm tải phần “trọng lượng” mã nguồn.

Thay đổi web hosting của bạn là một trong những cách dễ nhất để cải thiện tốc độ. Những người trong số các bạn sử dụng web hosting chia sẻ giá rẻ $ 5 / tháng sẽ được hưởng lợi nhiều nhất khi chuyển sang dịch vụ lưu trữ được quản lý hoặc thậm chí là VPS của riêng bạn. Sự khác biệt sẽ là đêm và ngày mà không có bất kỳ thay đổi trang web nào. Chuyển từ dịch vụ lưu trữ được quản lý sang một VPS được tối ưu hóa hoặc máy chủ “bare metal” chuyên dụng sẽ là một bước nhảy vọt khác. 

Sự khác biệt không chỉ là tốc độ mà còn là vấn đề chi phí (tiết kiệm). Một máy chủ nhanh có thể xử lý nhiều khách truy cập hơn một máy chủ chậm. Nếu máy chủ của bạn có thể xử lý gấp đôi lưu lượng, về mặt lý thuyết, hóa đơn có thể rẻ hơn gấp đôi. Không phải là vấn đề lớn đối với một trang web nhỏ nhưng đối với một trang web thương mại điện tử khổng lồ với hóa đơn máy chủ $ 1k / tháng thì sao? Giảm 50% chi phí nghe thật hấp dẫn!

1. Chọn vị trí trung tâm dữ liệu gần đó (BEG, LOW-MED)

Rõ ràng, bạn nên chọn một vị trí máy chủ gần nhất với khách truy cập của bạn. Lý tưởng nhất là bạn không muốn thời gian ping DNS của mình hơn 100ms từ máy chủ đến máy tính của khách truy cập. Có nhiều hàm ý tùy thuộc vào nhu cầu của bạn.

• Các doanh nghiệp địa phương nên có một máy chủ càng gần khách truy cập của họ càng tốt. Giữ nó trong vòng 100ms hoặc ít hơn, trong vòng 50ms là tốt hơn. Kiểm tra thời gian ping với WonderNetwork .
• Hoa Kỳ là khoảng 80ms từ bờ biển này sang bờ biển khác. Canada và Mexico cũng rất gần nhau.
• Toàn bộ Tây Âu chỉ là 40-50ms, rất gần.
• Châu Á nằm trong phạm vi 80ms giữa hầu hết các quốc gia.
• Ấn Độ / Pakistan, Úc / NZ, Châu Phi hơi bị cô lập. Các doanh nghiệp địa phương ở đó cần một trung tâm dữ liệu cục bộ. Ngay cả Singapore đến Úc cũng là đường biên giới “xa” theo tiêu chuẩn DNS (~ 150ms).
• Nam Mỹ có thể là cơ sở hạ tầng không đáng tin cậy. Vì lý do đó, nhiều công ty ở Trung / Nam Mỹ vẫn sử dụng các trung tâm dữ liệu có trụ sở tại Hoa Kỳ như ở California, Texas hoặc Florida (Miami).
• Nếu bạn có lưu lượng truy cập trên toàn thế giới (bao gồm Châu Á / Thái Bình Dương) và không có khu vực cốt lõi cụ thể, tôi thích bờ biển phía Tây Hoa Kỳ là vị trí hoàn hảo cho giao thông nhanh chóng đến Châu Âu và Châu Á.

Cũng tốt nếu có một công ty lưu trữ web trên cùng múi giờ với đối tượng cốt lõi của bạn. Bằng cách đó, họ có thể (nhanh chóng) hỗ trợ hoặc khắc phục sự cố khi hầu hết khách truy cập của bạn còn hoạt động.

• Những người trong số bạn nghĩ rằng CDN có thể bù đắp cho vị trí máy chủ ở xa (điều đó không nhất thiết phải đúng!)

Những người trong số các bạn đang tìm kiếm các giao điểm chuyên dụng… tốt nhất là trung tâm dữ liệu TIER-4 với bốn số 9 (đảm bảo 99,9999% thời gian hoạt động). Nhưng chúc may mắn để bạn có được những thứ được đảm bảo này!

• Thời gian hoạt động (99,9% thời gian hoạt động có nghĩa là thời gian ngừng hoạt động 43 phút mỗi tháng).

2. Chọn dịch vụ lưu trữ trang web phù hợp (BEG, HIGH)

• Share hosting ($ 5-30 / tháng) – tốt cho các trang web nhỏ và lưu lượng truy cập thấp lên đến 100k lượt truy cập / tháng. Không có quyền truy cập vào cấu hình máy chủ.
• VPS / Cloud hosting ($ 30-300 / tháng) – tuyệt vời cho các trang web trung bình và lưu lượng truy cập lên đến 30 triệu lượt truy cập / tháng.
• Máy chủ chuyên dụng (bare metal) ($ 200 / tháng trở lên) – tuyệt vời cho các trang web lớn với hàng TẤN lưu lượng truy cập.

Mua những thứ tốt nhất mà bạn có thể thoải mái mua được. Một trang web nhỏ không cần nhiều sức mạnh nhưng nó vẫn đáng chú ý khi bạn có một máy chủ tốt hơn và được đánh giá cao hơn bạn nghĩ. Hãy nghĩ về một chiếc điện thoại mới có thể mở ứng dụng nhanh hơn chỉ một phần của giây. Bạn thực sự có thể cảm nhận được sự khác biệt và nó cải thiện trải nghiệm người dùng rất nhiều.

• Share hosting thường chậm vì họ nhồi nhét hàng trăm khách hàng / trang web vào cùng một máy chủ (tối đa hóa lợi nhuận). Điều này làm giảm tốc độ web, các sự cố không mong muốn hoặc máy chủ khởi động lại, các cuộc tấn công bảo mật và IP email của bạn bị đánh dấu là spam.
• Môi trường lưu trữ được chia sẻ cũng chậm vì chúng tải nhiều tập lệnh / mô-đun để tối đa hóa khả năng tương thích cho nhiều người dùng nhất có thể. Và nếu không có tài nguyên chuyên dụng, khách truy cập của bạn sẽ phải xếp hàng chờ đợi trong khi máy chủ bận xử lý các trang web khác trước.
• VPS / Dedicated nhanh hơn vì có nhiều tài nguyên hơn cho mỗi tài khoản và tài nguyên của bạn chỉ phục vụ các trang web của bạn. Bạn có nhiều quyền kiểm soát hơn đối với môi trường của mình, có thể định cấu hình nó theo nhu cầu của bạn. VPS / Dedicated có thể tốn kém hoặc khó quản lý đối với người dùng thông thường. Có các dịch vụ bảng điều khiển đám mây để giúp quản lý nó và cũng có các dịch vụ được quản lý hoàn toàn, nơi họ chăm sóc mọi thứ cho bạn.
• Những người không thể xử lý trách nhiệm kỹ thuật của VPS có thể sử dụng “dịch vụ share hosting cao cấp”. Chúng không chiếm nhiều máy chủ nhưng hiệu suất (mặc dù tốt hơn so với chia sẻ lưu trữ thông thường) vẫn sẽ kém xa VPS.

3. Chọn một máy chủ web hiệu suất cao (INT-ADV, HIGH)

Sử dụng bất kỳ phần mềm máy chủ web nào trừ Apache. Tốt nhất là NGINX hoặc LiteSpeed, hoặc Apache được tối ưu hóa cao (hiếm tìm thấy). Lưu lượng truy cập của bạn càng cao, sự khác biệt càng đáng chú ý.

• NGINX tỏa sáng ở các trang web đơn giản. Chỉ cần đặt nó. Không có nhiều cài đặt để tối ưu hóa. Nhưng một khi bạn có một trang web phức tạp, NGINX là một túi hỗn hợp. Một số tính năng NGINX không dễ định cấu hình. Nếu bạn có quản trị viên máy chủ để tinh chỉnh, điều đó thật tuyệt vời nhưng với nhiều người thì không.
• LiteSpeed ​​có nhiều tính năng dễ tiếp cận hơn NGINX. Như khi bạn cần một số thứ được lưu trong bộ nhớ cache nhưng không phải những thứ khác, hoặc xử lý các chuyển hướng cấp máy chủ thông qua htaccess. LiteSpeed ​​cũng có một plugin bộ nhớ cache WordPress mà NGINX không có. Đó là một lợi thế LỚN. (Cá nhân tôi thích LiteSpeed ​​hơn.)
• OpenLiteSpeed ​​là phiên bản cộng đồng miễn phí của LiteSpeed. Đó là một giải pháp thay thế tuyệt vời cho những người muốn NGINX miễn phí nhưng có plugin bộ nhớ cache LiteSpeed ​​mạnh mẽ.
• Một số máy chủ web có ngăn xếp hỗn hợp Apache + NGINX. Tôi cảm thấy những thứ đó đã lỗi thời và làm cho ngăn xếp nặng hơn / chậm hơn một cách không cần thiết.
• Nếu sử dụng Apache, các sự kiện MPM là tốt nhất (so với worker hoặc prefork).
• Luôn cập nhật máy chủ web của bạn. Các phiên bản mới hơn có thể tăng tốc đáng kể các giao thức và quy trình nhất định.

4. Cấu hình máy chủ web (ADV, MED-HIGH)

Hầu hết các máy chủ web đều có cấu hình an toàn / chức năng ngay lập tức. Thích hợp cho các trang web nhỏ trung bình với ít lưu lượng truy cập. Đó là khi bạn nhận được nhiều lưu lượng truy cập hơn và nhiều cuộc tấn công bảo mật hơn hoặc có nhiều ứng dụng đòi hỏi khắt khe hơn, việc tinh chỉnh cấu hình sẽ tạo ra sự khác biệt lớn.

• Timeout – 30 đến 60 giây là một khởi đầu an toàn. Bạn có thể tăng lên đến 600 hoặc hơn nếu cần cho các quy trình dài (nhập, xuất, sao lưu). Hãy nhớ rằng điều này cho phép các quy trình được mã hóa kém hoặc khai thác hack làm cạn kiệt tài nguyên máy chủ của bạn.
• # trong số các quy trình con được phép – tùy thuộc vào môi trường máy chủ. Mặc định sẽ ổn.
• Cho phép kết nối đồng thời – ở bất kỳ đâu từ 1-20k. Cao hơn chưa chắc đã tốt hơn!
• Keep alive – bật, tắt, hoặc “Smart keep-alive” của LiteSpeed. Tôi nghĩ rằng “bật” là an toàn hơn. Nếu bạn có LiteSpeed, tính năng duy trì thông minh thật tuyệt vời!
• Keep alive timeout – 3-5 giây là một khởi đầu an toàn. Tăng lên nếu cần.

Có bao nhiêu luồng, kích thước body / buffer, worker, client, v.v… .tất cả mà bạn có thể tra cứu trực tuyến. Nó phụ thuộc vào kích thước máy chủ và kịch bản sử dụng của bạn. Hãy vào các diễn đàn và hỏi xung quanh hoặc nhờ một quản trị viên hệ thống cấu hình cho bạn. Hãy nhớ rằng các quản trị viên khác nhau có cách định cấu hình riêng.

Sự khác biệt quan trọng nhất đối với tôi là quyết định xem máy chủ này nên được đặt là linh hoạt hay bảo thủ:

• Cấu hình AGGRESSIVE – cung cấp cho mọi trang web nhiều tài nguyên nhất có thể. Tốt cho người thuê thấp hoặc máy chủ chuyên dụng.
• Cấu hình CONSERVATIVE – cung cấp cho mọi trang web ít tài nguyên nhất có thể. Tốt cho người thuê cao hoặc máy chủ chia sẻ.

5. Tắt các dịch vụ không sử dụng (INT, HIGH)

Nhiều máy chủ được tự động thiết lập với tất cả các tính năng đang chạy để giúp bạn thực hiện mọi việc dễ dàng. Nhưng chúng giống như những chiếc máy tính mới tinh với phần mềm được cài đặt sẵn. Loại bỏ những cái bạn không sử dụng. Ngay cả khi chúng không sử dụng nhiều bộ nhớ, chúng vẫn có thể bị tấn công bởi tin tặc và ăn tài nguyên.

• DNS – tắt nếu bạn đang sử dụng dịch vụ DNS bên ngoài. (Cloudflare, DNSME, v.v.)
• Email – tắt nếu bạn đang sử dụng email của bên thứ ba. (G-Suite, MXroute, v.v.)
• FTP / SFTP – tắt nếu không sử dụng.
• Memcache / Redis – tắt nếu bạn không sử dụng nó.
• Các dịch vụ khác – Varnish, Elastipress, v.v.

6. Loại bỏ các mô-đun máy chủ không sử dụng (ADV, LOW)

Tắt mọi mô-đun đơn lẻ không được sử dụng bởi máy chủ. Một số trong số chúng là những thứ máy chủ không sử dụng; những thứ khác là nội dung bản phân phối Linux không được sử dụng. Các ngăn xếp tương thích với Apache cũ hoặc bảng điều khiển chưa được tối ưu hóa có xu hướng có nhiều mô-đun không sử dụng được bật theo mặc định (trong khi cũng không bật những mô-đun bạn có thể cần).

Đọc tài liệu và kiểm tra trực tuyến trước khi loại bỏ hoặc thay thế chúng một cách mù quáng. Điều nguy hiểm là bạn vô hiệu hóa những thứ bạn cần (hoặc tệ hơn, một thứ giúp cải thiện hiệu suất). Bạn nên lập danh sách các dịch vụ / mô-đun bị vô hiệu hóa để tham khảo sau này hoặc đưa cho nhà thầu khi khắc phục sự cố.

7. Sử dụng phiên bản PHP mới nhất (INT-ADV, HIGH)

Chỉ riêng phiên bản PHP đã tạo ra sự khác biệt LỚN.

• Sử dụng phiên bản PHP mới nhất có thể! (Dễ dàng định cấu hình từ bảng điều khiển web hosting của bạn)
• Ví dụ, PHP 7.0 nhanh hơn 3 lần so với PHP 5.6.
• Ngay cả PHP 7.3 cũng nhanh hơn 10% so với PHP 7.2.
• Tại thời điểm viết bài này, PHP 8.0 đã có sẵn.
• Hãy cảnh giác với bất kỳ máy chủ web nào vẫn sử dụng PHP cũ!

Giữ cho trang web của bạn phiên bản PHP được cập nhật không chỉ để tăng tốc độ mà còn là bảo mật. Vấn đề duy nhất là một số chủ đề hoặc plugin có thể không tương thích với phiên bản PHP mới nhất. Bạn sẽ biết vì trang web của bạn không hoạt động bình thường hoặc trông kỳ lạ. Vì vậy, hãy kiểm tra cẩn thận và cập nhật các chủ đề / plugin để giúp chúng tương thích với PHP mới nhất.

8. Các cấu hình php.ini được đề xuất (INT, MED)

Hầu hết các bạn (trên dịch vụ lưu trữ được chia sẻ) thậm chí sẽ không có quyền truy cập vào các cài đặt này hoặc không biết cách đặt chúng. Nhưng dù sao, đây là những khuyến nghị của tôi.

• max_execution_time – thấp hơn (30-60 giây) là tốt hơn để ngăn tài nguyên bị trễ khỏi máy chủ. Nhưng bạn có thể cần thời gian thực thi cao hơn cho các quy trình dài như nhập, xuất, sao lưu.
• max_input_time – thấp hơn (60 giây) là tốt hơn. Chỉ tăng nếu bạn đang cố gắng nhập một thứ gì đó mất vĩnh viễn.
• max_input_vars – được đặt thành “1000”, trừ khi một số plugin cần cao hơn.
• memory_limit – hãy thử “256M” để an toàn. Nâng cao nếu bạn có các plugin nặng. Tôi muốn đặt thấp hơn để tôi được thông báo ngay lập tức khi có cache. “Error_log” sẽ cho bạn biết nếu bạn cần thêm.
• zlib.output_compression – có thể hữu ích hoặc không. Tôi bỏ nó đi.

9. Sử dụng phiên bản fork MySQL cập nhật (INT-ADV, LOW)

Hầu hết mọi người chỉ biết đến MySQL, hiện đã được Oracle mua lại / sở hữu. Ngoài ra còn có MariaDB (một nhánh của MySQL bởi những người sáng tạo ban đầu của nó) và Percona, và những người khác.

• MySQL 8 tốt hơn nhiều so với MySQL 5.7.
• Nhưng sẽ tốt hơn nếu bạn có thể sử dụng MariaDB trên MySQL. Thân thiện với cộng đồng và hiệu suất tốt hơn vani MySQL 5.7.
• Sử dụng phiên bản MariaDB mới nhất mà bạn có thể.
• Dù bạn làm gì, chỉ cần không sử dụng MySQL 5.7.

Còn Percona thì sao? Còn về các fork tương thích với MySQL của bên thứ 3 khác thì sao? Đối với hầu hết các trang web, nó tạo ra sự khác biệt nhỏ nếu có. Đừng quên sao lưu cơ sở dữ liệu của bạn trước khi thay đổi hoặc nâng cấp MySQL.

10. Chuyển đổi bảng MySQL từ MyISAM sang InnoDB (BEG, LOW)

• Đảm bảo rằng các bảng của bạn được đặt thành InnoDB thay vì MyISAM.
• InnoDB mới hơn và được coi là tốt hơn về tổng thể (nhanh hơn, an toàn hơn).
• MyISAM có thể nhanh hơn trong một số trường hợp (khi chủ yếu ở chế độ chỉ đọc).
• Bạn có thể chuyển đổi thủ công trong phpMyAdmin hoặc sử dụng một plugin (Servebolt Optimizer hoặc LiteSpeed ​​Cache). Có thể xóa plugin sau đó nếu bạn không cần.

11. Điều chỉnh cấu hình MySQL (ADV, LOW)

• Thường không bắt buộc (hoặc có lợi đáng kể) đối với trang web trung bình nhưng có thể giúp ích rất nhiều cho các trang web lớn với lưu lượng truy cập cao và độ dài truy vấn khác nhau.
• Bạn có thể chạy MySQLTuner để biết các khuyến nghị chung hoặc hỏi xung quanh cộng đồng quản trị viên hệ thống để xem những người khác sử dụng những gì.
• Kích thước bộ đệm, kích thước gói, bộ nhớ cache, kết nối, bộ nhớ cache, ngăn xếp, v.v … đều là những thứ chung cần điều chỉnh.
• Hướng dẫn Linode đơn giản.

Khi thử các cấu hình ngẫu nhiên trực tuyến hoặc sao chép của người khác, hãy đảm bảo rằng môi trường của họ tương tự như môi trường của bạn. Sự khác biệt chính là:

• kích thước máy chủ, tài nguyên có sẵn
• có bao nhiêu máy khách / trang web trên máy chủ
• có bao nhiêu người dùng cuối trên máy chủ
• lưu lượng bao nhiêu
• các trang web lớn như thế nào
• loại hành vi đọc / ghi

Điều quan trọng là phải biết liệu cài đặt của họ là để đạt hiệu quả (máy chủ web có người thuê cao) hay hiệu suất tích cực (máy chủ web của người thuê thấp).

12. Bộ nhớ đệm toàn trang của máy chủ (ADV, HIGH)

Bộ nhớ đệm toàn trang có thể giúp tăng tốc bất kỳ trang web nào. Nhưng bộ nhớ đệm trực tiếp từ máy chủ mạnh hơn và tiết kiệm tài nguyên hơn nhiều so với bộ đệm PHP / cấp ứng dụng được thực hiện thông qua một plugin.

• Một số máy chủ Apache hoặc NGINX sử dụng Varnish – đã lỗi thời. Không sử dụng proxy Varnish. Chỉ cần nâng cấp lên ngăn xếp Pure-LiteSpeed ​​hoặc pure-NGINX.
• Các máy chủ LiteSpeed ​​có thể sử dụng bộ đệm LiteSpeed ​​- mạnh mẽ, nhiều tính năng và đi kèm với một plugin bộ đệm WordPress tiện dụng (được gọi là “LiteSpeed ​​Cache”).
• Máy chủ NGINX có thể sử dụng FastCGI – tuyệt vời, siêu nhanh! Mặc dù không có plugin bộ nhớ cache NGINX chính thức cho WordPress, nhưng có nhiều plugin “NGINX trợ giúp” khác nhau để hỗ trợ các chức năng bộ nhớ cache cơ bản (như xóa).

Để an toàn, bạn nên tắt bộ nhớ đệm trên các trang có biểu mẫu, giỏ hàng hoặc thanh toán. Các trang riêng tư (dành cho người dùng đã đăng nhập) CÓ THỂ được lưu vào bộ nhớ đệm nhưng đừng gây rối với điều đó trừ khi bạn có nhiều lưu lượng truy cập riêng và sẵn sàng dành hàng giờ để định cấu hình bộ nhớ cache riêng.

Bạn chỉ có thể bật bộ nhớ đệm cấp máy chủ nếu bạn sở hữu hoặc có quyền truy cập vào máy chủ. Nếu không, máy chủ web của bạn sẽ quyết định những tùy chọn bộ nhớ đệm nào bạn có.

• Chia sẻ lưu trữ thường cho phép tất cả các plugin bộ nhớ đệm.
• Lưu trữ được quản lý thường giới hạn bạn chỉ với một tài khoản độc quyền của họ.

13. Memory object-caching (ADV, LOW-HIGH)

Bộ nhớ đệm đối tượng chỉ lưu vào bộ nhớ cache các truy vấn cơ sở dữ liệu thay vì toàn bộ trang html. Về mặt kỹ thuật, điều này làm cho nó “chậm hơn” so với bộ nhớ đệm toàn trang (vì bạn không lưu vào bộ nhớ đệm toàn bộ trang) nhưng hữu ích để tăng tốc các trang động hoặc trang riêng tư (người dùng đã đăng nhập, phần phụ trợ quản trị) không thể lưu vào bộ đệm tĩnh .

Bất kỳ trang web nào có nhiều dữ liệu được làm mới liên tục trên giao diện người dùng hoặc nhiều con số và báo cáo về phụ trợ… sẽ được hưởng lợi từ bộ nhớ đệm đối tượng. Hầu hết các trang web tĩnh hoặc các trang web có lưu lượng truy cập thấp sẽ không được hưởng lợi gì từ bộ nhớ đệm đối tượng; không sử dụng nó trên chúng… nó có thể làm cho chúng chậm hơn!

• Redis là tiêu chuẩn vàng trong bộ nhớ đệm đối tượng hiện nay. Nó vượt trội hơn so với memcache cũ hơn về mọi mặt.
• Memcache chỉ được sử dụng trong một số trường hợp hiếm hoi mà Redis không hoạt động hoặc chậm hơn.
• Nếu dữ liệu của bạn không thay đổi nhiều, bạn có thể đặt thời gian lưu vào bộ nhớ đệm đối tượng lâu hơn (ví dụ: 60 phút trở lên). Thời gian dài hơn có nghĩa là ít truy vấn cơ sở dữ liệu hơn.
• Nếu không, hãy giữ nguyên 5-10 phút mặc định để an toàn… trừ khi bạn không ngại người dùng nhìn thấy dữ liệu cũ.
• Bộ nhớ đệm đối tượng có thể được quản lý bởi các plugin WordPress. Lý tưởng nhất nếu bạn có một plugin bộ nhớ cache để quản lý cả bộ nhớ đệm toàn trang và bộ nhớ đệm đối tượng.

Bạn có thể nhận được bộ nhớ đệm đối tượng nhanh hơn ~ 25% bằng cách sử dụng Unix Socket

• Các ổ cắm UNIX được chạy từ lớp cấp thấp hơn trên mô hình mạng OSI và do đó nhanh hơn các ổ cắm TCP tiêu chuẩn.
• Hướng dẫn cấu hình Redis và Memcache UNIX cho CentOS.
• Hướng dẫn cấu hình ổ cắm Redis và Memcache UNIX cho Ubuntu.
• Lưu ý: với ổ cắm UNIX được bật, chỉ một tài khoản người dùng máy chủ (và có lẽ là tất cả các trang web của người dùng đó) mới có thể sử dụng bộ nhớ đệm đối tượng. Vì vậy, bạn không thể sử dụng điều này nếu bạn dự định có nhiều người dùng máy chủ triển khai bộ đệm đối tượng.

Một số thông tin cơ bản về memory-caching…

Memory-caching là tiêu chuẩn vàng trong bộ nhớ đệm, vì bộ nhớ đệm chạy từ bộ nhớ sẽ nhanh hơn từ đĩa. Vấn đề là chúng tôi có số lượng bộ nhớ hạn chế (hầu hết đã được sử dụng cho các ứng dụng) vì vậy chúng tôi không thể lưu trữ toàn bộ bộ nhớ cache của trang web trong đó. Dù sao thì ngày nay nó cũng ít quan trọng hơn vì đĩa máy chủ hiện nay nhanh hơn rất nhiều (nhờ công nghệ SSD).

Chắc chắn bây giờ bộ nhớ cũng dồi dào hơn nhưng sau đó, các ứng dụng lại lớn hơn. Bạn có thể đã nghe nói về những người khác tải toàn bộ trang web của họ vào bộ nhớ… một số sử dụng tuyến bộ nhớ cache, những người khác bằng cách gắn thư mục WordPress của họ vào bộ nhớ. Nó hoạt động tốt nếu trang web của bạn đủ nhỏ nhưng đối với hầu hết mọi người: bộ nhớ của bạn chỉ đủ lớn để lưu trữ các truy vấn cơ sở dữ liệu, mọi thứ khác bạn muốn lưu vào bộ nhớ cache sẽ được lưu trữ trên đĩa của bạn.

14. Sử dụng giao thức HTTP mới nhất (BEG, HIGH)

HTTP / 2 tải các yêu cầu trình duyệt nhanh hơn rất nhiều so với HTTP / 1 (nhờ tính năng song song). Tôi cảm thấy nó nhanh hơn gấp 3 lần.

• Bạn nên sử dụng HTTP / 2 hoặc thậm chí HTTP / 3 (được phát hành gần đây).
• Tránh các máy chủ web cũ hơn vẫn còn trên HTTP / 1 cổ điển.
• Kiểm tra trang web của bạn để tìm HTTP / 2 và HTTP / 3 .
• Sử dụng HTTP / 2 yêu cầu HTTPS / SSL. Nếu trang web của bạn không có trong HTTPS, hãy làm điều đó ngay bây giờ!

15. Mã hóa nội dung (INT, HIGH)

GZIP là như vậy năm 2016. Mọi máy chủ web ngày nay nên có tính năng nén BROTLI. Nó vượt trội hơn GZIP (tạo ra các tệp nhỏ hơn VÀ trong thời gian ngắn hơn). Nhưng thật đáng ngạc nhiên, BROTLI vẫn không có sẵn trên tất cả các máy chủ web.

• Nếu sử dụng BROTLI – hãy đặt nén tĩnh thành 4.
• Nếu sử dụng GZIP – đặt nén động thành 1, nén tĩnh thành 6.

Bạn có thể đẩy mức nén tĩnh lên cao hơn nếu CPU của bạn mạnh (hoặc máy chủ ít sử dụng) và / hoặc nội dung tĩnh của bạn được lưu trong bộ nhớ cache trong một thời gian dài (thời gian hết hạn dài). Nếu bạn đang sử dụng CDN hoặc Cloudflare, hãy đảm bảo rằng bạn cũng bật tính năng nén BROTLI ở đó.

16. Bảng điều khiển (INT, HIGH)

Vấn đề này chỉ quan trọng đối với người dùng VPS. Các bảng điều khiển từng bị phê bình về trọng lượng ban đầu mà chúng đặt trên máy chủ. Đó là bởi vì bảng điều khiển ban đầu được thiết kế cho các máy chủ chuyên dụng lớn, nhưng sau đó đã được tối ưu hóa cho VPS nhỏ hơn. Mặc dù đúng là không có bảng điều khiển sẽ nhẹ hơn việc có một bảng điều khiển, nhưng nó khiến các công việc hàng ngày trở nên khó khăn hơn. Dấu chân của chúng giờ đây không đáng kể nếu xét đến mức độ hữu ích của các tấm nền.

Bảng điều khiển hoạt động tốt nhất là bảng điều khiển phù hợp với nhu cầu của bạn.

• Cho phép bạn chọn máy chủ web mà bạn chọn – NGINX hoặc LiteSpeed.
• Dễ dàng định cấu hình chuyển hướng ở cấp máy chủ – thay vì plugin chuyển hướng cấp PHP chậm hơn.
• Dễ dàng định cấu hình các quy tắc lưu vào bộ nhớ đệm chi tiết – chọn nội dung nào và nội dung nào không lưu vào bộ nhớ đệm.
• Dễ dàng quản lý – cho bạn hoặc quản trị viên hệ thống của bạn.
• Có thể lồng người dùng – ngăn chặn tình trạng mất tài nguyên trên các máy chủ có lượng người thuê cao.
• Bảo mật trước các cuộc tấn công – vì các nỗ lực tấn công ăn cắp nhiều tài nguyên.
• Dễ sử dụng – cho bạn hoặc khách hàng của bạn.

17. Sử dụng dịch vụ DNS bên ngoài (INT, LOW)

• Độ trễ DNS thấp hơn (lợi ích nhỏ)
• Dễ dàng cập nhật DNS (tiện lợi)

Việc sử dụng DNS bên ngoài như Cloudflare hoặc DNS Made Easy có tạo ra sự khác biệt về tốc độ web hosting không? Tôi nghĩ rằng nó cải thiện thời gian tra cứu nhưng không quá đáng chú ý trừ khi máy chủ DNS trước đây của bạn là một mảnh rác của máy chủ web giá rẻ.

Lợi ích chính đối với tôi là tôi có thể chuyển hướng mọi thứ nhanh chóng như thế nào. Giả sử bạn bị tấn công và cần chuyển hướng thông qua proxy bảo mật. Hoặc có thể bạn đang chuyển một số khía cạnh của trang web của mình sang một máy chủ khác. Trong những thời điểm như thế này, có một dịch vụ DNS là rất tiện lợi. Bạn có thể chuyển đổi mọi thứ với rất ít thời gian chết và thậm chí chuyển đổi chúng trở lại nhanh chóng nếu có sự cố.

Các dịch vụ DNS có vẻ phức tạp hơn khi thiết lập, nhưng khi đã có sẵn, chúng cho phép bạn tích hợp các dịch vụ mới và giảm thiểu các vấn đề về hiệu suất nhanh hơn rất nhiều.

18. Chạy WP-cron từ máy chủ của bạn (BEG, MED)

Nhiều tác vụ WordPress cần một trình kích hoạt để hoạt động. Chẳng hạn như gửi email hệ thống, chạy sao lưu, phát hành các bài đăng theo lịch trình. Theo mặc định, WordPress sử dụng một chức năng có tên là WP-Cron (có vị trí thuận tiện tại yourdomain.com/wp-cron.php). Nó hoạt động bằng cách kiểm tra (và thực hiện) cho bất kỳ tác vụ đang chờ xử lý nào bất cứ khi nào ai đó truy cập trang web. Nó rất tốt cho các trang web nhỏ, nhưng thật tệ nếu bạn có rất nhiều lưu lượng truy cập (kích hoạt nhiều cuộc kiểm tra cron không cần thiết) cũng là một lỗ hổng DDOS rõ ràng.

Điều hợp lý là vô hiệu hóa WP-cron và sử dụng cron job thực sự cho dù từ máy chủ của bạn hay dịch vụ cron bên ngoài. Một số công việc cron truy cập trực tiếp vào trang web. Những người khác đi qua thư mục Linux. Sử dụng cái nào hiệu quả. Tôi nghĩ khoảng thời gian 5 phút là tốt.

19. Phân trang người dùng & giới hạn tài nguyên (ADV, MED-HIGH)

Bạn có nhiều trang web hoặc ứng dụng khách trên cùng một máy không? Bạn không thể cảnh sát tất cả chúng một cách hiệu quả? Nếu bạn đang mất quyền kiểm soát đối với người thuê của mình, có lẽ đã đến lúc giới hạn nguồn lực của họ. Tôi sẽ bắt đầu với bạn bằng một số chiến thuật dưới đây. Bạn tra cứu phần còn lại.

• Cloudlinux & CageFS – giới hạn mức sử dụng CPU và bộ nhớ
• Trên toàn máy chủ, cấm tạo trước bộ nhớ cache, trình kiểm tra liên kết bị hỏng và các ổ chứa tài nguyên khác.
• Giảm thời gian thực thi php.
• Cấu hình toàn cầu chặn những người vi phạm thông thường, bot, v.v.

Trường hợp xấu nhất, chỉ cần tách một số máy khách sang một máy chủ khác. Chia chúng ra theo kích thước, dung lượng sử dụng, lưu lượng truy cập, bất cứ điều gì bạn muốn.

20. Theo dõi nguồn tài nguyên (ADV, MED-HIGH)

Chúng tôi thường gặp sự cố máy chủ chậm mà không có manh mối rõ ràng về nơi để xem. Hôm nay, đó là khách hàng này. Ngày mai, đó là khách hàng. Có vẻ như bất kỳ trang web nào cũng có thể là thủ phạm vào bất kỳ ngày nào. Khi bạn có quá nhiều khách hàng và không ai trong số họ có đủ khả năng bật và tắt các plugin, thực sự rất khó để tìm ra vấn đề.

Đây là một số ý tưởng:

• Kiểm tra nhật ký máy chủ – bạn có đang bị tấn công không? Có yêu cầu quá mức không?
• Kiểm tra màn hình máy chủ – người dùng nào đang sử dụng CPU, bộ nhớ và băng thông?
• Khi bạn biết đó là trang web nào… hãy kiểm tra nhật ký lỗi WordPress. Chạy theo dõi truy vấn.
• Tất nhiên, nó thậm chí có thể không xảy ra mọi lúc. Bạn phải theo dõi xem người dùng hoặc quy trình đang làm gì khi xảy ra hiện tượng chậm máy.

Đôi khi bạn sẽ cần tâm lý của nhà phát triển nhiều hơn. Plugin nào được cập nhật lần cuối? Bất kỳ chủ đề hoặc plugin mới nào được mã hóa tùy chỉnh? (Kiểm tra các lệnh sử dụng hết bộ nhớ.) Có, bạn có thể sử dụng trình theo dõi ứng dụng như New Relic nhưng đối với tôi, nó quá mức cần thiết. Các vấn đề phức tạp nhất là khi có vẻ như mọi trang web đều có vấn đề. Hoặc cũng có khi máy chủ tải thấp nhưng các trang web vẫn chạy chậm. Chúc may mắn!

Trong phần tiếp theo của loạt bài blog này, chúng tôi sẽ đề cập đến việc tối ưu hóa bộ nhớ đệm cho các trang web của bạn, vì vậy hãy chú ý theo dõi. Để có phiên bản đầy đủ của bài viết, hãy truy cập Hướng dẫn Tối ưu hóa Tốc độ WordPress Cuối cùng.