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