matteoriva
  • 0
Новичок

Почему домашняя страница (намного) медленнее, чем другие страницы?

  • 0

Я пытаюсь настроить веб-сайт WordPress, который загружается медленно, и я обнаружил, что домашняя страница загружается намного дольше. Это не из-за контента, потому что я просто учитываю время, необходимое для завершения базового запроса (доступно для просмотра через firebug в firefox).

Также я попытался скопировать код index.php на пользовательскую страницу, и тот же точный код загружается примерно за 1 секунду, в то время как основной дом загружается примерно за 7. Я заметил, что отдельные страницы загружаются быстрее, и сначала я подумал, что это связано с разница в содержании, но после этого теста я не уверен, в чем причина.

Есть ли много вещей, которые WordPress делает за кулисами только для основного индекса? Есть ли другой способ объяснить эту ситуацию и, что более важно, исправить ее, чтобы домашняя страница загружалась быстрее?

ОБНОВЛЕНИЕ — ГРЯЗНОЕ РЕШЕНИЕ

После множества слепых попыток я создал новую страницу под названием home, которая используется index.php в качестве пользовательского шаблона (не копия, тот же файл). Я перенаправил любой вызов на базовый путь к нему (посредством внутренней перезаписи wordpress), и у меня та же домашняя страница, что и раньше, только что загруженная в 1/6 раза. Хотя я доволен результатом, я действительно хотел бы понять, что происходит.

ДРУГОЕ ОБНОВЛЕНИЕ

Таким образом, дело в том, что я не могу использовать динамическую (в смысле WordPress) страницу с этим сайтом, она отлично работает только с пользовательской «статической» страницей, на которую я вставляю контент с помощью различных функций. медленный (с высоким лимитом памяти) или просто пустой (низкий лимит памяти, скрипт не работает).

Как было предложено в этом вопросе, я создал статический дом, связанный с пользовательской страницей, и он отлично работает. Я также создал страницу блога (опять же с пользовательским шаблоном), которая также работает нормально (где «хорошо» означает, что она показывает мою пустую тестовую страницу, содержащую только одно слово и без кода), если я не укажу ее как «Страница сообщений» в admin -> Чтение настроек. Другими словами, похоже, что как только wordpress видит динамическую страницу (ту, которая должна содержать основной цикл), он делает что-то очень тяжелое, что съедает много оперативной памяти.

Все еще ищу причину этого, я могу обойти это, но мне бы очень хотелось понять, в чем проблема.

Изменить: добавлена ​​награда

Дополнительная информация: Я пробовал отключать все плагины, WordPress обновлен до последней версии.

