Hướng dẫn tối ưu tăng tốc độ website nâng cao – Phần 1 – Tối ưu Web Hosting

Trong thời đại số hóa ngày nay, tốc độ của trang web không chỉ là một yếu tố quan trọng mà còn là điểm tựa quyết định giữa thành công và thất bại. Người dùng hiện đại đòi hỏi sự nhanh chóng và mượt mà khi truy cập các trang web, và các công cụ tìm kiếm cũng ưa thích những trang có hiệu suất tốt hơn. Chính vì vậy, việc tối ưu hóa tốc độ trang web của bạn trở thành một phần quan trọng của chiến lược trực tuyến.

Trong loạt bài viết này, chúng tôi sẽ hướng dẫn bạn từng bước cách tối ưu hóa và tăng tốc độ website của mình lên một tầm cao mới. Phần 1 của loạt bài này sẽ tập trung vào việc tối ưu hóa web hosting, một trong những yếu tố cơ bản định hình hiệu suất của trang web của bạn.

Hãy cùng khám phá những cách thức cụ thể để cải thiện tốc độ và hiệu suất của trang web của bạn thông qua việc tối ưu hóa web hosting, và bắt đầu cuộc hành trình đầy hứa hẹn để nâng cao trải nghiệm của người dùng và thu hút nhiều khách hàng hơn.

Giới thiệu

Tốc độ của dịch vụ lưu trữ web của bạn xác định tốc độ 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 một chiếc xe chạy nhanh hơn, bạn có hai lựa chọn: A) lắp động cơ mạnh hơn và/hoặc B) giảm bớt trọng lượng. Đối với trang web, máy chủ web là “động cơ” và mã là “trọng lượng”.

Mục tiêu của chúng ta là cải thiện “động cơ” máy chủ web trong khi giảm bớt “trọng lượng” mã, đơn giản như vậy thôi!

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

Khác biệt không chỉ là về tốc độ mà còn về 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 so với một máy chủ chậm. Nếu máy chủ của bạn có thể xử lý gấp đôi lượng lưu lượng, lý thuyết là hóa đơn có thể giảm đi gấp đôi. Điều này không quá quan trọng đối với một trang web nhỏ, nhưng đối với một trang web thương mại điện tử lớn với hóa đơn máy chủ 1.000 đô la/tháng, việc giảm 50% chi phí trông vô cùng hấp dẫn!

Lựa chọn vị trí trung tâm dữ liệu gần bạn

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

Các doanh nghiệp địa phương nên đặt máy chủ càng gần càng tốt với người truy cập của họ. Hãy giữ nó trong khoảng 100ms hoặc ít hơn, trong khoảng 50ms là tốt nhất. Kiểm tra thời gian ping với WonderNetwork.

Những người trong bạn nghĩ rằng một CDN có thể bù đắp cho việc đặt máy chủ xa (điều này không nhất thiết là đúng!)

Lựa chọn dịch vụ lưu trữ web phù hợp

• Lưu trữ chia sẻ ($5-30/tháng) – thích hợp cho các trang web nhỏ và lưu lượng thấp lên đến 100,000 lượt truy cập/tháng. Không có quyền truy cập vào cấu hình máy chủ. Lựa chọn an toàn bao gồm Host Armada – Rocket.net

• Lưu trữ VPS/đám mây ($30-300/tháng) – tốt cho các trang web trung bình và lưu lượng lên đến 30 triệu lượt truy cập/tháng. Lựa chọn an toàn bao gồm Gridpane hoặc thử một dịch vụ VPS được quản lý hoàn toàn.

• Máy chủ riêng (bare metal) ($200/tháng trở lên) – tốt cho các trang web lớn với LƯỢNG lưu lượng khổng lồ. Lựa chọn an toàn là LiquidWeb.

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

• Share hosting thường chậm vì họ đổ hàng trăm khách hàng/trang web vào cùng một máy chủ (tối ưu hóa lợi nhuận). Điều này làm tăng sự trễ, sự cố hoặc khởi động lại máy chủ đột ngột, tấn công bảo mật và địa chỉ IP email của bạn bị đánh dấu là thư rác.

• Môi trường lưu trữ chia sẻ cũng chậm vì họ tải nhiều kịch bản/module để tối ưu hóa khả năng tương thích cho càng nhiều người dùng càng tốt. Và mà không có tài nguyên dành riêng, khách truy cập của bạn cuối cùng sẽ phải đợi trong hàng chờ trong khi máy chủ đang bận xử lý các trang web khác trước.

