Перейти к содержимому 
HTTP-запросы WordPress определяют скорость отображения ваших страниц, поскольку каждый запрос к CSS, JS, изображениям или шрифтам требует времени. Я покажу вам, как уменьшить количество запросов, избежать блокировки рендеринга и оптимизировать веб-сайт сразу заметно ускорить.
Центральные пункты
Следующие основные моменты быстро приведут вас к снижению количества запросов и улучшению LCP со стабильным Функция:
- Кэширование использование: Кэш браузера, страниц и объектов значительно сокращает количество повторных запросов.
- CSS/JS оптимизировать: Минимизируйте, объединяйте, интегрируйте критические CSS, избегайте блокировки рендеринга.
- фотографии модернизировать: WebP/AVIF, ленивая загрузка, фиксированные размеры, отсутствие слайдеров-героев.
- Скрипты delay: отсрочка/задержка для аналитики, пикселей, внешних ресурсов.
- CDN/Хостинг выбрать: HTTP/3, пограничное кэширование, короткий TTFB для глобальных пользователей.
Что такое HTTP-запросы в WordPress?
Каждый ресурс на странице генерирует свой собственный запрос, то есть CSS-файлы, JavaScript, изображения, иконки и Шрифты. Современные темы и плагины быстро добавляют множество мелких файлов, что увеличивает количество Запросы диски. Каждый запрос включает в себя поиск DNS, рукопожатие TCP и передачу данных, и именно эти накладные расходы увеличиваются. Без оптимизации я часто вижу 70+ запросов на страницу, что заметно задерживает отображение. Целевые значения явно ниже этого: менее 50 - хорошо, менее 25 - отлично для максимальной скорости. Небольшое уменьшение количества запросов на каждый тип страницы оказывает большое влияние, поскольку шаблоны, заголовки и нижние колонтитулы загружаются везде.
Почему каждый запрос имеет значение
Любой дополнительный файл может заблокировать рендеринг, особенно синхронно загруженный CSS и JavaScript. Если эти ресурсы остаются блокирующими рендеринг в головной части страницы, пользователи ждут белых пространств и отскакивают. Это влияет на основные веб-показатели: LCP отстает, TBT растет, а CLS увеличивается без фиксированных мер для изображений или рекламы. Поэтому я постоянно проверяю, какие ресурсы действительно важны, а какие можно отложить. Если вы не уверены, почему запросы замедляются, несмотря на малый размер файлов, прочтите мое руководство Зачем блокировать HTTP-запросы для практических объяснений.
Быстрый старт: меры с наибольшим эффектом
Я начинаю с кэширования, минификации и ленивой загрузки, потому что эти шаги дают отличный эффект и могут быть быстро реализованы. sind. Хороший плагин кэширования создает статические HTML-страницы и сохраняет База данных. Минификация удаляет пробелы и комментарии, объединяет файлы и значительно сокращает загрузку. Ленивая загрузка перемещает неэкранные изображения на задний план, что помогает First Paint и LCP. Всего несколькими щелчками мыши можно добиться прямых улучшений без изменения темы.
| Мера оптимизации | Заявки на сокращение | Инструменты/плагины |
|---|---|---|
| Кэширование (браузер, страница, объект) | 50-80% для обратных визитов | WP Rocket, LiteSpeed Cache, W3TC |
| Минифицировать и комбинировать | 20-50% меньшее количество переводов | Autoptimise, Perfmatters |
| Фотографии с ленивой загрузкой | 30-60% начальный | WP Rocket, основная функция |
| CDN с HTTP/2/3 | до 40% более эффективным | Cloudflare, QUIC.cloud |
Умное использование кэширования
Сначала я активирую кэширование браузера, чтобы возвращающиеся пользователи могли сохранять активы локально из Кэш и больше не из Сервер нагрузка. Кэширование страниц генерирует статичный HTML для посетителей и экономит выполнение PHP и запросов к базе данных. При использовании объектного кэширования (например, Redis) частые запросы остаются в памяти, что снижает нагрузку на страницы администратора и магазина. Gzip/Brotli дополнительно уменьшают передачу, что сокращает время передачи и объем данных. Затем я проверяю время истечения срока действия (контроль кэша, expires) и то, не исключают ли строки запросов маркетинговые скрипты из кэширования без необходимости.
CSS и JavaScript: Минифицируйте, комбинируйте, загружайте
Множество маленьких файлов означает множество Запросы, Поэтому я обобщаю стили и сценарии как можно реже. Пучки вместе. Минификация уменьшает размер, но самое главное - меньше файлов для критического пути. Я включаю критические CSS в строку, чтобы содержимое над разворотом было стилизовано немедленно. Некритичные стили загружаются асинхронно или через атрибут media. Я устанавливаю JavaScript на отсрочку или задержку, но проверяю последовательность, чтобы не нарушить зависимости.
Изображения и медиа: большая экономия
Изображения часто являются причиной наибольшей доли Запросы, поэтому я конвертирую в WebP или AVIF и определяю фиксированный Размеры. Ленивая загрузка задерживает внеэкранные изображения, но я предварительно загружаю изображение героя специально для быстрого LCP. Отзывчивый srcset обеспечивает загрузку небольших вариантов на мобильных устройствах. Я избегаю слайдеров в героях, потому что они вызывают много файлов и перерисовки. Я также использую специфику современных форматов, чтобы свести артефакты к минимуму.
Шрифты, сторонние поставщики и внешние скрипты
Я загружаю внешние шрифты локально, чтобы иметь полный контроль над Кэширование и Предварительная нагрузка есть. Стили шрифтов я комбинирую редко, чаще всего достаточно обычного и жирного с переменным начертанием. Для аналитики, менеджеров тегов и пикселей я устанавливаю задержки до первого взаимодействия или загружаю их только после события onload. Это позволяет освободить критический путь от ненужных файлов. Я также проверяю виджеты социальных сетей и заменяю их статичными превью, которые перезагружаются при клике.
Выбор CDN и хостинга с умом
CDN приближает активы к пользователям, уменьшает задержки и количество круговые поездки заметно в первый призыв. HTTP/2/3 обеспечивает мультиплексирование, приоритезацию и более быстрые рукопожатия TLS. Пограничное кэширование HTML делает быстрее, в частности, международные целевые группы. На сервере я обращаю внимание на NVMe-хранилище, актуальные версии PHP и короткий TTFB. Хорошие хостеры предлагают такие инструменты, как Brotli, Early Hints и QUIC, которыми я активно пользуюсь.
Особые случаи: REST-API и Admin-Ajax
Многие установки генерируют фоновые запросы через REST API или admin-ajax.php, например, для форм, поиска или динамических Виджеты. Я определяю эти вызовы на вкладке "Сеть" и проверяю, можно ли сократить интервалы опроса или суммировать запросы. По возможности я кэширую ответы API на стороне сервера и устанавливаю ограничения скорости. Для более глубокой оптимизации обратитесь к моему руководству по Производительность REST-API, где показаны типичные тормоза и решения. Вот как я уменьшаю повторяющиеся фоновые запросы без потери функций.
Измерение и контроль устойчивой скорости
Я тестирую каждое изменение с помощью PageSpeed Insights, Lighthouse и GTmetrix, чтобы получить реальную картину. Эффект видеть и нет регрессии захват. Цели: менее 50 запросов на страницу, LCP менее 2,5 с, TBT менее 200 мс и CLS менее 0,1. Я также смотрю на график водопада, чтобы визуализировать блокировку ресурсов, поиск DNS и очереди. Помните: количество запросов часто имеет большее значение, чем чистый размер файла; я объясняю это в статье о Сосредоточьтесь на запросах. Постоянный мониторинг позволяет поддерживать оптимизацию на стабильном и измеримом уровне.
Дополнительно: HTTP/2/3, неиспользуемые CSS и обслуживание БД
Благодаря HTTP/2/3 я получаю преимущества мультиплексирования, приоритезации и ускорения. Рукопожатия, что означает время ожидания при параллельной загрузке Файлы сокращенный. Я удаляю неиспользуемые CSS, чтобы уменьшить размер таблиц стилей и сократить количество запросов. Для повторяющихся макетов стоит использовать критический CSS для каждого шаблона, а не для каждой страницы. В базе данных я удаляю ревизии, истекшие переходные периоды и трупы cron, чтобы бэк-энд и динамические функции оставались быстрыми. Такие шаги заметно ускоряют процесс, особенно для больших проектов с большим количеством плагинов.
Гигиена плагинов и тем
Я регулярно проверяю, какие плагины дублируют функции или редко используются. стать, и заменить тяжелые пакеты на более легкие Альтернативы. Бережливые темы, такие как Astra или GeneratePress, генерируют очень мало запросов и могут быть чисто оптимизированы. Внутри темы я деактивирую ненужные модули, например, коллекции иконок или слайдеры. Я также настраиваю построители страниц в минималистском стиле, чтобы они загружали только те виджеты, которые используются. Флаги функций и модульные очереди помогают избежать лишних файлов.
Целевое использование ресурсов и определение приоритетов
В дополнение к кэшированию и пакетированию Подсказки по ресурсам решающие штрихи. Я использую Preload только для действительно важных ресурсов: изображения LCP, основного CSS (если он не встроен как Critical CSS) и основного Webfont-файл. Слишком большое количество предварительных загрузок блокирует расстановку приоритетов и может привести к обратному эффекту. Для шрифтов я устанавливаю font-display (swap/optional), чтобы избежать FOIT, и создать предварительную загрузку с правильным в роли-атрибут, чтобы браузер не загружал файл дважды.
Предварительная выборка DNS и Предварительное подключение Я использую его в редких случаях для обязательных сторонних провайдеров (например, провайдеров платежей в кассе). Preconnect избавляет меня от необходимости Рукопожатие TLS, Однако это имеет смысл только в том случае, если ресурс точно нужен. Префеч Я использую для ресурсов, которые, вероятно, понадобятся на следующем этапе (например, следующая страница пагинации). В связи с Первые подсказки сервер может заблаговременно сигнализировать о предварительной загрузке - это сокращает время до первого байта, пока устанавливается соединение.
- Предварительная загрузка: Только для изображения LCP, основного CSS, критического файла шрифта.
- Preconnect: для безопасных, неизбежных сторонних доменов.
- Предварительная выборка: для ресурсов/страниц, которые потенциально могут понадобиться в ближайшее время.
- Предварительная выборка DNS: для небольшой, но благоприятной подготовительной работы с внешними узлами.
По возможности я также использую Приоритетные подсказки (fetchpriority=“high“ для изображения LCP), чтобы браузер понимал, что действительно должно быть на первом месте. Это сокращает время загрузки и Последовательность запросов более точное управление.
Активы WordPress: загружайте только то, что вам нужно
Многие страницы загружают стили и скрипты глобально, хотя они необходимы лишь в некоторых шаблонах. Я определяю таких кандидатов и загружаю их условный - Например, скрипты форм только на страницах контактов, CSS слайдеров только там, где есть слайдеры, а активы WooCommerce только на страницах магазина, товаров и оформления заказа.
Особенно полезно заниматься уборкой:
- Emoji-Отключите скрипты и стили во фронтенде, поскольку современные системы имеют встроенные emojis.
- oEmbedфункционирует, если в него не встроен сторонний контент.
- Dashicons во фронтенде, если тема их не требует.
- jQuery Migrate если старые скрипты не висят.
- Гутенберг Блок-библиотека Загружайте CSS только в том случае, если стили блока действительно используются во фронтенде.
Для более тонкого управления активами я использую модульные очереди (на каждый шаблон/блок) или оптимизирующий плагин, который может деактивировать ресурсы на каждой странице. Это сокращает Список запросов быстро от огромного количества файлов до горстки действительно необходимых активов.
WooCommerce, формы и другие динамические области
У магазинов есть свои особые случаи: Известный фрагменты тележки-скрипт может вызвать множество повторных запросов через admin-ajax.php. Я загружаю эту функцию только там, где она имеет смысл (на страницах товаров, корзин, оформления заказа), и отключаю ее в блогах или на целевых страницах. Я кэширую мини-карты, где это возможно, и обновляю их только при реальном взаимодействии. Для изображений товаров я постоянно использую srcset и предварительно загрузите первое видимое изображение.
Для форм я уменьшаю Опрос-интервалы, отправляю валидации в пакетах и использую дебаггинг, чтобы ввод не передавался с каждым нажатием клавиши. По возможности я реализую поиск и фильтры через кэшированные конечные точки (например, REST), чтобы повторяющиеся одинаковые запросы обслуживались из кэша. Это снижает нагрузку на сервер, уменьшает количество HTTP-запросы и улучшает восприятие скорости.
Дальнейшее совершенствование изображений, iframe и мультимедиа
Для изображения LCP я использую fetchpriority="high" и установить точную предварительную нагрузку. В то же время я обращаю внимание на ширина/высота или CSSсоотношение сторон, чтобы не было смещения макета. Я предоставляю изображения с decoding="async", чтобы не блокировать рендеринг, и установите ленивый только там, где это имеет смысл: в первый Картинка не должна быть ленивой, все остальные должны быть ленивыми.
Я заменяю внешние iframe (YouTube, Maps, Social) на световые превью. Вместо того чтобы сразу загружать весь виджет, я показываю статичное изображение предварительного просмотра и загружаю настоящую вставку только после клика. Таким образом, я избавляюсь от многочисленных начальных запросов, которые не нужны при первом взаимодействии. Для своих собственных видео я использую постерные изображения, современные кодеки и адаптивную потоковую передачу, чтобы большие файлы не блокировали синхронизацию.
Очистка заголовков кэша и удаление кэша
Многие запросы возникают из-за неоптимальной работы кэша браузера или CDN. Я определяю для статических активов (CSS, JS, шрифты, изображения) длинные TTL с Управление кэшем и установите флаг неизменяемый. Для безопасного распространения обновлений я использую Версионирование в именах файлов или WordPressver-параметры. Важно: CDN должна правильно кэшировать строки запроса, иначе вы потеряете ?ver=-параметры теряют свою силу, и он перезагружается без необходимости.
ETag и Last-Modified чтобы повторные проверки проходили быстро, а ответы if-none-match/if-modified-since-responses помогают экономить объем данных. С stale-while-revalidate сайт остается отзывчивым, а обновления выполняются в фоновом режиме. Все это позволяет сократить количество переходов и обеспечить четкое планирование обновлений без хаоса в кэше.
Избегайте ошибок: Когда пакетирование и минификация - это слишком много хорошего
На сайте HTTP/2/3 Мне не нужно втискивать каждый кусочек в один файл. Слишком большие пакеты делают попадания в кэш, потому что каждое изменение делает недействительным весь блок. Я нахожу средний путь: несколько логически разделенных пучков, которые сохраняют небольшой критический путь и при этом позволяют повторное использование (например, пучок глобального ядра, пучок шаблонов, редко изменяемый пучок поставщиков).
Минификация также может вызвать проблемы: Uglify/Minify может повредить функции некоторых плагинов. Поэтому я тестирую шаг за шагом и при необходимости исключаю из Minify/Combine критические скрипты (например, встроенный JSON, платежные скрипты, Captcha). Целью является более стабильный, короткий критический путь, не рискованная связка, которая ломается при каждом обновлении.
Методология измерений: надежное тестирование вместо догадок
Я провожу измерения с помощью воспроизводимых профилей: Настольный и мобильный отдельно, с реалистичной пропускной способностью и дросселированием процессора. В DevTools я использую Покрытиедля того чтобы Неиспользуемые CSS/JS и диаграмму водопада, чтобы увидеть, какие запросы ожидают, укладываются в стопку или замедляются по приоритетам. Я сравниваю Первый взгляд и Повторный просмотр, чтобы проверить, действительно ли работают заголовки кэша и действительно ли количество запросов при повторном посещении уменьшается вдвое или даже больше.
Я также установил ограждения: максимальное количество Запросы на тип страницы, целевой показатель LCP, бюджет для сторонних провайдеров. Новые функции запускаются только в том случае, если они соответствуют бюджетам. Это позволяет поддерживать быстродействие сайта в долгосрочной перспективе, а не только непосредственно после оптимизации.
Тонкости работы на стороне сервера: TTFB и TLS
Помимо чистого количества запросов, имеет значение и время ответа сервера. Я храню OPcache активно, настройте PHP-FPM, убедитесь, что плагины работают без сбоев, и минимизируйте базу данных.круговые поездки. При использовании TLS я обеспечиваю короткую цепочку сертификатов, текущий TLS 1.3 и активированный Сшивание OCSP. Вместе с HTTP/3 это сокращает время рукопожатия и значительно ускоряет первые запросы - особенно для мобильных пользователей.
Краткое резюме
Я уменьшаю количество запросов, активируя кэширование, объединяя CSS/JS, модернизируя изображения и откладывая внешние скрипты. загрузка. Я размещаю шрифты локально и предварительно загружаю критически важные ресурсы чисто и целевой. CDN с HTTP/2/3 и быстрый хостинг уменьшают задержку и TTFB. Я использую измерения в PageSpeed, Lighthouse и GTmetrix, чтобы проверить, не сползают ли LCP, TBT и CLS в целевой коридор. Всего за несколько часов этот процесс часто позволяет перейти от вялых запросов 70+ к быстрым страницам, скорость которых значительно ниже 50.
