Перейти к содержимому 
Я оптимизирую скорость wordpress без плагинов с помощью ручного вмешательства, которое заметно сокращает время загрузки и надежно снижает основные показатели сайта. Так я сохраняю контроль над Запросыресурсов и побочных эффектов и устранить балласт в самом источнике.
Центральные пункты
- фотографии Последовательное сжатие перед загрузкой и преобразование в формат WebP
- Ленивая загрузка родной атрибут HTML вместо перегруженных расширений
- Кэширование через .htaccess/server и стратегию чистых заголовков
- Код Минимизируйте, объединяйте и избегайте блокировщиков рендеринга
- Балласт удалить в WordPress, базу данных и темы
Почему я оптимизирую без плагинов
Плагины кажутся удобными, но они добавляют запросы, скрипты и стили, которые блокируют начальные пути рендеринга и заставляют меня TTFB ухудшается. Каждая дополнительная зависимость увеличивает поверхность ошибок и усложняет анализ причин падения производительности. Я использую ручные меры, чтобы уменьшить цепочки нагрузки и минимизировать количество активных компонентов. Это позволяет мне снизить накладные расходы, сохранить гибкость и быстрее реагировать на новые требования. Такой подход предотвращает побочные эффекты, вызванные цепочками обновлений, и сводит обслуживание к минимуму. slim.
Сделайте изображения тонкими: Форматы, размеры, сжатие
Большие изображения не убивают время до первого байта, но они доминируют над временем передачи и LCP, поэтому я уменьшаю каждый актив. заранее. Я экспортирую фотографии в JPEG или WebP и использую PNG только для настоящих прозрачных изображений. Я масштабирую размеры точно в соответствии с требуемой шириной области просмотра, вместо того чтобы загружать 4000px, когда достаточно 800px. Затем я последовательно сжимаю изображение с помощью Squoosh, ImageOptim или Photoshop и проверяю на наличие видимых артефактов. Для отзывчивых вариантов я полагаюсь на srcset/sizes и предпочитаю использовать этот короткий вариант Руководство по отзывчивым изображениямчтобы браузер автоматически загружал наименьший значимый источник, а мой Передача данных уменьшается.
Используйте ленивую загрузку нативно
Я загружаю изображения и iFrames только тогда, когда они попадают в область просмотра, нативно через HTML5, вместо того чтобы интегрировать дополнительные скрипты, которые означают Основная нить load. В современных браузерах вполне достаточно атрибута loading="lazy". Таким образом, я уменьшаю количество начальных байтов и уравниваю критическую фазу рендеринга. В то же время управление остается прозрачным, и я сам решаю, какие элементы над разворотом я намеренно загружаю с нетерпением. Критические изображения героев получают loading="eager", все остальное загружается смещение.
<img src="beispiel.jpg" alt="Пример изображения" loading="lazy">
<iframe src="video.html" title="Видео" loading="lazy"></iframe>Целенаправленное ускорение LCP: Приоритеты и промежуточные результаты
Чтобы повысить стабильность Largest Contentful Paint, я явно помечаю свой самый большой элемент над разворотом. Изображениям присваивается fetchpriority="high" и задаются размеры, чтобы браузер предпочитал их и CLS избегает. При необходимости я добавляю предварительную нагрузку, если путь свободен.
<!-- LCP-Image priorisieren -->
<link rel="preload" as="image" href="/assets/hero.webp" imagesrcset="/assets/hero-800.webp 800w, /assets/hero-1200.webp 1200w" imagesizes="(min-width: 800px) 1200px, 100vw">
<img src="/assets/hero-800.webp"
srcset="/assets/hero-800.webp 800w, /assets/hero-1200.webp 1200w"
sizes="(min-width: 800px) 1200px, 100vw"
width="1200" height="700"
fetchpriority="high"
loading="eager"
decoding="async"
alt="Герой">Для изображений и контейнеров я задаю ширину/высоту или соотношение сторончтобы исключить скачки раскладки. Для некритичных областей я использую content-visibility: auto и contain-intrinsic-sizeчтобы впоследствии браузер отображал области за пределами области просмотра без перемещения макета.
/* Резерв над разворотом */
.hero { aspect-ratio: 12 / 7; }
/* Разместите невидимые секции позже */
.section { content-visibility: auto; contain-intrinsic-size: 1000px; }
Настройте кэширование браузера особым образом
Повторяющиеся посетители должны загружать статические активы из кэша, поэтому я устанавливаю время истечения срока действия непосредственно на уровне сервера через хтакесс или на vHost. Длинные TTL для изображений, умеренные для CSS/JS и короткие по умолчанию для HTML обеспечивают баланс между своевременностью и скоростью. Я обращаю внимание на последовательное версионирование файлов, чтобы обновления вступали в силу немедленно, несмотря на длинные TTL. В сочетании с заголовками ETags или Last-Modified трафик значительно сокращается. Это экономит полосу пропускания и сокращает время, затрачиваемое на Время загрузки.
ExpiresActive On
ExpiresByType image/jpg "доступ плюс 1 год"
ExpiresByType image/jpeg "доступ плюс 1 год"
ExpiresByType image/gif "доступ плюс 1 год"
ExpiresByType image/png "доступ плюс 1 год"
ExpiresByType text/css "доступ плюс 1 месяц"
ExpiresByType application/pdf "доступ плюс 1 месяц"
ExpiresByType text/javascript "доступ плюс 1 месяц"
ExpiresByType application/x-javascript "доступ плюс 1 месяц"
ExpiresDefault "доступ плюс 2 дня"Стратегия кэширования, версионирование и ревалидация
Я комбинирую длинные TTL с хэшированием имен файлов, чтобы клиенты кэшировали одинаковое количество времени (style.9c2a.css), и обновления вступают в силу немедленно. Для часто изменяемых пакетов я устанавливаю Cache-Control: public, max-age=31536000, immutableв то время как HTML короткий no-cache-стратегии. Для динамичных ответов я предпочитаю Условные запросы через ETag или Last-Modifiedчтобы клиенты проводили ревалидацию редко:
Набор заголовков Cache-Control "public, max-age=31536000, immutable"
</FilesMatch
.
Набор заголовков Cache-Control "no-cache, no-store, must-revalidate"
</IfModuleДля материалов с различными форматами (например, WebP против JPEG) я проверяю, что Vary: Accept установлен правильно на Edge; это предотвращает попадание в кэш неправильных версий. Я поддерживаю согласованность версий с помощью конвейеров сборки, чтобы ни один актив не устаревал неконтролируемым образом.
Оптимизация CSS и JavaScript
Я минифицирую CSS/JS локально в процессе сборки и удаляю комментарии, пробелы и неиспользуемые элементы. Селекторы. Критические стили для верхней части страницы я упаковываю в строку, остальные загружаю асинхронно или в виде отложенного файла. Я перемещаю блокирующие рендеринг скрипты в конец, добавляю к ним defer/async и сохраняю небольшое количество внешних библиотек. Для фреймворков я проверяю, как качается дерево, и проверяю области импорта, чтобы не загружать все, что редко используется. По возможности я связываю файлы в пакеты, чтобы уменьшить количество запросов без кэширования на задней стороне. ухудшаться.
Улучшить INP: Разгрузить основной поток
Для того чтобы рисовать с низким уровнем взаимодействия, я разбиваю длинные задачи на более мелкие кусочки, избегаю перегрузки макета и отделяю сложные обработчики от взаимодействий. Я использую отложить для модулей, установить пассивные слушатели событий и запланировать некритичную работу на время простоя:
.
document.addEventListener('touchstart', onTouch, { passive: true });
const expensiveInit = () => { /* ... */ };
requestIdleCallback(expensiveInit, { timeout: 1500 });
// Разделение длинных задач
function chunkedWork(items) {
const batch = items.splice(0, 50);
// обрабатываем...
if (items.length) requestAnimationFrame(() => chunkedWork(items)))
}Я измеряю длительные задачи в DevTools, удаляю дубликаты библиотек и заменяю jQuery-утилиты нативными API. Я суммирую обновления DOM, использую трансформировать вместо верх/лево и свести повторные потоки к минимуму.
Избавьтесь от балласта WordPress
Мне не нужны многие функции WP на продуктивных сайтах, поэтому я отключаю эмодзи, oEmbeds и часть REST API и экономлю деньги. Запросы. Это уменьшает размер головы, и меньше скриптов блокируют First Paint. Я также проверяю pingbacks, ссылки RSD и манифест WLW и отключаю их. Я также отключаю трекбеки и XML-RPC, если они не играют роли. Таким образом, я уменьшаю площадь атаки и сохраняю начальную фазу. свет.
// Деактивируйте эмодзи
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
// сокращаем oEmbeds и REST API
remove_action( 'wp_head', 'wp_oembed_add_host_js' );
add_filter('rest_enabled', '_return_false');
add_filter('rest_jsonp_enabled', '_return_false');Укрощение сторонних скриптов
Сторонний код часто является самой большой тормозной площадкой. Я инициализирую его с задержкой, включаю только то, что абсолютно необходимо, и загружаю его только после взаимодействия или согласия. Аналитика/отслеживание на подходе async после "Первой краски" я заменяю социальные виджеты статическими ссылками. Для iFrames я использую loading="lazy" и песочницачтобы ограничить побочные эффекты. Вставки YouTube получают изображение предварительного просмотра и загружают плеер только при нажатии - это экономит несколько запросов при запуске.
Обслуживание базы данных без помощников
Я удаляю лишние ревизии, пустые переходные периоды и очищаю спам-комментарии через phpMyAdmin, чтобы сделать запросы быстрее. ответ. Я проверяю параметры автозагрузки на предмет чрезмерного размера, потому что они оказываются в каждом запросе. В небольших установках для оптимизации таблиц достаточно нескольких целевых SQL-запросов. Я проверяю, не висят ли задания cron, и привожу в порядок постмету, оставленную старыми плагинами. Регулярное обслуживание предотвращает выход запросов из-под контроля и загромождение бэкенда. вялый завещание.
Системный Cron вместо WP Cron
Чтобы обеспечить надежное и эффективное выполнение заданий cron, я отделяю их от загрузки страницы. Я деактивирую WP-Cron и планирую реальные системные задания, которые работают в спокойное время.
// в файле wp-config.php
define('DISABLE_WP_CRON', true);# crontab -e (каждые 5 минут)
*/5 * * * * * * /usr/bin/php -q /path/to/wp/wp-cron.php >/dev/null 2>&1Это означает, что никакой cron не блокирует время отклика обычного запроса, а повторяющиеся задачи, такие как очистка переходных процессов или создание карты сайта, могут быть запланированы.
Критически проверьте тему, плагины и шрифты
Я удаляю неактивные темы и все расширения, которые дублируют функции или редко приносят пользу, чтобы Автозагрузка загружается меньше. Для шрифтов я сокращаю варианты до regular/bold и двух стилей шрифта, размещаю их локально и активирую предварительную загрузку для основного файла. Я подготавливаю внешние ресурсы с помощью DNS prefetch, если они мне действительно нужны. Для вложений в YouTube я использую миниатюры для последующей инициализации iFrame. Таким образом я сохраняю контроль над путями рендеринга и сохраняю начальную полезную нагрузку маленький.
Шрифты: поведение при загрузке, подмножество, обратные связи
Веб-шрифты сильно влияют на воспринимаемую скорость. Я использую Отображение шрифта: swap или опциячтобы текст был сразу виден. Я критически проверяю переменные шрифты и подставляю области Unicode для экономии байтов. Целенаправленная предварительная загрузка наиболее важного файла WOFF2 уменьшает количество FOIT.
.
@font-face {
font-family: 'Brand';
src: url('/fonts/brand-regular.woff2') format('woff2');
font-weight: 400;
font-style: normal;
font-display: swap;
unicode-range: U+000-5FF; /* базовый набор латиницы */
}Я определяю чистые системные резервные шрифты (например, Segoe UI, Roboto, SF Pro, Arial) в стеке шрифтов, чтобы минимизировать скачки верстки. О сайте Регулировка размера Я настраиваю разницу в метрике так, чтобы переход от фаллаута к веб-шрифту был едва заметен.
Сервер, PHP и протоколы
Без правильной инфраструктуры любая оптимизация будет безуспешной, поэтому я обращаю внимание на быстрые SSD, современные PHP-версии и поддержка HTTP/2. OPcache, Brotli/Gzip и мультиплексирование HTTP/2 ускоряют доставку и уменьшают количество блокировок. Если возможно, я рассматриваю HTTP/3/QUIC и тщательно проверяю настройку и конфигурацию TLS; эта короткая статья на Реализация HTTP/3. Нагрузочные и стресс-тесты показывают, как страница реагирует на нагрузку. Так я убеждаюсь, что мой стек поддерживает приложение несет и мои меры эффективны.
| Хостинг-провайдер | Характеристики | Производительность | Поддержка | Соотношение цены и качества |
|---|---|---|---|---|
| веб-сайт webhoster.de | SSD, PHP 8.*, HTTP/2 | ★★★★★ | ★★★★★ | ★★★★★ |
| Конкурент 1 | SSD, PHP 7.*, HTTP/2 | ★★★★☆ | ★★★★☆ | ★★★★☆ |
| Конкурент 2 | Жесткий диск, PHP 7.*, без HTTP/2 | ★★★☆☆ | ★★★☆☆ | ★★★☆☆ |
Оптимизация PHP-FPM, OPcache и транспорта
Я настроил PHP-FPM так, чтобы запросы не попадали в очередь. pm, pm.max_children и pm.max_requests Я увеличиваю нагрузку. OPcache получает достаточно памяти, чтобы избежать рекомпиляции.
php.ini / www.conf
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0
PHP-FPM (примеры значений)
pm = динамический
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 8
pm.max_requests = 500На транспортном уровне я активирую Brotli перед Gzip, держу открытым Keep-Alive и проверяю возобновление TLS. В HTTP/2 я проверяю приоритеты, чтобы CSS/шрифт и изображение LCP имели приоритет. В HTTP/3 я отслеживаю потерю пакетов и регулирую темп.
CDN, заголовок кэширования и география
Для международного трафика я использую пограничную сеть, чтобы снизить задержки и держать статические активы ближе к пользователю. доставлять. Я уделяю внимание чистоте ключей кэша, вариантам заголовков (например, для WebP) и последовательной версификации. Я тщательно кэширую важные HTML-страницы, выборочно - ответы API и агрессивно - изображения. Краткий обзор Оптимизация CDN помогает мне избежать таких подводных камней, как двойное сжатие. Таким образом я сочетаю серверное и пограничное кэширование и снижаю затраты. Посмотреть.
Форматы, согласование и дедупликация на границе
Я воспроизвожу изображения в современных форматах (WebP, опционально AVIF) и слежу за тем, чтобы CDN соблюдала согласование контента. Важными являются правильные Принять-варианты и уникальность ключей кэша. Я избегаю двойного Gzip, сжимая только один раз (сервер или Edge) и деактивируйте флаг на другом конце. Для HTML я устанавливаю консервативные TTL и сильные ETag, активы остаются агрессивно кэшированными.
Измерение, ключевые показатели и расстановка приоритетов
Я начинаю с четкого бюджета производительности и фокусируюсь на LCP, CLS и INP, а не на каждом миллисекундном значении. изолированный учитывать. Полевые данные превышают лабораторные показатели, поэтому я сравниваю сигналы реальных пользователей с тестовыми испытаниями. Диаграммы водопада выявляют блокирующие активы, карты запросов показывают дубликаты библиотек и ненужные файлы шрифтов. Я измеряю каждое изменение по отдельности, чтобы быстро выявить регресс. Только когда показатели стабильно улучшаются, я внедряю их более широко. с сайта.
Метод работы: чистое развертывание, быстрый откат
Я включаю проверку производительности в свой процесс развертывания: Сборки генерируют версионированные артефакты, тесты Lighthouse/DevTools выполняются в staging, и только проверенные пакеты запускаются в работу. Флаги функций позволяют мне контролируемо внедрять рискованные изменения и немедленно деактивировать их в случае необходимости. Это позволяет мне поддерживать стабильную производительность, пока я разрабатываю новые функции.
Краткое содержание: Как я это реализую
В первую очередь я оптимизирую контент с наибольшим эффектом: уменьшаю размер изображений, активирую ленивую загрузку, встраиваю критические части CSS и блокирую скрипты. смена. Затем я защищаю стратегии кэширования на стороне браузера и сервера, привожу в порядок функции WordPress и базу данных и удаляю ненужные плагины. Я проверяю инфраструктуру, HTTP/2/3, Brotli и OPcache и обеспечиваю чистые процессы развертывания с версионированием. При необходимости я добавляю CDN и регулирую заголовки и варианты. Наконец, я итеративно проверяю ключевые показатели, пока LCP, CLS и INP не станут стабильными и "зелеными". Области ложь.