• VPS/Máy chủ riêng (bare metal) 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 phục vụ chỉ cho 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 bạn, có thể cấu hình nó cho nhu cầu của bạn. VPS/Máy chủ riêng 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ụ trình quản lý đá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 tất 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ể chọn “lưu trữ chia sẻ cao cấp” như Rocket hoặc WP Engine. Họ không đông đúc máy chủ nhiều nhưng hiệu suất (mặc dù tốt hơn so với lưu trữ chia sẻ thông thường) vẫn sẽ xa hơn so với một VPS.

Chọn một máy chủ web hiệu suất cao

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 cấp (hiếm khi gặp). Càng có nhiều lưu lượng truy cập của bạn, sự khác biệt càng rõ rệt.

NGINX rất phù hợp cho các trang web đơn giản. Chỉ cần cài đặt và sử dụng. Không có nhiều thiết lập để tối ưu hóa. Nhưng khi bạn có một trang web phức tạp, NGINX có nhược điểm. Một số tính năng của NGINX không dễ cấu hình. Nếu bạn có một quản trị máy chủ để điều chỉnh, thì nó rất tốt, nhưng nhiều người không có điều đó.

LiteSpeed có nhiều tính năng dễ truy cập hơn so với NGINX. Ví dụ, khi bạn cần lưu trữ một số thứ nhưng không phải tất cả, hoặc xử lý chuyển hướng cấp độ máy chủ qua htaccess. LiteSpeed cũng có một plugin bộ nhớ cache cho WordPress mà NGINX không có. Điều đó thật là một lợi thế LỚN. (Cá nhân tôi thích LiteSpeed.)

OpenLiteSpeed là phiên bản cộng đồng miễn phí của LiteSpeed. Đó là một lựa chọn tuyệt vời cho những người muốn giá miễn phí của NGINX nhưng với plugin bộ nhớ cache mạnh mẽ của LiteSpeed.

Một số nhà cung cấp dịch vụ lưu trữ web có cấu trúc kết hợp Apache+NGINX. Tôi cảm thấy rằng những cấu trúc đó hiện đã lỗi thời và làm cho kết cấu chậm và nặng hơn không cần thiết.

Nếu sử dụng Apache, MPM events là tốt nhất (so với worker hoặc prefork).

Hãy luôn cập nhật máy chủ web của bạn. Các phiên bản sau có thể làm tăng đáng kể hiệu suất của một số giao thức và quy trình.

Cấu hình máy chủ web

Hầu hết các máy chủ web đi kèm với cấu hình an toàn/hoạt động ngay lập tức. Đủ cho các trang web nhỏ trung bình với lưu lượng thấp. Điều quan trọng là khi bạ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ó các ứng dụng đòi hỏi nhiều hơn, việc điều chỉnh cấu hình sẽ tạo ra sự khác biệt lớn.

• Thời gian chờ (Timeout) – Từ 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 cao hơn nếu cần cho các quy trình dài hạn (nhập, xuất, sao lưu). Hãy lưu ý rằng điều này cho phép các quy trình viết mã kém hoặc lợi dụng lỗ hổng bảo mật chạy ra ngoài tài nguyên máy chủ của bạn.

• Số lượng tiến trình con được phép (child processes) – phụ thuộc vào môi trường máy chủ. Cài đặt mặc định nên là đủ.

• Kết nối đồng thời được phép (Concurrent connections) – từ 1-20k. Cao hơn không nhất thiết tốt hơn!

• Giữ kết nối sống (Keep alive) – bật, tắt, hoặc sử dụng “smart keep-alive” của LiteSpeed. Tôi nghĩ là “bật” là an toàn hơn. Nếu bạn sử dụng LiteSpeed, smart keep-alive rất tuyệt!

• Thời gian giữ kết nối sống (Keep alive timeout) – từ 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 cơ thể/bộ đệm, người làm việc, khách hàng, v.v…. tất cả bạn có thể tìm kiếm trực tuyến. Điều này phụ thuộc vào kích thước máy chủ của bạn và tình huống sử dụng. Tham gia vào các diễn đàn và hỏi hoặc có một quản trị hệ thống cấu hình giúp bạn. Hãy nhớ rằng các quản trị viên khác có cách cấu hình riêng của họ.

Sự phân 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 thiết lập cấu hình mạnh mẽ hay thận trọng:

• Cấu hình AGGRESSIVE – cung cấp cho mỗi trang web càng nhiều tài nguyên càng tốt. Tốt cho máy chủ ít người sử dụng hoặc máy chủ riêng.

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

Tắt các dịch vụ không sử dụng

Nhiều máy chủ được thiết lập tự động với tất cả các tính năng đang chạy để đơn giản hóa quá trình cho bạn. Nhưng chúng giống như các máy tính mới với phần mềm được cài sẵn. Loại bỏ những phầ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 các hacker và điều đó sẽ tiêu thụ 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, vv.)

• Email – tắt nếu bạn đang sử dụng dịch vụ email của bên thứ ba. (G-Suite, MXroute, vv.)

• 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, vv.

Nếu bạn muốn chi tiết (OCD), hãy quét hệ thống của bạn để xem tất cả các cổng và dịch vụ đang lắng nghe.

Xóa các mô-đun máy chủ không sử dụng

Muốn trở nên chi tiết hơn nữa? Tắt mọi mô-đun không được sử dụng bởi máy chủ. Một số trong số chúng là các thứ không cần thiết cho máy chủ; những thứ khác là các thứ không cần thiết cho bản phân phối Linux. Các kết cấu tương thích với Apache theo trường phái cũ hoặc các bảng điều khiển không được tối ưu hóa thường có nhiều mô-đun không được sử dụng được kích hoạt theo mặc định (trong khi cũng không kích hoạt những mô-đun mà bạn có thể cần).

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

Sử dụng phiên bản PHP mới nhất

Phiên bản PHP đã tạo ra SỰ KHÁC BIỆT LỚN.

Hãy sử dụng phiên bản PHP mới nhất có thể! (Dễ dàng cấu hình từ bảng điều khiển lưu trữ web 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. Vào thời điểm viết bài này, PHP 8.2.9 đã có sẵn.

• Hãy cẩn thận với bất kỳ dịch vụ lưu trữ web nào vẫn sử dụng phiên bản PHP cũ!

• Việc duy trì phiên bản PHP của trang web của bạn không chỉ giúp tăng tốc độ mà còn đảm bảo tính 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 đúng cách hoặc trông kỳ cục.

Vì vậy, hãy kiểm tra một cách cẩn thận và duy trì việc cập nhật các chủ đề/plugin, điều này giúp chúng duy trì tính tương thích với phiên bản PHP mới nhất.

Cấu hình php.ini được đề xuất

Hầu hết các bạn (đang sử dụng dịch vụ lưu trữ chia sẻ) có thể không có quyền truy cập đến các cài đặt này hoặc không biết cách thiết lập chúng. Tuy nhiên, dưới đây là những đề xuất của tôi.

• max_execution_time – thấp hơn (30-60 giây) tốt hơn để ngăn các quy trình tài nguyên khỏi làm chậm máy chủ. Nhưng bạn có thể cần thời gian thực hiện 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) tốt hơn. Tăng lên chỉ khi bạn cố gắng nhập cái đó mất mãi mãi.

• max_input_vars – đặt thành “1000”, trừ khi một số plugin yêu cầu giá trị cao hơn.

• memory_limit – hãy thử “256M” để đảm bảo an toàn. Tăng nếu bạn có các plugin nặng. Tôi thích đặt giá trị thấp hơn để tôi được thông báo ngay lập tức khi có các quy trình tài nguyên. “error_log” sẽ cho bạn biết nếu bạn cần thêm.

• zlib.output_compression – có thể có ích hoặc không. Tôi thường để nó tắt.

Sử dụng phiên bản MySQL cập nhật

Hầu hết mọi người chỉ biết về MySQL, hiện đang được mua lại/sở hữu bởi Oracle. Còn có MariaDB (một phiên bản phân nhánh của MySQL do các nhà sáng tạo ban đầu của nó tạo ra) và Percona, cũng như các lựa chọn khác.

• MySQL 8 tốt hơn rất nhiều so với MySQL 5.7.

• Nhưng tốt hơn nếu bạn có thể sử dụng MariaDB thay vì MySQL. Thân thiện với cộng đồng và hiệu suất tốt hơn so với MySQL phiên bản gốc 5.7.

• Hãy sử dụng phiên bản MariaDB mới nhất mà bạn có thể.

Dù bạn làm gì, chỉ đừng sử dụng MySQL 5.7.

