Tại sao nhà (rất nhiều) chậm hơn các trang khác?

Tôi đang cố điều chỉnh một trang web wordpress chịu thời gian tải chậm và tôi phát hiện ra rằng trang chủ dường như mất nhiều thời gian hơn để tải. Đó không phải là do nội dung vì tôi chỉ đang xem xét thời gian yêu cầu cơ sở kết thúc (có thể xem qua fireorms trong firefox).

Ngoài ra, tôi đã thử sao chép mã index.php trong một trang tùy chỉnh và cùng một mã chính xác tải trong khoảng 1 giây trong khi nhà chính tải trong khoảng 7. Tôi nhận thấy rằng các trang đơn lẻ được tải nhanh hơn và lúc đầu tôi nghĩ rằng đó là do sự khác biệt về nội dung, nhưng sau bài kiểm tra này tôi không chắc điều gì gây ra điều này.

Có nhiều thứ mà wordpress làm đằng sau hậu trường chỉ cho chỉ mục chính? Có cách nào khác để giải thích tình huống này và quan trọng hơn là khắc phục nó để trang chủ tải nhanh hơn?

CẬP NHẬT - GIẢI PHÁP TRỰC TIẾP

Sau rất nhiều lần thử, tôi đã tạo một trang mới gọi là home sử dụng index.phplàm mẫu tùy chỉnh (không phải bản sao, cùng một tệp). Tôi đã chuyển hướng bất kỳ cuộc gọi nào đến đường dẫn cơ sở đến nó (thông qua viết lại nội bộ của wordpress) và tôi có cùng trang chủ như trước đây, chỉ được tải vào 1/6 thời gian. Trong khi tôi hài lòng với kết quả này, tôi thực sự muốn hiểu chuyện gì đang xảy ra.

CẬP NHẬT KHÁC

Vì vậy, vấn đề dường như là tôi không thể sử dụng trang động (theo nghĩa của wordpress) với trang này, nó chỉ hoạt động tốt với trang "tĩnh" tùy chỉnh nơi tôi chèn nội dung qua nhiều chức năng khác nhau, Loop bình thường làm cho ngôi nhà rất hay chậm (với giới hạn bộ nhớ cao) hoặc chỉ để trống (giới hạn bộ nhớ thấp, tập lệnh không thành công).

Như được đề xuất trong câu hỏi này , tôi đã tạo một ngôi nhà tĩnh được liên kết với một trang tùy chỉnh và nó hoạt động tốt. Tôi cũng đã tạo một trang blog (một lần nữa với một mẫu tùy chỉnh) cũng hoạt động tốt (trong đó "fine" có nghĩa là nó hiển thị trang thử nghiệm trống của tôi chỉ chứa một từ và không có mã) trừ khi tôi chỉ định nó là "Trang bài viết" trong quản trị viên -> Đọc cài đặt. Nói cách khác, có vẻ như ngay khi wordpress nhìn thấy một trang động (trang được cho là giữ Vòng lặp chính), nó sẽ làm một cái gì đó rất nặng, ăn rất nhiều ram.

Vẫn đang tìm kiếm nguyên nhân của việc này, tôi có thể giải quyết nó nhưng tôi thực sự muốn hiểu vấn đề là gì.

Chỉnh sửa: thêm tiền thưởng

Thông tin thêm: Tôi đã thử vô hiệu hóa tất cả các plugin, wordpress được cập nhật lên phiên bản mới nhất.

EDIT THÊM: CHỈ SỐ BẢNG

wp_posts:

PRIMARY KEY  (`ID`),
KEY `type_status_date` (`post_type`,`post_status`(1),`post_date`,`ID`),
KEY `post_status_date_gmt` (`post_status`(1),`post_date_gmt`),
KEY `post_date` (`post_date`),
KEY `post_date_gmt` (`post_date_gmt`),
KEY `post_parent` (`post_parent`),
KEY `post_name` (`post_name`),
KEY `post_status` (`post_status`),
KEY `post_author` (`post_author`),
FULLTEXT KEY `post_related` (`post_name`,`post_content`),
FULLTEXT KEY `post_content` (`post_content`,`post_title`),

wp_term_relationships:

