Tối ưu hóa WordPress hiệu quả với WP_Query
Hầu hết các developer WordPress khi lấy các bài viết, các trang và các nội dung khác phù hợp với các tiêu chí cụ thể từ cơ sở dữ liệu. Thông thường chúng ta không cần phải tạo các truy vấn SQL (và thường thì chúng ta không nên làm) vì lớp WP_Query và các phương thức của nó cung cấp cho chúng ta một cách an toàn và hiệu quả để lấy dữ liệu từ cơ sở dữ liệu. Chúng ta chỉ cần khai báo một mảng các đối số và đối tượng $query sẽ xây dựng truy vấn SQL thực tế.
Trong bài này, tôi sẽ giả sử bạn đã biết các vấn đề cơ bản của lớp WP_Query, các phương thức và thuộc tính của nó, và nơi để tìm một danh sách các biến có sẵn.
Khi lưu lượng truy cập và nội dung bị hạn chế, chúng tôi thường không quan tâm đến hiệu quả của các truy vấn của chúng tôi. WordPress xây dựng các truy vấn SQL được tối ưu hóa tốt và cung cấp một hệ thống bộ nhớ đệm.
Khi lưu lượng truy cập và nội dung trang web phát triển đáng kể, lên đến hàng nghìn bài đăng, thì chúng ta phải xem xét thời gian thực hiện truy vấn.
Contents
Hộp công cụ
Đoạn mã mà tôi sẽ cho bạn thấy dưới đây đã được thử nghiệm với màn hình truy vấn, một plugin miễn phí cung cấp thông tin cần thiết về hiệu suất truy vấn, các trình khởi chạy (triggered hooks), yêu cầu HTTP, viết lại các quy tắc và nhiều hơn nữa.
Thay thế cho một plugin, chúng ta có thể buộc WordPress để lưu trữ thông tin truy vấn bằng cách thêm hằng số sau trong wp-config.php:
Khi SAVEQUERIES được thiết lập là true, WordPress đăng ký các truy vấn và một loạt thông tin hữu ích trong mảng $wpdb->queries. Do đó, tên của các hàm được gọi và sự mất hiệu lực của mỗi truy vấn có thể được in bằng cách thêm đoạn code sau trong một tệp mẫu như footer.php
Đây là một ví dụ về những gì được lặp lại:
WP_Query – Tại sao chúng ta không đếm hàng
Chúng ta có thể truy vấn cơ sở dữ liệu với hàm get_posts, nó trả về một mảng các bài viết, hoặc một new instance của đối tượng WP_Query. Trong cả hai trường hợp chúng ta có thể xác định kết quả của các truy vấn bằng cách thiết lập các giá trị thích hợp cho các biến cụ thể.
Chúng ta hãy bắt đầu với một ví dụ cho thấy một vòng lặp thông thường như nó thường xuất hiện trong một file template
$args là một mảng cặp key/value. Các cặp này được đặt tên là các truy vấn vars, và xác định hoặc ảnh hưởng đến query SQL thực tế.
Khi truy vấn cơ sở dữ liệu từ một plugin, chúng tôi có thể sử dụng bộ lọc pre_get_posts, như trong ví dụ sau:
Một điều quan trọng cần chú ý ở đây là đối tượng $query được truyền bằng tham chiếu chứ không phải theo giá trị, có nghĩa là các đối số truy vấn chỉ ảnh hưởng tới một $query instance hiện có.
Thiết lập phương thức thêm một truy vấn mới var đến truy vấn đặc tả và sẽ dùng WordPress để lấy tất cả các bài viết từ thể loại webdev. Đây là truy vấn kết quả:
Trong ví dụ này, giá trị LIMIT đã được thiết lập bởi người dùng quản trị trong các tùy chọn đọc (mục Reading), được thể hiện trong hình dưới đây.
Trong các truy vấn tùy chỉnh, chúng ta có thể thiết lập số hàng cần được lấy ra từ cơ sở dữ liệu nhờ tham số pagination posts_per_page.
Tùy chọn SQL_CALC_FOUND_ROWS buộc truy vấn đếm số hàng đã tìm thấy. Số này sẽ được trả về bởi hàm FOUND_ROWS() SQL, được thể hiện trong ví dụ sau:
Thật không may khi hàm SQL_CALC_FOUND_ROWS có thể làm chậm đáng kể đến thời gian thực hiện truy vấn. Tuy nhiên chúng ta có thể buộc WordPress loại bỏ tùy chọn cung cấp biến non_found_rows dưới dạng đã được sử dụng.
Nếu SQL_CALC_FOUND_ROWS bị bỏ qua, hàm FOUND_ROWS() trả về số hàng lên đến giá trị giới hạn (LIMIT). Trong cài đặt WordPress với vài trăm bài đăng, ví dụ meta query dưới đây đã mất 0.0107 giây.
Loại bỏ SQL_CALC_FOUND_ROWS thiết lập no_found_rows thành false, cùng một truy vấn đó nhưng mất có 0.0006 giây.
Khi bảng wp_post chứa hàng ngàn hàng, việc thực hiện truy vấn có thể mất vài giây. Nhưng khi chúng ta không cần pagination, chúng ta nên đặt no_found_rows thành true, làm cho truy vấn chạy nhanh hơn đáng kể.
Để bộ nhớ Cache hoặc không để bộ nhớ Cache
WordPress cung cấp một hệ thống tích hợp sẵn trong bộ nhớ đệm. Mặc dù bộ nhớ đệm sẽ cải thiện tốc độ tải trang, nhưng nó có thể gây ra một số truy vấn thêm để chạy chống lại cơ sở dữ liệu. Thêm vào đó, bất cứ lúc nào một truy vấn được thực hiện một bó dữ liệu không cần thiết có thể được yêu cầu.
May mắn thay, WordPress cho phép chúng tôi vô hiệu hóa bộ nhớ đệm với việc cung cấp ba thông số cụ thể:
– cache_results: Có nên lưu trữ thông tin đăng không. Mặc định là true
– update_post_meta_cache: Có nên cập nhật bộ nhớ post meta cache. Mặc định true
– update_post_term_cache: Có nên cập nhật bộ nhớ post term cache. Mặc định true
Nếu một hệ thống lưu trữ tạm thời được kích hoạt, chẳng hạn như Memcached, chúng tôi không cần phải quan tâm đến các thông số bộ nhớ cache bởi vì WordPress sẽ thiết lập để false các đối số theo mặc định.
Trong bất kỳ tình huống nào khác, chúng ta có thể xây dựng một truy vấn nhanh hơn với mã sau:
Khi một hệ thống lưu trữ tạm thời không có sẵn, các truy vấn trả lại một lượng nhỏ dữ liệu không nên được lưu trữ.
Xem thêm:
Trường trả về
Như một quy tắc chung, chúng ta không bao giờ nên truy vấn cơ sở dữ liệu cho các lĩnh vực không cần thiết. Lớp WP_Query cung cấp các trường đối số, cho phép hạn chế các trường trả về cho các id hoặc các trường ‘id => parent‘.
Các biến trường (fileds variable) nhận ‘id’ và ‘id => parent’, và mặc định là * (bất kỳ giá trị nào khác), mặc dù bạn sẽ nhận thấy rằng theo mặc định, WordPress sẽ đặt giá trị cho id trong một số truy vấn.
Cuối cùng, chúng ta có thể tối ưu hóa truy vấn đầu tiên của mình:
Khi không yêu cầu các trường cụ thể, giới hạn các trường trả về là ID
Kết luận
Xem xét tốc độ truy vấn có thể không mang lại lợi ích to lớn cho các trang web nhỏ với một vài trăm bài viết. Nếu bạn muốn sẵn sàng cho sự tăng trưởng hoặc bạn đang chạy một trang web lớn với các truy vấn đắt tiền thì bạn nên tối ưu hóa các truy vấn WordPress của bạn. Các truy vấn không hiệu quả có thể làm chậm đáng kể việc tải trang nhưng với một vài điều chỉnh đơn giản bạn có thể tăng tốc độ trang web của mình một cách đáng kể.