Còn Percona thì sao? Còn những phiên bản phân nhánh MySQL tương thích bên thứ ba khác? Đối với hầu hết các trang web, sự khác biệt ít quan trọng hoặc không quan trọng. Đừ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.

Chuyển đổi bảng MySQL từ MyISAM sang InnoDB

• Hãy đảm bảo rằng các bảng của bạn được thiết lập để sử dụng InnoDB thay vì MyISAM.

• InnoDB mới hơn và được coi là tốt hơn tổng thể (nhanh hơn, an toàn hơn).

• MyISAM có thể nhanh hơn trong một số tình huống (khi chủ yếu là 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). Sau đó, bạn có thể xóa plugin nếu bạn không cần nó nữa.

Cấu hình MySQL

• Thường không cần thiết (hoặc không đáng kể) đối với trang web trung bình nhưng có thể giúp đỡ rất nhiều đối với các trang web lớn với lưu lượng cao và độ dài truy vấn thay đổi.

• Bạn có thể chạy MySQLTuner để nhận các đề xuất tổng quan hoặc tham khảo cộng đồng quản trị hệ thống để xem mọi người khác đang sử dụng gì.

• Các thiết lập như kích thước bộ đệm, kích thước gói tin, bộ đệm, kết nối, bộ đệm, ngăn xếp, v.v… đều là những điều tổng quan mà bạn có thể tinh chỉnh.

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

• Kích thước máy chủ, tài nguyên có sẵn

• Có bao nhiêu khách hàng/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 truy cập là bao nhiêu

• Kích thước của các trang web

• Hành vi đọc/viết là gì

Quan trọng là biết xem các cài đặt của họ được thiết lập cho hiệu suất hiệu quả (máy chủ lưu trữ nhiều người sử dụng) hoặc hiệu suất mạnh mẽ (máy chủ lưu trữ ít người sử dụng).

Lưu trữ trang web tại cấp máy chủ

Lưu trữ trang web toàn bộ có thể giúp tăng tốc bất kỳ trang web nào. Tuy nhiên, lưu trữ trực tiếp từ máy chủ mạnh mẽ hơn và tiết kiệm tài nguyên hơn so với lưu trữ trình ứng dụng PHP cấp độ qua plugin.

• Một số máy chủ Apache hoặc NGINX sử dụng Varnish – quá lỗi thời. Đừng sử dụng Varnish proxy. Hãy nâng cấp lên bộ xử lý pure-LiteSpeed hoặc pure-NGINX.

• Máy chủ LiteSpeed có thể sử dụng bộ nhớ đệm LiteSpeed – mạnh mẽ, nhiều tính năng và đi kèm với một plugin lưu trữ WordPress tiện lợi (gọi là “LiteSpeed Cache”).

• Máy chủ NGINX có thể sử dụng FastCGI – tuyệt vời, cực kỳ nhanh chóng! Mặc dù không có plugin lưu trữ chính thức của NGINX cho WordPress, có nhiều plugin “NGINX helper” khác nhau để hỗ trợ các chức năng lưu trữ cơ bản (như xóa bộ nhớ đệm).

Để đảm bảo an toàn, bạn nên tắt lưu trữ trên các trang có biểu mẫu, giỏ hàng hoặc trang thanh toán. Các trang riêng tư (cho người dùng đã đăng nhập) CÓ THỂ được lưu trữ đệm nhưng không can thiệp vào điều đó trừ khi bạn có lưu lượng riêng tư đó và sẵn sàng dành hàng giờ để cấu hình lưu trữ riêng tư.

Bạn chỉ có thể bật lưu trữ 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, nhà cung cấp dịch vụ lưu trữ web của bạn sẽ quyết định các tùy chọn lưu trữ bạn có.

• Dịch vụ lưu trữ chia sẻ thường cho phép tất cả các plugin lưu trữ.

• Dịch vụ lưu trữ quản lý thường giới hạn bạn chỉ có thể sử dụng một số plugin riêng của họ.

Bộ nhớ cache đối tượng

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

Bất kỳ trang web nào có nhiều dữ liệu luôn được cập nhật trên giao diện trước, hoặc nhiều số liệu và báo cáo trên giao diện sau… đều có lợi từ việc cache đối tượng. Các trang web chủ yếu tĩnh hoặc có lưu lượng thấp sẽ không có lợi từ cache đối tượng; đừng sử dụng nó trên chúng… điều này có thể làm cho chúng trở nên chậm hơn!

• Redis hiện nay được coi là tiêu chuẩn và mạnh mẽ trong việc cache đối tượng.