PRIMARY KEY  (`object_id`,`term_taxonomy_id`),
KEY `term_taxonomy_id` (`term_taxonomy_id`)

wp_term_taxonomy:

PRIMARY KEY  (`term_taxonomy_id`),
UNIQUE KEY `term_id_taxonomy` (`term_id`,`taxonomy`),
KEY `taxonomy` (`taxonomy`)

Tôi xin để khác với hai ý kiến ​​trước.

Sử dụng một trang chủ tĩnh dẫn đến WP sử dụng quét chỉ mục trên khóa chính của bảng bài đăng, so với quét chỉ mục (ồ rất thường xuyên) trên post_date, status hoặc post_parent trong bảng bài viết.

Về bản chất, trang chủ bị chết chậm do thiết kế cơ sở dữ liệu kém trong WP. Lược đồ có các chỉ mục nhiều màu lố bịch trên các bảng phân loại mà MySQL chỉ đơn giản bỏ qua một khi bạn có một lượng bài viết có ý nghĩa. Thực tế là chúng ta đang sử dụng một bảng quá nhiều cho các nguyên tắc phân loại cũng không giúp được gì.

Trong cơ sở dữ liệu, thêm an toàn các chỉ mục trên:

CREATE INDEX extra_posts ON posts (post_type,post_status,post_date DESC)
CREATE INDEX extra_term_rel ON term_relationships(term_taxonomy_id,object_id)
CREATE INDEX extra_term_tax ON term_taxonomy(taxonomy,term_taxonomy_id,term_id)

Nó sẽ không hoàn hảo, nhưng ít nhất WP sẽ có thể sử dụng các kế hoạch vòng lặp lồng nhau dựa trên chỉ mục trên trang trước của bạn ...

Ồ, và ... nếu bạn đang sử dụng bất kỳ loại bài đăng tùy chỉnh nào trên trang trước của mình, bạn cũng cần thêm:

posts(post_status,post_date DESC)

Khác không có chỉ mục nào sẽ được sử dụng cho tất cả các truy vấn chính vì các mệnh đề OR.

Theo mặc định, không có sự khác biệt nào đối với hiệu suất của trang chủ. Tuy nhiên, có khả năng một số plugin làm điều gì đó chậm trên trang đó.

Có rất nhiều plugin để cấu hình hiệu năng WP. Tôi thường sử dụng WP Tuner nhưng dường như nó đã bị hỏng cho phiên bản WP mới nhất, vì vậy tôi không có sự thay thế ngay lập tức để đề xuất.

Cách đơn giản nhất là đóng gói mẫu đầy đủ các dấu thời gian / bộ nhớ.

printf(  '%d queries in %.3f seconds, using %.2fMB memory', get_num_queries(), timer_stop( 0, 3 ), memory_get_peak_usage() / 1024 / 1024 );

Đó là thô nhưng thường cho phép xác định vị trí nơi xảy ra chậm.

Sau gần 4 năm tôi đã nhận lại được điều này và cuối cùng đã tìm ra vấn đề. Hóa ra trang web có rất nhiều bài viết TẤT CẢ được đánh dấu là dính. Do cách sử dụng wordpress ngớ ngẩn đến khó tin để đánh dấu các bài đăng dính (một mảng được tuần tự hóa trong wp_options), vòng lặp chính của trang chủ động mất một thời gian dài vô cùng. Xóa sticky_poststrường trong bảng đã khắc phục sự cố.

Nếu trang chủ mất nhiều thời gian để tải, rất có thể bạn có một plugin hoặc một chức năng trong chủ đề đang thực hiện một yêu cầu từ xa một thời gian khi trang chủ được hiển thị.

Tôi sẽ thực hiện tìm kiếm đệ quy thông qua thư mục wp-content của bạn để gọi các 'wp_remote_' để tìm bất kỳ chức năng nào có thể gây ra điều này.

Đầu tiên, hãy kiểm tra quereis của WOrdPress và các hình ảnh, tập lệnh và biểu định kiểu được bao gồm. Bạn có thể kiểm tra các truy vấn với các Truy vấn gỡ lỗi của plugin và bạn sẽ có thêm thông tin về cài đặt của mình và các lỗi với các Đối tượng gỡ lỗi của plugin .