Недавно я писал о том, как мой сайт подвергся атаке и как мне пришлось перейти на Cloudflare, чтобы прекратить трафик ботов. Трафик ботов также снизил производительность моего сайта, затрагивая бесконечное количество несуществующих URL-путей, увеличивая количество запросов перенаправления с подстановочными знаками, которые никогда не будут работать.

Как WordPress влияет на производительность

При устранении проблем с использованием памяти и ЦП и устранении неполадок я все еще был поражен возможностями статического перенаправления. Затем я начал анализировать процесс, необходимый моему серверу для обработки несуществующего URL-адреса:

1. Входящий HTTP-запрос: Веб-сервер получает запрос URL-адреса и выполняет самые основные проверки, включая согласование SSL, соответствие виртуального хоста и наличие статического файла. Если запрошенный файл физически существует на диске, например изображение, файл CSS или статический HTML-файл, он обслуживается немедленно без вызова WordPress.
2. Правила перезаписи на уровне веб-сервера: Если статический файл отсутствует, сервер оценивает правила перезаписи и перенаправления, определенные на уровне сервера, такие как директивы перезаписи Nginx или правила Apache mod_rewrite в файле .htaccess. Обрабатываемые здесь перенаправления выполняются до загрузки PHP или WordPress, что делает их наименее ресурсоемким вариантом.
3. Загрузка PHP и загрузка WordPress: Если никакие правила уровня сервера не разрешают запрос, сервер перенаправляет запрос на index.phpзапуск выполнения PHP и процесса загрузки WordPress. На этом этапе загружаются основные файлы WordPress, инициализируются плагины, а использование памяти и процессора значительно увеличивается.
4. Разобранный запрос и решение запроса: WordPress анализирует запрошенный URL-адрес, чтобы определить, связан ли он с существующей записью, страницей, пользовательским типом записи, таксономией или другой зарегистрированной конечной точкой перезаписи. Этот процесс включает в себя несколько запросов к базе данных к таблицам новостей, терминов и опций.
5. Перенаправление поиска с помощью плагинов или основных хуков: Если запрошенный URL-адрес не разрешается в допустимый контент, WordPress проверяет зарегистрированную логику перенаправления. Это могут быть базовые канонические перенаправления, собственный код перенаправления или плагины перенаправления, которые запрашивают таблицы базы данных или кэшированные правила, чтобы найти соответствующий исходный URL-адрес.
6. Оценка кэша перенаправления: Хорошо реализованные системы перенаправления сначала проверяют кеш в памяти или кеш объектов, а затем возвращаются к поиску в базе данных только при необходимости. Плохо оптимизированные плагины перенаправления могут выполнять несколько запросов к базе данных за одну версию, увеличивая нагрузку на сервер на сайтах с высоким трафиком.
7. Выдан ответ на пересылку: Если найдено соответствующее перенаправление, WordPress отправляет соответствующий код состояния HTTP, например 301 или 302, и прекращает дальнейшую обработку. На этом запрос заканчивается, но только после того, как ресурсы WordPress и PHP уже будут использованы.
8. Обнаружение 404: Если ни одно из правил перенаправления не соответствует, WordPress помечает запрос как 404 и готовит ответ об ошибке. Для этого по-прежнему требуется полная реализация WordPress, включая загрузку тем и разрешение шаблонов.
9. Отрисовка шаблона 404: Загружается шаблон 404.php активной темы вместе со всеми связанными ресурсами, перехватчиками, виджетами или сценариями отслеживания. Даже если страница отображается не найдено контента, это часто один из самых ресурсоемких результатов из-за полной отрисовки страницы.
10. Доставка ответа: Окончательный ответ HTML отправляется обратно в браузер, завершая жизненный цикл запроса. С точки зрения сервера этот путь представляет собой сценарий максимальной стоимости для одного неразрешенного URL-адреса.

Любой мигрировавший сайт имеет реструктуризированные постоянные ссылки или является просто старым сайтом… перенаправление имеет решающее значение для удобства пользователей и поддержания авторитетности обратных ссылок на страницы, соответствующие SEO. Когда в WordPress выполняются перенаправления, серверу приходится выполнять гораздо больше работы, чем думает большинство владельцев веб-сайтов. Каждый неразрешенный URL-адрес требует запуска PHP для загрузки ядра WordPress, инициализации плагинов и выполнения нескольких запросов к базе данных, прежде чем принять решение о перенаправлении.

На загруженном сайте это означает использование ресурсов процессора, памяти и подключений к базе данных, чтобы заставить браузер перейти куда-то еще. Умножьте эту стоимость на тысячи устаревших URL-адресов, некорректных ссылок, трафика ботов и внешних обратных ссылок, и перенаправление незаметно станет измеримым компромиссом между производительностью и стабильностью.

Чтобы представить это в перспективе, Martech Zone приближается к 20 годам с множеством доменов, миграциями и изменениями структуры постоянных ссылок, а также тысячами партнерских ссылок, для которых я использую рефералов. я упакован более 6100 рефералов! Как результат, большинство ресурсы моего сервера были потрачены впустую на перенаправления вместо представления фактического контента.

Зачем переносить редиректы из WordPress на ваш сервер

Перенос перенаправления на уровень сервера позволяет устранить почти все эти накладные расходы. Когда Nginx или Apache обрабатывают перенаправление, решение принимается до вызова PHP и до загрузки WordPress. Никаких запросов к базе данных, никакого выполнения плагинов и никакого рендеринга тем. Сервер оценивает простое правило, возвращает ответ 301 или 302 и закрывает запрос.

Это сокращает время получения первого байта (TTFB), снижает нагрузку на PHP и базу данных, а также экономит ресурсы WordPress для запросов, которые действительно требуют динамического контента. Практически говоря, перенаправление на уровне сервера лучше масштабируется, быстрее реагирует и уменьшает радиус всплесков трафика, сканеров, ботов и неработающих ссылок. Для любого сайта, для которого важны производительность, надежность или экономичность, перенаправление происходит как можно ближе к веб-серверу, а не скрывается на уровне приложения.

Благодаря интеграции FlyWP с Cloudflare Cloudflare действует как шлюз для всего трафика, а не только для статических ресурсов, как в типичной конфигурации CDN. В результате Cloudflare стал идеальным решением для миграции моих рефералов. Теперь плагин перенаправления не использует ресурсы для запроса и кэширования перенаправлений в WordPress… Cloudflare справляется со всем этим.

Как перенести рефералов в Cloudflare

Поскольку я перенес свой CDN в Cloudflare, чтобы предотвратить атаку ботов, я исследовал и обнаружил, что у них есть мощный механизм перенаправления, который позволяет выполнять массовую загрузку с перенаправлением. Процесс переноса обратных ссылок был непростым, поэтому я хочу задокументировать его здесь на случай, если вы тоже захотите это сделать:

1. Моя статика (не подстановочный знак или регулярное выражение) перенаправляет из Rank Math в файл CSV.
2. CSV-файл был импортирован в «Правила» > «Правила перенаправления» > «Перейти к массовому перенаправлению».

Source