• Redis vượt trội so với memcache cũ ở hầu hết mọi khía cạnh.

• Memcache chỉ được sử dụng trong các tình huống hiếm khi Redis không hoạt động hoặc chậm hơn.

• Nếu dữ liệu của bạn thay đổi ít, bạn có thể đặt thời gian cache đối tượng lâu hơn (ví dụ, 60 phút trở lên). Thời gian lâu hơn đồng nghĩa với ít truy vấn cơ sở dữ liệu hơn.

• Nếu không, hãy tuân theo thời gian mặc định 5-10 phút để đảm bảo an toàn… trừ khi bạn không phiền người dùng thấy dữ liệu đã cũ.

• Cache đối tượng có thể được quản lý bằng các plugin WordPress. Lý tưởng nhất nếu bạn có một plugin cache để quản lý cả việc lưu trữ trang toàn bộ và lưu trữ đối tượng.

Bạn có thể có được tốc độ cache đối tượng nhanh hơn khoảng 25% bằng cách sử dụng Unix Socket

• UNIX socket chạy từ một tầng niêm phong thấp hơn trên mô hình mạng OSI và do đó nhanh hơn so với socket TCP tiêu chuẩn.

• Lưu ý: khi bật socket UNIX, chỉ có một tài khoản người dùng máy chủ duy nhất (và có lẽ tất cả các trang web của người dùng đó) có thể sử dụng cache đối tượng. Vì vậy, bạn không thể sử dụng tính năng này nếu bạn có kế hoạch sử dụng nhiều tài khoản người dùng máy chủ khác nhau cho cache đối tượng.

Một số thông tin cơ bản về cache bộ nhớ…

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

Tất nhiên, bộ nhớ hiện nay cũng phong phú hơn nhưng lưu ý rằng các ứng dụng cũng lớn hơn. Bạn có thể nghe nói về người khác tải toàn bộ trang web của họ vào bộ nhớ… một số người sử dụng đường dẫn cache, người khác sử dụng thư mục WordPress của họ để lưu trữ trong bộ nhớ. Điều này 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ưu trữ các truy vấn cơ sở dữ liệu, bất kỳ điều gì bạn muốn lưu trữ đối tượng sẽ được lưu trữ trên ổ đĩa của bạn.

Sử dụng giao thức HTTP mới nhất

HTTP/2 tải các yêu cầu từ trình duyệt nhanh hơn nhiều so với HTTP/1 (nhờ khả năng song song). Đối với tôi, nó cảm giác nhanh hơn gấp ba lần.

• Bạn nên sử dụng HTTP/2 hoặc thậm chí là HTTP/3 (vừa được phát hành gần đây).

• Tránh các máy chủ web cũ sử dụng HTTP/1 lạc hậu.

• Kiểm tra trang web của bạn để xem liệu nó có sử dụng HTTP/2 và HTTP/3 hay không.

• Việc sử dụng HTTP/2 yêu cầu HTTPS/SSL.

• Nếu trang web của bạn chưa được cài đặt HTTPS, hãy thực hiện ngay bây giờ!

Mã hóa nội dung

GZIP đã quá cũ kỹ từ năm 2016. Hiện nay, mọi máy chủ web nên có 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 đáng kinh ngạc, BROTLI vẫn chưa có sẵn trên tất cả máy chủ web.

• Nếu sử dụng BROTLI – đặt mức nén tĩnh thành 4.

• Nếu sử dụng GZIP – đặt mức nén động thành 1, mức nén tĩnh thành 6.

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

Bảng điều khiển (Control-panel)

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

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 muốn – NGINX hoặc LiteSpeed.

• Dễ dàng cấu hình chuyển hướng ở mức máy chủ – thay vì sử dụng plugin chuyển hướng ở mức PHP chậm hơn.

• Dễ dàng cấu hình quy tắc cache chi tiết – lựa chọn cái gì và cái gì không được lưu trữ.

• Dễ quản lý – dành cho bạn hoặc sys-admin của bạn.

• Có thể hạn chế người dùng – ngăn chặn nguồn lực lớn trên các máy chủ có nhiều người sử dụng.

• Bảo mật chống lại hacker – vì các cuộc tấn công hacker tiêu tốn nhiều tài nguyên.

• Dễ sử dụng – dành cho bạn hoặc khách hàng của bạn.

Sử dụng dịch vụ DNS bên ngoài

• Giảm độ trễ DNS