ДАЛЬНЕЙШЕЕ РЕДАКТИРОВАНИЕ: ТАБЛИЧНЫЕ ИНДЕКСЫ

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`)
Share
  1. @kemp — Если я не пропустил это, вы не включили ссылку на домашнюю страницу, чтобы мы могли увидеть это сами. Вы можете это сделать?

    • 0
    • Кроме того, добавьте эти инструменты профилирования на свой сайт: wordpress.stackexchange.com/questions/1567/…, чтобы разрешить просмотр: http://example.com?debug=sql

      • 0
    • @Денис пробовал, но ничего не выходит. Я получаю пустую страницу и случайную внутреннюю ошибку сервера с этим сообщением в журнале: Premature end of script headers: index.php

      • 0
    • @kemp вы удалили содержимое кеша и повторили тесты с двумя идентичными страницами (динамическими/статическими)?

      • 0
    • Да, я только что заметил, что ваши URL-адреса используют подробную структуру постоянных ссылок. Что происходит, когда вы используете одну из предложенных структур на основе даты/имени, например, /ГГГГ/ММ/slug/?

      • 0
    • @ Денис, не могли бы вы просмотреть индексы? Я обновил вопрос, так как они не помещались в комментарий. Кроме того, можно ли считать 13 200 сообщений слишком большим количеством? Что также странно, с моей точки зрения, так это то, что обычный цикл на страницах категорий работает отлично.

      • 0
    • 13200 строк — это очень мало в базе данных, если только они плохо не запрашиваются. Мой сайт разработки с парой странных сообщений читает всю страницу диска и быстро сортирует результат в кратчайшие сроки. Мой живой сайт, напротив, имеет чуть более 1000 сообщений, и php занимает порядка 50 мс, чтобы получить сообщения с главной страницы. Чтобы представить это в перспективе, мой сайт разработки PgSQL извлекает первые 10 строк из нескольких сотен тысяч за 20 мс…

      • 0
    • Относительно ваших текущих индексов: type_status_date настолько широк, что MySQL обычно предпочитает использовать post_status или post_date. post_status_date_gmt/post_date_gmt используются внутри для очень специфических запросов. Обычно первый в моем опыте. post_parent/post_name используются при запросе иерархических типов; первому было бы полезно добавить post_type для быстрого извлечения корневых страниц. post_author полезен для авторских страниц и в админке. Для авторских страниц внешнего интерфейса это было бы более идеальным: (post_author, post_type, post_status, post_date DESC).

      • 0
    • Продолжаем… term_tax (object_id,term_taxonomy_id) хорош для получения тегов/котов/и т. д. из сообщений. Последнее, что я проверял, ни один из других индексов терминов не используется. Мой вышеупомянутый extra_term_tax позволяет фактически получать термины, используя индекс, а extra_term_rel позволяет получать сообщения, соответствующие термину.

      • 0
    • @Denis — отличный ответ здесь… Я просто хотел спросить вас, является ли предложенное вами решение его проблемы тем, что вы реализуете на своих сайтах WordPress по умолчанию?

      • 0
    • Рарст прав. Вероятно, у вас есть плагин или виджет, который работает только на главной странице и выполняет длинные запросы о чем-то (например, проверяет категорию или что-то в этом роде?)

      • 0
    • @Jeremy: но это не объясняет, почему точная копия дома загружается быстрее под другим именем страницы.

      • 0
    • @Rarst: спасибо за предложение, но я не могу заставить его работать правильно. Я вижу отчет на странице администратора, но ничего на обычных. Может зависеть от того, что wordpress подключен к vbulletin, и плагин не распознает меня как администратора, вошедшего в систему.

      • 0
    • Это может быть точный код кода страницы, но это не точная копия окружения. Условные теги — это очень простая техника кода WordPress — домашняя страница и обычная страница могут быть идентичными по коду, но условные теги будут возвращать разные значения, поэтому на хуки может срабатывать разный код. | Не работает — вы имеете в виду плагин или фрагмент?

      • 0
    • Кемп: Попробуйте отключить все ваши плагины и посмотрите, сохраняется ли разница. Если его нет, включите их один за другим. Другой способ проверить это — установить совершенно новый сайт без плагинов и запустить на нем свою тему, чтобы посмотреть, занимает ли домашняя страница больше времени.

      • 0
    • Это должно быть что-то, что WordPress делает перед загрузкой шаблона, потому что это не связано с кодом страницы.

      • 0
    • Код может находиться не на самой странице, а в таких функциях, как wp_head() обработчики действий вызова, которые подключаемые модули могут использовать для вызова дополнительных функций. Вот почему @prettyboymp предложил выполнить поиск по всему wp-content каталогу, а @Jeremy Clarke рекомендовал отключить все вышеперечисленные плагины.

      • 0
    • Да, но та же самая страница отлично работает, когда она называется «статической», она зависает только при вызове «динамической».

      • 0
  2. Я позволю себе не согласиться с двумя предыдущими комментариями.

    Использование статической домашней страницы приводит к тому, что WP использует сканирование индекса по первичному ключу таблицы сообщений, а не сканирование индекса (ох, какое редкое) по post_date, status или post_parent в таблице сообщений.

    По сути, домашняя страница работает очень медленно из-за плохого дизайна базы данных в WP. Схема имеет смехотворные многоколоночные индексы в таблицах таксономии, которые MySQL просто игнорирует, когда у вас есть значимое количество сообщений. Тот факт, что мы слишком часто используем таблицу для таксономий, также не помогает.

    В базу безопасно добавить индексы на:

    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)
    

    Это не будет идеально, но, по крайней мере, WP сможет использовать планы вложенных циклов на основе индекса на вашей главной странице…

    Да, и… если вы используете какой-либо пользовательский тип записи на своей главной странице, вам также необходимо добавить:

    posts(post_status,post_date DESC)
    

    В противном случае индекс вообще не будет использоваться для основного запроса из-за предложений OR.

    • 0
  3. По умолчанию нет никакой разницы в производительности домашней страницы. Однако существует вероятность того, что какой-то плагин делает что-то медленное только на этой странице.

    Существует множество плагинов для профилирования производительности WP. Я обычно использую WP Tuner, но он, кажется, сломан для последней версии WP, поэтому у меня нет немедленной замены, чтобы предложить.

    Самый простой способ — заполнить шаблон маркерами времени/памяти.

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

    Это грубо, но часто позволяет точно определить место, где происходит замедление.

    • 0
  4. Спустя почти 4 года я вернулся к этому и, наконец, нашел проблему. Оказывается, на сайте было много статей, ВСЕ помеченных как прилепленные. Из-за невероятно глупого способа, который WordPress использует для пометки прикрепленных сообщений (сериализованный массив в wp_options), основной цикл динамической домашней страницы занял невероятно много времени. Очистка sticky_posts поля в таблице устранила проблему.

    • 0
  5. Если домашняя страница загружается так долго, скорее всего, у вас есть плагин или функция в теме, которая отправляет удаленный запрос во время рендеринга домашней страницы.

    Я бы сделал рекурсивный поиск в вашем каталоге wp-content вызовов «wp_remote_», чтобы найти любые функции, которые могут быть причиной этого.

    • 0
  6. Сначала проверьте запросы WOrdPress и включенные изображения, скрипты и таблицы стилей. Вы можете проверить запросы с помощью плагина Debug Queries и получить больше информации о своей установке и ошибках с помощью плагина Debug Objects.

    • 0

Оставить ответ

You must login to add an answer.