Lưu trữ & hiệu suất
Cách chúng tôi tăng tốc WordPress: LiteSpeed Enterprise, LSCache và Redis cho từng trang web
Yêu cầu WordPress nhanh nhất là yêu cầu không bao giờ chạy — đây là cách ngăn xếp của chúng tôi xử lý hầu hết các lượt truy cập từ bộ nhớ đệm trước khi PHP hoặc MySQL được gọi, và điều đó có ý nghĩa gì đối với Core Web Vitals.
Yêu cầu nhanh nhất là yêu cầu không bao giờ chạy
Một yêu cầu WordPress tiêu chuẩn đòi hỏi rất nhiều tài nguyên. Máy chủ web chuyển giao cho PHP, PHP khởi động WordPress, chạy các plugin, truy vấn MySQL vài chục lần, lắp ráp HTML, và chỉ sau đó mới gửi dữ liệu phản hồi. Trên một trang web có lượng truy cập lớn, toàn bộ quá trình đó diễn ra cho mọi khách truy cập, và đó là nơi ngốn gần như toàn bộ thời gian phản hồi byte đầu tiên (time-to-first-byte) của bạn.
Giải pháp của chúng tôi là đảm bảo rằng, trong phần lớn các lượt truy cập, không có chuyện đó xảy ra chút nào. Trên các trang web mà chúng tôi lưu trữ — hơn 100.000 trang web PBN cộng với WordPress được quản lý thông thường — đại đa số lượt xem trang ở giao diện người dùng đều được phục vụ dưới dạng trang đầy đủ được kết xuất sẵn trực tiếp từ bộ nhớ đệm, mà không cần gọi PHP hay chạm vào cơ sở dữ liệu. Phần còn lại của bài viết này nói về cách các lớp tạo nên điều đó kết hợp với nhau như thế nào, và vị trí của từng lớp thể hiện giá trị ra sao.
Vấn đề quan trọng là đây không phải là các bộ nhớ đệm cạnh tranh mà bạn phải chọn một trong số đó. Bộ nhớ đệm toàn trang, bộ nhớ đệm đối tượng và biên CDN đều xử lý một nhóm yêu cầu khác nhau, và giá trị nằm ở cách chúng chuyển giao cho nhau.
LiteSpeed Enterprise + LSCache: tầng toàn trang
Mỗi trang web đều chạy trên LiteSpeed Enterprise với LSCache cấp độ máy chủ. Khi phản hồi của giao diện có thể lưu vào bộ nhớ đệm, máy chủ web sẽ đánh dấu phản hồi đó bằng các tiêu đề cache-control và tag của LiteSpeed, đồng thời LiteSpeed sẽ phục vụ toàn bộ trang trực tiếp trong lần truy cập tiếp theo — không có tiến trình PHP nào được tạo, không có truy vấn MySQL nào được thực thi. Đó là yếu tố quan trọng nhất tác động đến WordPress TTFB, bởi vì nó loại bỏ toàn bộ quá trình khởi động ứng dụng khỏi đường dẫn xử lý chính.
Vì LSCache nằm ngay bên trong máy chủ web thay vì trong một plugin PHP, nó bắt đầu hoạt động từ rất sớm trong vòng đời yêu cầu và lưu trữ các trang ở định dạng mà máy chủ có thể xả ngay lập tức. Một trình thu thập dữ liệu bộ nhớ đệm giữ cho các trang phổ biến luôn ở trạng thái sẵn sàng, do đó khách truy cập đầu tiên sau khi xóa bộ nhớ đệm không phải là người phải chịu chi phí tạo lại trang. Kết quả là TTFB thấp hơn rõ ràng và ổn định hơn nhiều so với bộ nhớ đệm chỉ dùng plugin được gắn thêm vào một ngăn xếp thông thường, nơi bộ nhớ đệm vẫn nằm phía sau PHP.
Plugin bộ nhớ đệm cấp độ kho lưu trữ của riêng chúng tôi được cài đặt sẵn và tự động cập nhật trên mọi trang web, kết nối WordPress với LSCache một cách chính xác ngay khi xuất xưởng. Trên máy chủ nguồn không phải LiteSpeed, nó đơn giản là không phát ra tiêu đề trang đầy đủ nào và tự động nhường chỗ, trong khi bộ nhớ đệm đối tượng và các quy tắc loại trừ vẫn tiếp tục thực hiện nhiệm vụ của mình — do đó, một trang web được di chuyển sẽ không bao giờ rơi vào trạng thái bị hỏng và cấu hình dang dở.
Duy trì tốc độ mà không phục vụ nội dung cũ: ESI và tính năng tự động dọn dẹp thông minh
Bộ đệm toàn trang mạnh mẽ có hai lỗi kinh điển: hiển thị trang của người khác cho người dùng đã đăng nhập và hiển thị trang đáng lẽ phải thay đổi cho bất kỳ ai. Cả hai vấn đề này đều được giải quyết ở tầng bộ đệm thay vì bằng cách giảm bớt việc lưu đệm.
ESI (Edge Side Includes) cho phép chúng ta lưu đệm trang web đồng thời để hở các phần cần phải giữ nguyên trạng thái trực tiếp. Trên một cửa hàng WooCommerce, các trang danh mục, sản phẩm và chuyên mục được phục vụ dưới dạng bộ đệm toàn trang để đạt được TTFB nhanh nhất có thể, trong khi ESI hiển thị đoạn giỏ hàng, tổng giỏ hàng thu gọn và trạng thái tài khoản cho mỗi yêu cầu. Giỏ hàng, thanh toán, tài khoản của tôi và bất kỳ trang mã xác thực (nonce) hoặc phiên làm việc nào đều bị loại trừ theo mặc định. Người mua sắm luôn nhìn thấy giỏ hàng của chính họ và một quy trình thanh toán hoạt động bình thường; mọi người vẫn nhận được mặt tiền cửa hàng từ bộ đệm.
Tính mới mẻ được xử lý bằng cơ chế tự động xóa bộ nhớ đệm thông minh. Các hook xóa tự động kích hoạt khi nội dung, sản phẩm, giá cả hoặc đơn hàng thay đổi, do đó các trang được lưu trong bộ nhớ đệm liên quan sẽ làm mới ngay lập tức thay vì theo hẹn giờ, và bạn cũng có thể xóa theo yêu cầu từ bảng điều khiển hoặc từ bên trong WordPress. Xóa bộ nhớ đệm dựa trên thẻ có nghĩa là chỉnh sửa một bài đăng sẽ xóa bài đăng đó và các lưu trữ của nó — chứ không phải toàn bộ bộ nhớ đệm — do đó một lần chỉnh sửa duy nhất không làm khởi động lạnh toàn bộ trang web.
Bộ nhớ đệm đối tượng Redis theo từng trang web: dành cho những gì không thể tạo thành một trang đầy đủ
Không phải mọi yêu cầu đều có thể là một trang tĩnh đầy đủ. Các phiên đăng nhập, trang quản trị WordPress, giỏ hàng WooCommerce, tìm kiếm và các phân đoạn động do ESI để lại đều phải chạy PHP. Đối với những trường hợp đó, mục tiêu chuyển từ 'bỏ qua ứng dụng' sang 'bỏ qua cơ sở dữ liệu'.
Mỗi trang web đều có bộ nhớ đệm đối tượng Redis chuyên dụng của riêng mình. WordPress lưu trữ kết quả của các lần đọc cơ sở dữ liệu lặp đi lặp lại — tùy chọn, biến tạm, tra cứu bài viết và phân loại, dữ liệu sản phẩm và phiên làm việc của WooCommerce — trong bộ nhớ, để truy vấn tương tự không phải chạy trên MySQL trong mỗi lần truy cập. Hiệu quả rõ rệt nhất chính là ở những nơi bộ nhớ đệm toàn trang không thể hỗ trợ: bảng điều khiển nhanh hơn, giỏ hàng nhanh hơn và tải cơ sở dữ liệu thấp hơn đáng kể khi có lưu lượng truy cập.
Bộ nhớ đệm đối tượng áp dụng riêng cho từng trang web chứ không dùng chung, điều này rất quan trọng đối với cả hiệu suất lẫn tính cô lập. Kết hợp với việc điều tiết cơ sở dữ liệu theo từng trang web, các truy vấn nặng hoặc được viết kém của một trang web không thể làm cạn kiệt tài nguyên cơ sở dữ liệu của các trang web lân cận. Bạn có thể tìm hiểu thêm về cách toàn bộ thiết lập đa tầng kết hợp với nhau trên trang tính năng bộ nhớ đệm của chúng tôi, cũng như về ranh giới giữa các đối tượng thuê trong mục tính cô lập.
Biên mạng và lớp vận chuyển bên dưới
Bộ nhớ đệm nằm trên máy chủ gốc vẫn phải truyền qua mạng. Phía trước máy chủ là điểm biên CDN, vì vậy các tài sản tĩnh và trang có thể lưu vào bộ nhớ đệm được phục vụ từ một điểm hiện diện ở gần khách truy cập, và máy chủ gốc vẫn yên tĩnh ngay cả khi chịu tải. Đối với dòng hosting không để lại footprint của chúng tôi, cùng một điểm biên đó là một nhóm đa CDN trải rộng trên nhiều nhà cung cấp, phục vụ cho mục tiêu footprint cũng như mục tiêu hiệu suất; trên WordPress thông thường, đó đơn giản là một lớp nhanh chóng, hoạt động hiệu quả giúp giữ cho các máy chủ gốc ở trạng thái rảnh rỗi.
Bên dưới, các yếu tố nền tảng không hề bị cắt xén. Các trang web chạy trên lưu trữ NVMe với HTTP/3, do đó những byte mà bộ nhớ đệm gửi đi sẽ được truyền tải qua một giao thức hiện đại, đa kênh với hệ thống lưu trữ tốc độ cao hỗ trợ cho mọi trường hợp không tìm thấy dữ liệu trong bộ nhớ đệm. Không có lớp nào trong số này là tính năng bổ sung: LiteSpeed, LSCache, Redis theo từng trang, NVMe và HTTP/3 là tiêu chuẩn cơ bản trên mọi gói dịch vụ, không phải là một bậc nâng cấp trả phí.
Những yếu tố nào thực sự tác động đến Core Web Vitals
Rất đáng để lưu ý chính xác, bởi vì dịch vụ lưu trữ thường bị thổi phồng về Core Web Vitals. TTFB là phần việc thuộc trách nhiệm của máy chủ, và hệ thống lưu trữ đệm bên dưới là yếu tố giúp giảm chỉ số này — một trang đầy đủ được lưu đệm và phân phối qua HTTP/3 từ biên mạng có mức TTFB thấp nhất có thể. Vì TTFB là yếu tố tiên quyết của Largest Contentful Paint, một nguồn gốc nhanh sẽ mang lại cho mọi chỉ số hạ nguồn một sự khởi đầu thuận lợi mà nếu không có nó thì không thể đạt được.
Nhưng các chỉ số LCP, CLS và INP chủ yếu được quyết định ở trình duyệt, bởi chính trang web đó: hình ảnh chính chưa được tối ưu, CSS và JavaScript chặn hiển thị, bố cục dịch chuyển khi phông chữ và quảng cáo tải, cùng lượng công việc nặng nề trên luồng chính từ các plugin. Không mức độ bộ nhớ đệm máy chủ nào có thể khắc phục được hình ảnh chính 2 MB hoặc một chủ đề chứa hàng megabyte JavaScript. Dịch vụ lưu trữ trung thực giúp phần đóng góp của máy chủ trở nên hiệu suất cao và nhất quán, sau đó phần còn lại phụ thuộc vào trang web để giữ cho giao diện người dùng gọn gàng.
Sự phân chia công việc đó là một mô hình tư duy hữu ích. Chúng tôi đảm bảo yêu cầu đến trình duyệt nhanh chóng và duy trì tốc độ đó dưới lượng truy cập lớn; bạn giữ cho tải trọng nhỏ và ổn định. Nơi cả hai gặp nhau — làm ấm bộ nhớ đệm, phân phối ở biên và duy trì phản hồi của cơ sở dữ liệu để các trang động không bị đình trệ — chính xác là nơi ngăn xếp của chúng tôi được tinh chỉnh, và đó là điều khiến WordPress được quản lý trên nền tảng này nhanh hơn so với cùng một trang web trên một máy chủ lưu trữ thông thường.
Các câu hỏi thường gặp
Tôi có cần cài plugin bộ nhớ đệm như WP Rocket không?
Không. Tính năng lưu đệm toàn bộ trang được xử lý ở máy chủ web bởi LSCache của LiteSpeed, và plugin bộ nhớ đệm của riêng chúng tôi — được cài đặt sẵn và tự động cập nhật — kết nối WordPress với tính năng đó một cách chính xác, đi kèm với bộ nhớ đệm đối tượng Redis cho mỗi trang web ở phía sau. Việc cài đặt thêm một plugin lưu đệm toàn bộ trang thứ hai thường sẽ xung đột với bộ nhớ đệm cấp máy chủ thay vì hỗ trợ, do đó nó không cần thiết và không được khuyến nghị.
Việc lưu trữ đệm (caching) có làm hỏng giỏ hàng WooCommerce hoặc các trang đã đăng nhập của tôi không?
Không. Trang giỏ hàng, thanh toán, tài khoản của tôi và bất kỳ trang nonce hoặc phiên làm việc nào đều bị loại khỏi bộ nhớ đệm theo mặc định, đồng thời ESI giữ cho phân đoạn giỏ hàng và tổng số tiền luôn hoạt động trên các trang được lưu vào bộ nhớ đệm khác. Người mua sắm luôn nhìn thấy giỏ hàng của riêng họ và trang thanh toán hoạt động bình thường trong khi mặt tiền cửa hàng vẫn tải từ bộ nhớ đệm.
Bộ nhớ đệm được làm mới như thế nào khi tôi xuất bản hoặc chỉnh sửa?
Tính năng tự động xóa bộ nhớ đệm thông minh hoạt động trên các hook WordPress liên quan, vì vậy việc xuất bản, chỉnh sửa nội dung hoặc thay đổi sản phẩm, giá cả hoặc đơn hàng sẽ chỉ làm sạch các trang bị ảnh hưởng và trang lưu trữ của chúng — chứ không phải toàn bộ bộ nhớ đệm — và một trình thu thập dữ liệu sẽ tải lại chúng. Bạn cũng có thể xóa bộ nhớ đệm theo yêu cầu từ bảng điều khiển hoặc từ bên trong WordPress.
Liệu chỉ riêng dịch vụ lưu trữ web có thể mang lại cho tôi các chỉ số Core Web Vitals hoàn hảo không?
Nó mang lại cho bạn TTFB tốt nhất có thể, đó là phần đóng góp của máy chủ và là bước đệm thuận lợi cho Largest Contentful Paint. Nhưng LCP, CLS và INP phần lớn do chính trang web quyết định — kích thước hình ảnh, tài nguyên chặn hiển thị, độ ổn định bố cục và JavaScript trên luồng chính. Ngăn xếp của chúng tôi giúp phản hồi từ máy chủ nhanh chóng và ổn định; việc giữ cho tải trọng của front-end gọn nhẹ mới là cách khỏa lấp phần khoảng trống còn lại.
Liên quan
Dùng thử miễn phí 14 ngày
Triển khai các trang web đầu tiên của bạn miễn phí trong 14 ngày — không cần thẻ. Bạn đang chuyển một mạng lưới hiện có? Lần chuyển đổi đầu tiên của bạn là do chúng tôi tài trợ.
Dùng thử miễn phí