• Dễ dàng cập nhật DNS

Việc sử dụng dịch vụ DNS bên ngoài như Cloudflare hoặc DNS Made Easy có làm thay đổi đáng kể về tốc độ webhosting không? Tôi nghĩ rằng nó cải thiện thời gian tra cứu nhưng không quá rõ rệt trừ khi máy chủ DNS trước đó của bạn quá tệ do dịch vụ webhosting rẻ tiền.

Lợi ích chính đối với tôi là tốc độ chuyển hướng. Giả sử bạn bị hack và cần chuyển hướng thông qua một 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 bạn sang máy chủ khác. Trong những khoảnh khắc như vậy, có dịch vụ DNS là rất tiện lợi. Bạn có thể chuyển đổi mọi thứ với thời gian chết chóc rất ít, và thậm chí có thể chuyển đổi lại nhanh chóng nếu có vấn đề.

Dịch vụ DNS có thể dường như là một phiền toái thêm khi cài đặt, nhưng một khi đã được thiết lập, 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 một cách nhanh chóng.

Chạy WP-cron từ máy chủ của bạn

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

Một số tác vụ cron truy cập trang web trực tiếp. Các tác vụ khác đi qua thư mục Linux. Sử dụng tùy theo công việc nào hoạt động. Tôi nghĩ khoảng cách 5 phút là tốt.

Hạn chế người dùng và giới hạn tài nguyên (Caging users & resource limits)

Bạn có nhiều trang web hoặc khách hàng trên cùng một máy chủ không? Bạn không thể kiểm soát họ một cách hiệu quả? Nếu bạn đang mất kiểm soát với những người thuê của mình, có lẽ đã đến lúc giới hạn tài nguyên của họ. Dưới đây, tôi sẽ giới thiệu một số chiến thuật cơ bản. Bạn có thể tìm hiểu thêm về các chiến thuật khác.

• Sử dụng Cloudlinux & CageFS – giới hạn việc sử dụng CPU và bộ nhớ

• Cấm toàn bộ máy chủ truy cập trước để xây dựng bộ nhớ cache, kiểm tra các liên kết hỏng và các tài nguyên gây tốn kém khác.

• Giảm thời gian thực thi PHP.

• Cấu hình toàn cầu chặn các yếu tố thường gây tốn kém, bot, vv.

• Trong tình huống tồi tệ nhất, bạn có thể tách một số khách hàng sang máy chủ khác. Phân chia họ theo kích thước, dung lượng không gian, lưu lượng mạng, hoặc bất kỳ tiêu chí nào bạn muốn.

Theo dõi những tài nguyên gây tốn kém (Tracking down resource hogs)

Thường xuyên chúng ta gặp vấn đề về máy chủ chạy chậm mà không có gợi ý rõ ràng về nơi để tìm kiếm. Hôm nay, đó là khách hàng này. Ngày mai, đó là khách hàng khác. Dường như bất kỳ trang web nào cũng có thể là nguyên nhân vào bất kỳ ngày nào. Khi bạn có nhiều khách hàng như vậy và không có ai có khả năng chuyển đổi các plugin một cách thường xuyên, việc theo dõi vấn đề thực sự rất khó khăn.

Dưới đây là một số ý tưởng:

• Kiểm tra các nhật ký máy chủ – bạn có bị hack không? Có yêu cầu nhiều quá không?

• Kiểm tra các máy giám sát máy chủ – người dùng nào đang tốn nhiều CPU, bộ nhớ và băng thông?

• Khi bạn biết được đó là trang web nào… kiểm tra nhật ký lỗi WordPress. Chạy Query Monitor.

• Tất nhiên, có thể chúng không xảy ra liên tục. Bạn phải theo dõi những người dùng hoặc quy trình đã làm gì khi xảy ra sự chậm trễ.

Đôi khi bạn cần có tư duy như một nhà phát triển. Plugin nào đã được cập nhật gần đây nhất? Có chủ đề hoặc plugin mới nào được viết mã tùy chỉnh? (Kiểm tra các lệnh tiêu thụ bộ nhớ.) Vâng, bạn có thể sử dụng các công cụ giám sát ứng dụng như New Relic nhưng với tôi, đó là quá nhiều công cụ. Những vấn đề khó khăn nhất là khi có vẻ như mọi trang web đều là vấn đề. Hoặc cũng khi tải máy chủ thấp nhưng trang web vẫn chạy chậm. Chúc bạn may mắn!