Долгий ответ сервера wordpress как исправить

Время ответа сервера — это время, которое требуется браузеру посетителя для получения ответа от сервера вашего хостера.

Вот 27 способов уменьшить время отклика сервера.

Позиции с № 1 по № 10 загружаются менее чем за 2,3 секунды

В 2016 году SEO-мастер Брайан Дин проанализировал более 1 млн результатов поиска, чтобы выяснить, какие факторы приводят к тому, что страница занимает первое место в Google.

Брайан обнаружил, что веб-страницы, занимающие первые и вторые места в Google, имеют среднее время загрузки 2 секунды или меньше.

SEO — это настолько сложная тема, что кажется почти абсурдным, что такая простая вещь, как ускорение работы вашего сайта, может помочь вам достичь первой страницы результатов поиска.

Доказательства совершенно очевидны: ваши шансы попасть на страницу №1 Google резко возрастают , если вы сможете заставить свой сайт загружаться за 2 секунды или меньше.

И оказывается, что это не так уж и сложно.

Мне удалось сократить время загрузки моего сайта до 1,7 секунды, по данным Pingdom:

Как я это сделал?

Именно это я и собираюсь показать вам в этой статье: 27 способов уменьшить время отклика сервера в WordPress.

Но сначала, что такое время отклика сервера?

Как его проверить?

А что такое хорошее время отклика сервера?

Что такое время отклика сервера?

Время ответа сервера (SRT) — это время, которое проходит с момента запроса веб-браузером данных с сервера до момента ответа сервера на этот запрос.

Также упоминается как Time To First Byte (TTFB).

В тесте Google Page Speed Insights, показанном ниже, Google сообщил о времени отклика сервера как об одной из возможностей улучшения производительности данного конкретного сайта:

Как проверить время отклика сервера?

Лучший способ проверить время отклика вашего сервера — это Page Speed Insights от Google.

Если время отклика вашего сервера медленное, Google внесет его в список «Возможности» (для ускорения времени загрузки).

Вот два других инструмента для измерения времени отклика сервера:

Что такое показатель PSI Google?

Google создал тест Page Speed Insights в 2018 году, вскоре после объявления «Google Speed Update» в июле того же года.

В отличие от Pingdom и GT Metrix, тест Google PSI не измеряет время загрузки напрямую.

Выставляет оценку вашему сайту, основываясь на ряде факторов, влияющих на удобство работы с мобильными устройствами:

• От 90 до 100 — «Быстрый»
• От 50 до 89 — «Средний»
• От 0 до 49 — «Медленный»

Если вы получили оценку 90 или выше, индикатор PSI становится зеленым.

Читая между строк, кажется вероятным, что Google хочет, чтобы все сайты имели показатель PSI 90 или выше.

Как получить оценку 90+ в PSI Google?

Есть пять ключевых улучшений, которые вы можете сделать, чтобы ваш сайт получил оценку PSI 90+:

• Оптимизация изображений
• Минимизация CSS и JavaScript
• Используйте CDN (сеть доставки контента) для доставки таких вещей, как изображения и PDF.
• Устранение блокировки рендеринга ресурсов
• Включение GZIP-сжатия на вашем сервере

Потребность в скорости

Так что же заставляет уделять особое внимание скорости веб-сайта?

Как вы, возможно, знаете, мобильные устройства обгоняют настольные компьютеры.

В 2017 году впервые мобильные устройства превзошли настольные: 50,3% всего просмотра Интернета приходится на мобильные устройства.

Этот процент увеличился в 2018 году до 52,2%. И процент мобильного интернет-серфинга будет продолжать расти.

Но вот в чем проблема:

Настольные браузеры обычно подключены к высокоскоростному Интернету. Но большинство мобильных пользователей используют гораздо более медленные соединения (3G и 4G).

Если Google и другие поисковые системы намерены удовлетворить растущий спрос со стороны мобильных пользователей, им необходимо, чтобы веб-сайты предлагали более быстрое время отклика.

Именно здесь на помощь приходит Google Page Speed Insights.

Можно предположить, что сайты, не имеющие показатель PSI 90+, будут иметь проблемы с ранжированием на первой странице Google.

Итак, теперь, когда вы понимаете, почему скорость стала таким важным вопросом, давайте рассмотрим способы сделать ваш сайт быстрее.

#1 — Обновите версию PHP

В декабре 2015 года был выпущен PHP 7. Для примера, PHP 7 примерно в 3 раза быстрее, чем PHP 5.6.

Если вы не используете PHP 7, вы должны немедленно обновить .

После активации плагина перейдите в раздел ‘At a Glance’ вашей приборной панели WP и вы увидите вашу версию PHP:

Это плагин, который нужно использовать только один раз.

Как только вы проверили свою версию PHP, деактивируйте плагин и удалите его.

Если окажется, что ваш сайт не использует PHP 7, свяжитесь с вашим хостером и попросите его включить PHP 7.

#2 — Проверьте, используете ли вы HTTP/2

HTTP/2 — это новый сетевой протокол, представленный в 2015 году. Это может сделать ваш сайт на 10-15% быстрее.

Используйте этот инструмент, чтобы проверить, использует ли ваш сайт HTTP/2.

Если ваш сайт уже использует HTTP/2, поздравляем — вы входите в число 27% всех сайтов, использующих HTTP/2 в настоящее время.

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

#3 — Используйте GZIP-сжатие

Еще один способ уменьшить время отклика сервера — применить GZIP-сжатие.

GZIP означает GNU zip. Это формат файла и программное приложение, используемое для сжатия и распаковки файлов. Проще говоря, он уменьшает размер именованных файлов.

Сжатие GZIP делает ваши веб-страницы быстрее, уменьшая размер файла до 90%.

Используйте инструмент сжатия GZIP, чтобы проверить, использует ли ваш сайт GZIP.

Если нет, вы можете включить его на своем сервере (через cPanel) или использовать плагин Check and Enable GZIP Compression.

#4 — Загружайте скрипты позже

Еще один способ уменьшить время отклика сервера — загружать скрипты по мере необходимости.

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

Сценарии, необходимые для продолжения работы на странице, загружаются только тогда, когда пользователь попадает на нее.

Это называется ленивой загрузкой .

Вот пример рекомендации Google PSI использовать Lazy Loading для «отправки изображений за пределы экрана»:

#5 — Используйте серверы имен Cloudflare (бесплатно)

Это еще один простой (и бесплатный) способ уменьшить время отклика сервера. Когда вы меняете свои серверы имен на серверы имен Cloudflare, ваш сайт получаетвоспользоваться преимуществами глобальной сети центров обработки данных Cloudflare.

Cloudflare имеет 165 центров обработки данных по всему миру.

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

Это приводит к значительному ускорению загрузки .

Вот видео, в котором рассказывается о процессе настройки серверов имен Cloudflare:

Примечание: изменение серверов имен на Cloudflare не означает смену веб-хоста — ваш веб-хост остается прежним.

#6 — Используйте сеть доставки контента (CDN)

Еще один отличный способ сократить время отклика сервера — использовать сеть доставки контента или CDN.

CDN — это глобальная сеть серверов, которая доставляет страницы и другой веб-контент пользователю, основываясь на его географическом положении.

Cloudflare является примером CDN.

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

Я использую StackPath в качестве CDN ($10 в месяц).

Он сократил время загрузки моего сайта примерно на 2 секунды, по данным Pingdom.

При использовании CDN вы сможете увидеть в результатах Pingdom, что большая часть вашего контента доставляется CDN (в данном случае StackPath):

#7 — Уменьшение блокировки рендеринга JavaScript

Блокировка рендеринга происходит, когда браузер пытается отобразить страницу и сталкивается со сценарием, который он должен выполнить, прежде чем продолжить загрузку.

Это увеличивает время загрузки вашей страницы.

Решение? Минимизируйте JavaScript.

Большинство плагинов оптимизации производительности имеют опцию «минифицировать JavaScript»:

#8 — Используйте плагин кэширования

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

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

Примерами плагинов кэширования являются:

#9 — Сократите количество внешних скриптов

Когда вашему сайту приходится вызывать внешние скрипты для загрузки страницы, это может значительно замедлить время загрузки.

Старайтесь свести внешние сценарии к минимуму .

Вот несколько примеров внешних сценариев:

• Скрипты видео YouTube
• Блок комментариев Disqus
• Кнопки социального обмена
• Блок живого чата
• Формы опт-ин и всплывающие формы Формы опт-аут.в и всплывающие модули
• Google Fonts

#10 — Установка WP Disable

Платформа WordPress может быть быстро раздута различными «запросами». Эти запросы замедляют время загрузки ваших веб-страниц.

Плагин WP Disable делает ваш сайт быстрее, отключая определенные «запросы», такие как:

• Emoji
• Gravatars
• Embed
• Trackbacks,
• WooCommerce скрипты и CSS
• RSS
• XML-…RPC
• Автоматическое сохранение
• Теги Windows Live Writer
• Теги коротких ссылок
• WP API
• Комментарии
• Контроль сердцебиения

Панель управления позволяет выбрать, какие из этих элементов вы хотите отключить.

#11 — Очистка базы данных

Большинство плагинов для оптимизации производительности имеют функцию очистки базы данных.

В Swift это называется «оптимизацией базы данных».

На следующем снимке экрана показаны элементы базы данных, которые можно исключить для ускорения загрузки:

#12 — Оптимизация изображений

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

Для быстрой загрузки сайта ваши изображения должны быть не более 100 кб.

Используйте Screaming Frog для проверки содержимого вашего сайта. Установите фильтр изображений на «более 100 КБ», чтобы вы могли определить изображения, которые необходимо оптимизировать:

Если у вас много изображений, которые необходимо оптимизировать, рассмотрите возможность использования платной услуги, такой как Kraken.

Всего за несколько долларов в месяц вы можете оптимизировать свои изображения партиями.

И у вас будет лучшая степень сжатия, чем при использовании бесплатных сервисов.

#13 — Обновите свой хостинг

Лучший способ сократить время отклика сервера — просто выбрать хостинг с быстрыми серверами. Все советы и рекомендации, упомянутые в этой статье, будут бесполезны, если ваш веб-хост работает медленно.

Медленный веб-хостинг обычно вызван одним из этих двух факторов (или обоими):

• У вашего хостера недостаточно ресурсов сервера, или
• Ваш хостер размещает слишком много сайтов на одном сервере

Если любое из этих условий применимо к вашему сайту, вы никогда не добьетесь времени загрузки менее 2 секунд.

Как же узнать, какие веб-хостинги являются быстрыми?

Для многих блоггеров, как и для меня, это просто процесс проб и ошибок.

Я начал с HostGator, затем перешел на Bluehost, а теперь я с SiteGround.

Существует несколько сайтов, которые анализируют скорость работы веб-хостов.

Но имейте в виду, что эти сайты часто зарабатывают деньги через партнерские ссылки веб-хостов.

И это сразу ставит под сомнение объективность любого совета, который они дают.

Из личного опыта могу сказать, что SiteGround — самый быстрый хостинг, с которым я работал.

SiteGround показывает хорошие результаты в различных обзорах:

BitCatcha оценивает SiteGround как № 1 из 6 самых быстрых хостингов 2019 года.

Том Депюи отмечает, что SiteGround был признан лучшим веб-хостом 2018 года в группе Facebook ‘WordPress Hosting’.

#14 — Сведите количество плагинов WP к минимуму

Все плагины в той или иной степени замедляют время загрузки вашего сайта. Поэтому старайтесь, чтобы количество ваших плагинов не превышало 20.

Я недавно сократил количество своих плагинов с 40 (. ) до 28 и работаю над их дальнейшим сокращением.

#15 — Выбор правильных плагинов

Еще один хороший способ уменьшить время отклика сервера — устранить требовательные к ресурсам плагины WordPress. Известно, что некоторые плагины замедляют работу вашего сайта больше, чем другие.

Найдите альтернативы этим плагинам (а лучше вообще обойтись без них):

• Akismet
• JetPack
• WordPress Facebook plugin
• Contact Form 7
• The Divi Builder plugin
• Cursor Revolution
• SumoMe
• Любой плагин, который показывает «связанные сообщения» в конце каждой статьи или записи блога
• Essential Grid
• Система комментариев Disqus
• Проверка битых ссылок
• Безопасность Wordfence

#16 -… Убедитесь, что версия WP актуальна

Использование устаревшей версии WordPress сделает ваш сайт медленнее, чем необходимо.

Проверьте, какую версию WP вы используете в панели ‘At a Glance’ в приборной панели WordPress:

#17 — Убедитесь, что ваши плагины WP обновлены

Аналогично, использование устаревших версий ваших плагинов также приведет к тому, что ваш сайт будет загружаться медленнее, чем должен.

Поэтому обязательно обновляйте свои плагины всякий раз, когда видите уведомление об обновлении.

Для этого существует плагин: Easy Updates Manager (именно тогда, когда вы думали, что контролируете свои плагины).

#18 — Загрузите свой фавикон прямо в тему

Еще один способ уменьшить время отклика сервера — загрузить свой фавикон прямо в тему WordPress. Другими словами, не используйте отдельный плагин для загрузки своего favicon.

Вместо этого загрузите свой favicon прямо в тему:

#19 — Используйте плагины оптимизации скорости

Плагины оптимизации скорости сайта обычно делают любое (или все) из следующего в попытке ускорить ваш сайт:

• Оптимизация изображений
• Ленивая загрузка изображений
• Минификация HTML
• Минификация JavaScript
• Кэширование
• Ранняя загрузка
• Удаление мусорного содержимого (ревизии, комментарии, дублирование метаданных и т.д.))
• Удаление просроченных переходных процессов
• Оптимизация шрифтов

Вот некоторые популярные плагины для оптимизации скорости:

#20 — Используйте премиум DNS сервис

Все веб-хостинги предоставляют бесплатный DNS хостинг.

И это, вероятно, то, что вы имеете на данный момент.

Но за несколько долларов в месяц вы можете получить премиум-хостинг DNS.

DNS-хостинг премиум-класса обеспечивает минимальную задержку между поиском DNS и получением первого байта. Это уменьшит время отклика вашего сервера.

#21 — Удаление виджетов из боковой панели/футера вашего сайта

У вас куча виджетов в боковой панели?

Может быть, поисковая строка, форма регистрации, список популярных записей в блоге, список последних записей, список категорий записей в блоге и так далее?

Мой совет: удалите их .

Эти виджеты загружаются вечно, добавляя драгоценные миллисекунды к общему времени загрузки.

И вот в чем дело: боковая панель, как и нижний колонтитул, является элементом всего сайта.

Это означает, что эти виджеты должны быть загружены на каждой странице вашего сайта.

У меня были «блогроллы», которые состояли из последних записей, основных записей и категорий записей. У меня также был виджет «поиск по этому сайту» и форма оптина.

И я избавился от всего, кроме модуля opt-in.

Это сократило время загрузки на 2 секунды.

#22 — Выбор быстрой темы WordPress

За исключением официальной темы WP, бесплатные темы WordPress часто плохо закодированы и поэтому медленно загружаются.

Если вы хотите, чтобы ваш сайт загружался быстро, мой совет — приобретите тему премиум-класса.

ColorLib протестировал более 50 премиум WP тем и составил список самых быстро загружающихся WP тем.

Я был счастлив увидеть, что моя тема (MagazinePro) является одной из них!

#23 — Оптимизация домашней страницы для быстрой загрузки

Вы можете оптимизировать свою домашнюю страницу для быстрой загрузки:

• Показывать выдержки вместо полных сообщений
• Уменьшить количество сообщений блога на главной странице
• Выбрать меньший размер для основных изображений

Как видно из скриншотов ниже, мне, вероятно, следует выбрать меньший размер для основных изображений:

#24 — Используйте домены без cookies

Домен без cookies — это домен, который не обслуживает cookies.

Cookies — это небольшие пакеты информации, которые передаются между вашим сайтом и браузером посетителя.

Хотя файлы cookie являются ценным способом отслеживания производительности вашего сайта, большая часть вашего контента не нуждается в подключении файлов cookie.

Это содержимое может быть передано вашим посетителям с другого домена, домена без cookies. И это еще один способ ускорить время загрузки ваших сайтов.

#25 — Добавление заголовков Expires

Заголовки Expires — это часть кода, которая сообщает браузеру посетителя, должен ли он загрузить файл или просто перезагрузить его из своего кэша.

Если ваш посетитель уже был на вашем сайте, у него уже есть некоторые файлы, хранящиеся в его кэше.

Идея ‘expires headers’ заключается в том, что нет необходимости загружать файлы, которые браузер вашего посетителя уже загрузил в последний раз, когда он был на вашем сайте.

Заголовки ‘Expires’ экономят время и делают ваши веб-страницы быстрее.

Чтобы добавить ‘expires headers’ на свои веб-страницы, достаточно вставить около 15 строк кода в файл .htaccess.

Если вы предпочитаете использовать плагин, Far Future Expiry Header вставит код заголовка expires за вас.

#26 — Откладывание неиспользуемого CSS

В тесте Google Page Insights вы можете увидеть рекомендацию «отложить неиспользуемый CSS».

Неиспользуемый CSS загромождает страницы и делает их медленнее.

Вы можете удалить неиспользуемый CSS вручную, следуя инструкциям в этой статье.

Или вы можете использовать плагин Asset CleanUp: Page Speed Booster. Этот плагин очищает ваш код, создавая веб-страницы, которые загружаются быстрее.

#27 — Используйте ускоренные мобильные страницы (AMP)

Ускоренные мобильные страницы или AMP — это спонсируемый Google формат, который позволяет веб-страницам быстро загружаться на мобильных устройствах.

Когда вы включаете AMP на своем сайте, ваши страницы отмечаются в результатах поиска Google как быстрые, с небольшим значком молнии:

Одна из причин быстрой загрузки страниц AMP заключается в том, что они находятся на сервере Google, а не на вашем.

В статье под названием: Google AMP производит 600% увеличение скорости загрузки страниц мобильных сайтов, Кристин Чун сообщает, что использование Google AMP увеличило время загрузки веб-страницы с 6 секунд до 1 секунды.

Итак, простой акт включения AMP на вашем сайте WordPress может значительно увеличить скорость работы ваших страниц.

Как включить AMP?

Скачайте и установите официальный плагин AMP для WordPress (не другой плагин!)

Когда плагин включен, на экране редактирования записей вашего блога появится сообщение «AMP: Включено»:

Заключение

Люди, которые смогли довести время загрузки своего сайта до менее 2 секунд и показатель Google PSI выше 60, в настоящее время наблюдают огромный рост своего органического трафика в Google (включая этого автора).

Итак, потратьте время на реализацию некоторых из этих стратегий и сократите время отклика вашего сервера — оно того стоит!

Из перечисленных выше стратегий, вот те, которые дадут вам наибольшую отдачу:

• Использование сети доставки контента (CDN)
• Использование премиум DNS серверов
• Установка и активация плагина кэширования
• Удаление плагинов WordPress (target aмаксимум 20 плагинов)
• Удалите большинство виджетов из боковой панели вашего сайта
• Установите и активируйте плагин оптимизации скорости, например Swift
• Обновите ваш хостинг на более быстрый тарифный план или более быстрый хост

Поскольку мир переходит от настольных компьютеров к мобильным, время отклика сервера становится критическим фактором ранжирования .

Настанет время, когда только сайты, способные молниеносно доставлять контент мобильным пользователям, будут занимать первое место на странице Google.

Поэтому опережайте события и старайтесь, чтобы время отклика вашего сервера было менее 2 секунд .

Скорость и отказоустойчивость – одни из тех факторов, что неизменно влияют на популярность вашего ресурса, ведь даже с лучшим в мире контентом медленно работающий сайт будет раздражать читателей и рано или поздно вы их потеряете. В этой статье мы будем оптимизировать самый популярный блоговый движок — WordPress, работающий на PHP. А заодно рассмотрим несколько общих моментов в оптимизации сайтов.

1 Тестируем текущую скорость

Чтобы узнать изменилось ли что-нибудь после нашей оптимизации, не помешает замерять для начала текущую скорость загрузки страниц блога, чтоб было с чем сравнивать. Есть несколько инструментов, которые помогут сделать это:

1.1 Pingdom

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

Бенчмарк одного довольно известного ресурса.

1.2 YSlow

YSlow– плагин для Firefox, который встраивается в, пожалуй лучший плагин для веб разработчика, Firebug. Он анализирует более 20 факторов, которые влияют на скорость работы сайта и оценивает общую производительность по 100 бальной системе, а каждый отдельный элемент оценкой от A до F.

1.3 Количество запросов и время их выполнения

Вставив небольшой кусок PHP кода, можно вывести в футер количество запросов к БД и время, затраченное на их выполнение.

<?php echo get_num_queries(); ?> queries in <?php timer_stop(1); ?> seconds.

2 Web Hosting

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

• Shared Hosting – на одном сервере может хоститься в среднем около 100 человек;
• VPS – на одном сервере может хоститься около 20 человек;
• Dedicated – сервер будет использоваться только вами.

Чтоб просмотреть примерную нагрузку на сервер, залогиньтесь через ssh и введите в консоли команду top.

Это, конечно, не означает, что вы не сможете ускорить блог, работающий на виртуальном хостинге(Shared Hosting), однако стоит помнить – производительность тем выше, чем большие ресурсы мы имеем в своем распоряжении.

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

3 Установка и настройка сервера

Удостоверьтесь, планируемая нагрузка соответствует мощности сервера и он сможет с ней справиться. В первую очередь это будет зависеть от объема оперативной памяти и процессора. Как правило, WordPress ставят на Apache, но много удачных решений существует и на базе других http серверов: nginx, lighttpd и т.д.

Не забудьте обновить до последней версии PHP и Apache.

3.1 Отключите неиспользуемые сервисы

Вы можете получить больше доступной оперативной памяти, отключив неиспользуемые службы и оптимизировав MySQL и Apache.

• Удалите ClamD;
• Настроить SpamD на использование только 1 дочернего процесса;
• Удалите Mailman, если, конечно, вы не собираетесь запускать почтовый сервис.

3.2 MYSQL Query Cache

Поскольку стабильность и скорость WordPress довольно сильно зависит от работы БД, стоит убедиться, что настройки в my.cnf соответствуют возможностям сервера. В первую очередь следует установить настройки кэширования запросов, добавив в my.cnf следующие строки:

query_cache_type = 1
query_cache_limit = 2M
query_cache_size = 20M

Чтоб настройки вступили в силу придется перезапустить сервис MySQL сервис.

3.3 Кэш компилятора: XCache или Eaccelerator?

Кэш компилятора увеличивает производительность откомпилированных скриптов на сервере, кэшируя их – это поможет сократить время выполнения PHP скриптов. Стоит попробовать и то и другое решение, однако по результатам опытов увеличение производительности при использовании Xcache на 5% выше, чем с Eaccelerator.

3.4 Увеличьте максимальное число соединений на Apache

Увеличение максимального количества соединений в httpd.conf повысит производительность, т.к. сервер сможет обрабатывать большее количество подключений за раз. Однако, следует изменять этот параметр осторожно, дабы не исчерпать весь объем оперативной памяти и не замедлить работу сервера, потому всегда тестируйте новые настройки прежде чем запускать их в работу. Установим к примеру 150 коннектов:

max_connections = 150

Не забудьте рестартить сервис Apache, чтоб применить настройки.

4 Оптимизация кода и графики

Итак, сервер заработал и теперь настало самое время поиграть с кодом WordPress.

4.1 Отключите хотлинки

Каждый раз когда вы используете свой сервер для хранения изображений вы существенно больше используете его ресурсов. Довольно часто люди заимствуют ваши изображения, ставя хотлинки на своих серверах. Это не только занимает канал, но и создает определенную нагрузку на сервер.
Добавьте следующий код в .htaccess файл, заменив example.com на имя вашего домена, чтобы отключить использование хотлинков:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www.)?example.com/.*$ [NC]
RewriteRule .*.(gif|jpg|png|ico)$ - [F,L]
</ifModule>

4.2 Используйте внешний хостинг для хранения изображений

Хостинг изображений на внешних серверах поможет значительно снизить нагрузку на сервер. В примере ниже вы можете видеть снижение объема используемой оперативной памяти на одном из блогов после переноса изображений на сервис Amazon S3.

4.3 Сжимайте java-скрипт код

Сжатие javascript довольно простая задача. Поскольку он выполняется при каждом просмотре страницы, вы можете уменьшить размер Javascript, удалив все незаполненное пространство. Вот простой инструмент, который поможет сделать это за вас — JavaScript Compressor.

4.4 Javascript в начале страницы

Часто случается так, что сайт начинает загружаться медленно или вообще останавливается, т.к. другой ресурс, с которого вызывается javascript(на пример Digg badges, Tweetmeme и т.д.), не доступен или оффлайн. Чтобы избежать этого вынесите весь javascript код в конец страницы, а то что по каким-то причинам вынести не удалось – попробуйте заключить в iFrame.

4.5 Используйте кэш браузера

Сам по себе кэш браузера, конечно не сделает ваш блог быстрее, однако поможет снизить нагрузку на сервер, кэшируя часто загружаемые объекты(стили, элементы интерфейса и т.п.).
Попробуйте вставить следующий код в .htaccess файл:

FileETag MTime Size
<ifmodule mod_expires.c>
<filesmatch ".(jpg|gif|png|css|js)$">
ExpiresActive on
ExpiresDefault "access plus 1 year"
</filesmatch>
</ifmodule>

4.6 Сжимайте статические данные

Вы можете уменьшить размер загружаемой страницы позволив браузеру принимать и передавать данные в сжатом виде. Это также снизит загрузку канала и количество загружаемых данных.
Следующий код в .htaccess может помочь вам в этом:

AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/javascript text/css application/x-javascript
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4.0[678] no-gzip
BrowserMatch bMSIE !no-gzip !gzip-only-text/html

4.7 Используйте CDN для статических файлов

Если хранить все изображения на одном и том же домене, то браузер будет ожидать их загрузки одного за другим. Допустим на странице их у вас есть 12 штук, если вы разделите их между тремя поддоменами, они будут загружаться одновременно из трех «разных» источников вместо того, чтоб загружаться браузером по очереди из одного.
Можете попробовать перенести все css & javascript файлы на files.yoursite.com, а изображения и временные файлы на static.yoursite.com. Или же просто использовать CDN(Content Delivery Network) – большая сеть серверов, расположенных по всему миру, которые позволят не только хранить ваши файлы на разных поддоменах, а значит загружать их параллельно, но и доставлять пользователю данные с самого близкого к нему сервера. Все это позволит загружать данные намного быстрее.

5 WordPress

В этой части статьи мы рассмотрим приемы для улучшения производительности, которые можно применить непосредственно к WordPress.

5.1 Обновитесь до последней версии

Обновления до более новых версий позволяют не только устранять обнаруженные уязвимости, но и улучшают производительность. Для примера в wordpress 2.8 была существенно оптимизирована работа с БД.

5.2 Отключите Post Revisions

Во всех версиях wordpress, начиная с 2.6, редакции ваших статей каждый раз во время правки автоматически сохранялись. Это замедляет работу БД и увеличивает ее размер без особой надобности.
Чтоб отключить post revisions, добавьте следующую строку в wp-config.php:

define('WP_POST_REVISIONS', false);

Чтобы удалить сохраненные ранее ревизии текста, выполните следующий запрос в PHPmyadmin:

DELETE a,b,c
FROM wp_posts a
LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)
LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)
WHERE a.post_type = 'revision'

5.3 Сократите количество запросов

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

<meta http-equiv="Content-Type" content="<?php bloginfo('html_type'); ?>; charset=<?php bloginfo('charset'); ?>" />

Мы запросто можем переписать в:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

Уже на два запроса меньше. Довольно просто, не правда ли?

6 WordPress Plugins

И на последок предлагаю вашему вниманию несколько плагинов, которые могут повысить производительность wordpress. Как только все, описанное выше, будет выполнено, эти плагины помогут добиться еще более высокой производительности.

WP Super Cache
Это, пожалуй, лучший плагин к WordPress. WP Super Cache создает статические html версии каждой страницы и загружает их каждый раз, обходясь тем самым без запросов к БД. Это значительно увеличивает скорость загрузки страниц и снижает нагрузку на сервер. Строго рекомендуется к установке.

PHP Speedy WP
Этот плагин решает другую проблему, обозначенную в этой статье – удаление незаполненного пространства в CSS & javascript. Однако есть некоторые проблемы совместимости этого плагина с WP Super Cache, кроме того он долгое время уже не обновлялся, потому используйте на свой страх и риск.

Optimize DB
Плагин позволяет оптимизировать таблицы MySQL без помощи PHPmyadmin.

Счастья тебе и твоему уютному бложеку, %username%.

<?php echo get_num_queries(); ?> запросов. <?php timer_stop(1); ?> секунд.

• 1 месяц спустя…

Доброго здравия, друзья!

Сегодня я бы хотел рассказать вам как оптимизировать скорость и производительность сайта, а именно об таком параметре как TTFB.

TTFB (Time to First Byte — Время до первого байта) — это количество миллисекунд, которое требуется браузеру для получения первого байта ответа от вашего веб-сервера.

Более четко TTFB также называется «ожидание» от Google:

Если вы хотите оптимизировать скорость и производительность своего сайта, важно знать, на какие ключевые показатели следует обращать внимание.

Например, Time to First Byte (TTFB — Время до первого байта) измеряет количество времени, которое требуется браузеру пользователя для получения первого «байта» данных с сервера вашего веб-сайта.

Не для того, чтобы визуализировать его или показывать на экране. Но просто вернуть один байт в браузер.

В этом посте я объясню вам, что такое TTFB и почему это важно.

Затем мы обсудим, как его измерить и как вы можете уменьшить его на своем сайте WordPress.

Наконец, мы завершим некоторыми часто задаваемыми вопросами. Давайте уже начнем!

Что такое время до первого байта (TTFB)?

Время до первого байта измеряет реакцию вашего сервера на запрос браузера посетителя.

Другими словами, это количество времени, которое проходит между тем, когда пользователь переходит на веб-страницу, и тем, когда сервер его распознает.

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

И поскольку TTFB — это самое начальное взаимодействие, длительное время до первого байта означает, что остальная часть страницы даже не может начать загрузку.

Потому что сервер еще не ответил.

Следовательно, TTFB играет ключевую роль в пользовательском опыте (UX) вашего сайта, а также в его поисковой оптимизации (СЕО).

Это также один из основных показателей интернета (наряду с FCP — Первая содержательная отрисовка, LCP — Большая содержательная отрисовка и CLS — Накопительный сдвиг макета), который Google рассматривает для определения опыта загрузки страницы вашего сайта и, в свою очередь, его рейтинга.

TTFB похож на First Contentful Paint (FCP — Первая содержательная отрисовка), который также используется для измерения опыта загрузки и времени ожидания пользователя.

Однако FCP измеряет, сколько времени проходит, прежде чем посетитель увидит первый элемент на странице.

TTFB — это любая информация, видимая или нет.

TTFB веб-сайта состоит из трех основных процессов:

1. HTTP-запрос отправляется браузером посетителя на сервер;
2. Сервер обрабатывает запрос и готовит ответ;
3. Сервер отправляет ответ браузеру.

Чем быстрее этот процесс, тем быстрее и быстрее будет время загрузки.

Однако несколько факторов и проблем могут задерживать и замедлять его на каждом этапе.

Следовательно, чтобы оптимизировать скорость и производительность вашего сайта, вы, вероятно, захотите сосредоточиться на уменьшении TTFB.

Как измерить TTFB — Время до первого байта?

Существует несколько различных способов измерения TTFB, в том числе с использованием лабораторных и полевых инструментов.

Имеются в виду как смоделированные результаты (лаборатория), так и тестирование с использованием реальных пользовательских данных (поле).

Однако перед этим полезно сначала узнать, что такое хороший результат.

Обычно благоприятный TTFB находится где-то между 200 миллисекундами (мс) и 500 мс (0,2 и 0,5 секунды).

Конечно, чем меньше цифра, тем лучше.

Все, что превышает 600 мс, считается плохой оценкой.

Поскольку Google ввел скорость страницы в качестве фактора ранжирования, многие веб-сайты работают со временем менее 100 мс.

Однако в большинстве случаев все, что меньше 200 мс, по-прежнему считается «хорошим».

Есть различные инструменты, которые вы можете использовать для измерения TTFB.

Давайте рассмотрим несколько лучших вариантов.

WebPageTest

WebPageTest — это онлайн-инструмент, который позволяет быстро и легко проверить скорость вашей страницы.

Однако вы также можете использовать его для доступа к подробному отчету, который включает ключевые показатели, включая TTFB.

Чтобы использовать его, вы можете просто ввести свой URL-адрес в текстовое поле, а затем нажать кнопку «Start Test»:

На странице результатов вы можете просмотреть много информации о своем сайте.

Вверху вы можете найти общий балл для вашего TTFB.

В следующем разделе вы можете найти время в миллисекундах в столбце «First Byte»:

Согласно WebPageTest, целью является время, необходимое для согласования сервера доменных имен (DNS), сокета и уровня защищенных сокетов (SSL), плюс 100 мс.

На каждые дополнительные 100 мс, которые занимает TTFB, онлайн-инструмент понижает оценку вашего сайта на буквенную.

GTmetrix

GTmetrix — еще один бесплатный онлайн-инструмент, который можно использовать для измерения TTFB.

Вы можете ввести URL-адрес своего веб-сайта в текстовое поле, а затем нажать кнопку «Test your site»:

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

Далее по странице вы можете щелкнуть вкладку «Performance»:

В разделе «Browser timings» вы можете найти TTFB.

Это всего лишь два примера инструментов онлайн-тестирования, которые вы можете использовать.

Дополнительные популярные варианты включают Bytecheck, Pingdom и KeyCDN.

Каждый из них работает аналогично этим двум вариантам.

Вставка URL-адреса, запуск теста в реальном времени, а затем анализ отчета о результатах.

Инструменты разработчика Google Chrome (Chrome DevTools)

Еще один способ измерить TTFB — Chrome DevTools.

Если вы пользователь Chrome, вы можете использовать этот метод для измерения TTFB прямо в браузере без использования сторонних инструментов.

В то время как многие из упомянутых выше тестов скорости используют различные местоположения серверов, из которых вы можете выбирать, таким образом, этот напрямую от вас.

Из-за этого имейте в виду, что ваши конкретные условия сети и задержка в сети могут влиять на TTFB.

Следовательно, результат, который вы увидите при использовании этого метода, может отличаться от того, что видят посетители вашего сайта.

Для начала зайдите на свой сайт WordPress в браузере, а затем перейдите к трем вертикальным точкам в правом углу экрана.

Затем перейдите в «Дополнительные инструменты — Инструменты разработчика».

Это откроет консоль DevTools.

Оттуда щелкните любой элемент на странице, а затем выберите вкладку «Network» (Сеть), а затем столбец «Waterfall»:

В списке выберите элемент, который хотите проверить. Под панелью вы можете найти «Waiting (TTFB)».

Как уменьшить время до первого байта (TTFB) на вашем сайте WordPress (4 основных совета)?

Теперь, когда вы лучше понимаете, что такое TTFB и как его измерять, пора посмотреть, что вы можете сделать, чтобы его улучшить.

Ниже приведены четыре ключевых совета, которые вы можете использовать для уменьшения TTFB на своем сайте WordPress.

1. Обновите свой хостинг WordPress

Возможно, наиболее влиятельным фактором в TTFB является хостинг-провайдер вашего сайта.

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

Тип хостинга, который вы используете, влияет на скорость и производительность вашего сайта.

Например, если вы используете общий хостинг, у вас, скорее всего, будет доступ к ограниченным ресурсам.

И вы обязаны другим пользователям за пропускную способность и обработку вашего кластера серверов.

Поэтому, если вы страдаете от медленной загрузки и хотите уменьшить свой TTFB, вы можете подумать о переходе на нового хостинг-провайдера или более производительный план.

Если у вас общий хост, обновление вашего плана до более высокого уровня часто сопровождается приоритетным обслуживанием и более быстрыми серверами.

Кроме того, управляемый хостинг для сайтов WordPress — огромное преимущество для TTFB.

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

Более высокий уровень и / или управляемый хостинг обходятся дороже, чем хостинг эконом-класса, но просто нет лучшего способа получить более низкий TTFB (и общую скорость страницы), чем превосходный хостинг.

Я также рекомендую поискать веб-хостинг, который предлагает услуги DNS премиум-класса.

Время поиска DNS может способствовать медленному TTFB.

Использование премиальных инструментов DNS может помочь уменьшить задержку в сети и, в свою очередь, сократить время загрузки.

2. Используйте сеть доставки контента (CDN)

Один из наиболее эффективных способов повысить скорость сайта и уменьшить TTFB — это реализация CDN.

Если вы не знакомы с концепцией, это сеть распределенных серверов, расположенных по всему миру.

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

Вы можете выбирать из множества различных сервисов CDN для WordPress.

Некоторые из самых популярных вариантов включают Google Cloud CDN, KeyCDN и Cloudflare.

Фактически, некоторые хосты (например, SiteGround) предлагают бесплатную версию Cloudflare CDN со многими из своих планов.

Использование CDN на вашем сайте WordPress может помочь вам значительно уменьшить задержку в сети.

Помимо повышения производительности, CDN также может помочь укрепить безопасность вашего сайта, предотвращая такие угрозы, как атаки распределенного отказа в обслуживании (DDoS).

3. Удалите все ненужные плагины или темы (и обновляйте существующие)

Плагины и темы могут занимать много места и даже замедлять работу вашего сайта, особенно если они устарели.

Кроме того, старые расширения могут создавать уязвимости в системе безопасности и создавать ненужную нагрузку на ваш сервер и время загрузки.

Они могут быть не оптимизированы так хорошо, как могли бы, задерживая ваш TTFB из-за своего кода.

Убедитесь, что ваши плагины обновлены и необходимы.

Сокращение количества плагинов, которые у вас есть, определенно улучшит ваш TTFB, если они загромождают сервер вашего сайта.

На вашем сайте WordPress легко удалить любые плагины или темы, которые вы больше не используете.

Точно так же важно следить за тем, чтобы те, которые вы установили на своем сайте, оставались обновленными.

Если их код не оптимизирован настолько хорошо, насколько это возможно (особенно с обновлениями WP и т. д.), TTFB может пострадать.

На панели управления администратора WordPress вы можете найти доступные обновления плагинов, перейдя в меню «Плагины», а затем щелкнув ссылку «Доступно обновление»:

Имейте в виду, что разработчики плагинов и тем регулярно выпускают улучшения производительности и исправления ошибок для своих инструментов.

Оставаясь на вершине последних версий и исключая те, которые больше не служат цели, вы можете свести к минимуму занимание места на сервере.

4. Реализуйте кеширование на своем веб-сайте

Один из самых эффективных способов снизить нагрузку на сервер — использовать кеширование.

Кэширование — это метод, используемый для минимизации времени обработки сервером и более быстрой доставки контента.

Следовательно, это также полезная стратегия, которая может помочь уменьшить TTFB.

Есть множество плагинов кеширования WordPress, которые вы можете установить на свой сайт.

Некоторые из самых популярных вариантов включают WP Rocket и W3 Total Cache.

W3 Total Cache — это инструмент оптимизации производительности, который может помочь вам повысить скорость вашего сайта и СЕО.

Это также может помочь с интеграцией CDN.

Так что в этом отношении вы можете помочь с TTFB несколькими способами.

После установки вы можете получить доступ к настройкам, перейдя в «Производительность».

Этот плагин можно использовать бесплатно.

Однако, если вам нужны более продвинутые параметры конфигурации, есть профессиональная лицензия, доступная за 99 долларов в год.

Время до первого байта (TTFB) — часто задаваемые вопросы

К настоящему времени вы, надеюсь, имеете твердое представление о важности TTFB, о том, как его измерить и как его уменьшить.

Теперь давайте рассмотрим некоторые из наиболее часто задаваемых вопросов об этой метрике.

Как TTFB соответствует общей производительности моего сайта?

TTFB — это время между тем, когда посетитель заходит на ваш сайт, и когда его браузер получает первый байт данных с вашего сервера.

Другими словами, он измеряет реакцию вашего сервера на пользователя.

Это означает, что без приемлемого (читайте: низкого) TTFB остальная часть вашего сайта загружается медленно.

Даже если содержимое вашего веб-сайта полностью загружается менее чем за 1 секунду, если TTFB составляет 4 секунды (4000 мс), то общее время загрузки составляет ~ 5 секунд.

Таким образом, TTFB играет решающую роль в вашем UX и СЕО.

Google рассматривает TTFB как ключевой показатель при оценке рейтинга вашего сайта.

Любая оптимизация TTFB напрямую повлияет на другие показатели скорости страницы, такие как FCP и LCP.

Как лучше всего снизить TTFB?

Нет единого решения для уменьшения TTFB.

Поскольку основная цель — уменьшить время ответа сервера, я рекомендую использовать комбинацию методов, которые мы обсуждали выше.

Прежде всего, убедитесь, что у вас есть надежный хостинг-провайдер с отличной производительностью.

Затем внедрите CDN и систему кеширования на своем сайте, обновляйте плагины и удалите все ненужные надстройки, которые могут задерживать отправку ответа вашим сайтом.

TTFB не всегда основан на легковесном сайте, но, имея легкий сайт, можно быстро получить обратно первый байт.

Заключение

Скорость отклика сервера важна, если вы хотите, чтобы посетители вашего веб-сайта были довольны.

Если ваш сайт слишком долго отвечает, это увеличивает вероятность того, что они покинут ваш сайт.

Даже если ваш контент загружается быстро, если для начала загрузки требуются секунды, пользователи могут уйти.

Чтобы этого не произошло, важно обращать внимание на свой TTFB и принимать меры, чтобы поддерживать его как можно ниже.

У вас есть вопросы по оптимизации TTFB для вашего сайта WordPress?

Дайте нам знать в комментариях ниже!

А я на этом буду с вами прощаться — до скорых встреч и не болейте!

Статья была обновлена: 01 августа 2022 года

Помимо своего блога я веду еще несколько сайтов заказчиков. При этом возникают самые разные проблемы, которые приходится решать (собственно, для этого меня и нанимали). Одна из них – долгий ответ сервера. В чем заключается проблема?

В яндекс вебмастере появилось сообщение с таким содержанием:

Страницы сайта https://***.pro в среднем слишком долго отвечают роботу. При обращении к серверу среднее время ответа превышает 3 секунды. 

Долгая загрузка страниц затрудняет работу с сайтом https://***.pro. 

Проверьте ответ сервера и при необходимости обратитесь к хостинг-провайдеру. Перейдите в раздел диагностики, чтобы узнать обо всех известных Яндексу проблемах сайта.

Первым делом надо проверить, на самом ли деле это так. В том же вебмастере яндекса смотрим ответ сервера — 885 мс. Гугл спид тест выдает не намного лучший результат: По результатам проверки время ответа вашего сервера составило 0,74 секунды.

Вы скажете, что это немного? Ну, для сравнения, время ответа сервера блога, который вы читаете, составляет 10 мс. Конечно, на моем блоге самописная кмс, максимально адаптированная именно для моих нужд, а не тяжеловесный вордпресс. Однако, даже для вордпресса 1-3 секунды – это много.

Первым делом мне пришло на ум поругаться с техподдержкой хостинга заказчика. Однако, немного подумал и вспомнил про обычное кэширование. По умолчанию вордпресс ничего не кэширует, так что придется устанавливать плагин. Мой выбор пал на WP Fastest Cache

Ставим его и немного настраиваем. Сначала переключаем на русский язык (у меня почему-то по умолчанию стал китайский язык), а потом ставим галочки в этих местах:

Теперь проверяем время ответа сервера:

Мы улучшили результат в два раза! Это неплохо. Более того, мы загнали сайт в так называемую «зеленую зону гугла» — то есть скорость загрузки сайта признана хорошей:

Конечно, тут есть еще над чем поработать: сжать изображения, загружать асинхронно некоторые скрипты, но основное мы сделали – с помощью всего одного правильно настроенного плагина сумели уменьшить время ответа сервера. Если вам требуется помощь программиста по сайту, то вы всегда можете написать мне.

Автор этого материала — я — Пахолков Юрий. Я оказываю услуги по написанию программ на языках Java, C++, C# (а также консультирую по ним) и созданию сайтов. Работаю с сайтами на CMS OpenCart, WordPress, ModX и самописными. Кроме этого, работаю напрямую с JavaScript, PHP, CSS, HTML — то есть могу доработать ваш сайт или помочь с веб-программированием. Пишите сюда.

заметки, сайтостроение, wordpress

Наиболее частая задача, с которой ко мне обращаются клиенты — это оптимизация сервера для работы информационных сайтов на WordPress. Да и не только на WordPress, но на ней 90% сайтов.  Не менее часто обращаются люди, которым нужно оптимизировать сервер для быстрой работы интернет-магазинов. Это история отдельная, ибо там есть особенности.  И которая тоже когда-нибудь выйдет на страницах моего блога.  Так вот, это, можно сказать, стало уже типовой задачей.  Поэтому я решил подробно описать что такое оптимизация сервера и как это  происходит.  Какие возможности и настройки при этом затрагиваются.  Каковы причины, из-за которых возникает необходимость в оптимизации. С них, пожалуй, и начнём.

Зачем нужна оптимизация сервера? Наиболее частые причины

Вообще тут могут быть сотни различных вариантов, но это если рассматривать в подробностях. Я этого делать не буду, ибо почти все они в 90% случаев сводятся к следующим вариантам:

Хостер блокирует сайт за нагрузку, за превышение лимитов

Типичная картина первая: сайт разместили на обычном виртуальном хостинге и в какой-то момент по мере развития сайта и роста его посещаемости закономерно возникают предъявы от хостинга о том, что «уважаемый, а вы знаете, ваш сайт-де создаёт нагрузку на хостинг, превышает все установленные лимиты в дцать попугаев? Примите меры, разберитесь, покуда мы его не заблокировали». Такие вести вы можете получить совершенно внезапно от хостера, в лучшем случае. В терминальной стадии все может быть плачевней — ваш сайт хостер сразу просто блокирует за превышение нагрузки и пишет об этом уже по факту свершившегося.

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

SEO-специалисты, оптимизаторы рекомендуют добиться хорошей оценки в Google Pagespeed Insights

Типичная картина вторая: кто-то где-то как-то вам поведал о том, что сайт плохо растет в поиске если у него долгое время отклика. Мол, гугл имеет православный инструмент Pagespeed Insights, и если сайт не набирает достаточное количество попугаев в гугловой оценке, то будет у него все плохо, и вообще это чуть ли не единственная причина всех проблем с продвижением сайта. А вот если гугл покажет зелень — то все будет огонь, сайт взлетит в топы как ракета.

В этом как обычно, только доля правды, причем небольшая. Подробно об этом писал самый грамотный из известных мне на данный момент сеошников — Алексей Трудов, да и сам я добавлял пять копеек с интересными ссылками там же, в комментах.

Вкратце — этот инструмент НЕ ВЛИЯЕТ ни на что сам по себе. Имеет значение время отклика сайта. Если оно более 2 сек — есть смысл оптимизировать.  Время отклика можно увидеть там же, если раскрыть подробности по пункту «Сократите время ответа сервера».  Я же предпочитаю смотреть его через отладчик браузера.  Так же стоит знать, что многие сайты из топов имеют оценку «ниже плинтуса» — по 20-40 баллов, но это им не мешает сидеть в топах.  И с другой стороны, сайт может выдавать зелень — 90 попугаев, но быть «ниже плинтуса» уже в выдаче.   Сайт может иметь хорошую оценку, но открываться по 3-5 секунд. Или иметь 20-40 баллов — и летать за 0,3-0,5 секунд. Так что логику гугла и тех сеошников тут не уловить. Гугл предоставил неплохой инструмент, но не стоит доводить до маразма. Ориентироваться ли на его показания? Конечно! Но без фанатизма.  И без завышенных ожиданий.

Сервер «падает» от большой посещаемости сайтов

Чуть менее типичная картина третья ( может быть и продолжением и дополнением первой, второй, или обеих):
Сайт имеет приличную посещаемость от 10000 уников в сутки ( хотя может быть и меньше) и есть проблема со временем открытия страниц. Сначала в часы пик, а потом и вообще постоянно. При этом время открытия страниц дольше 1-2 секунд. Сайт может перестать расти или начать падать.

Все три вышеизложенные ситуации — это в 90% случаев то, с чем приходят клиенты обращаясь за оптимизацией настроек софта, аудитом или переносом сайтов. И в том случае, если ваши сайты уже работают на выделенном или виртуальном сервере, то это можно решить оптимизацией настроек софта. Если же сайт(ы) на виртуальном хостинге, то оптимальное решение подобной проблемы чаще всего действительно в переносе на VPS. Во втором случае часто можно даже ничего не делать с настройками, достаточно бывает только переноса на сервер с настройками по-умолчанию. Возможно позже и упрёшься в необходимость опттмизации, а возможно и нет.

Что происходит при этом и почему сервер не держит нагрузку?

Итак, для начала разберём почему могут быть подобные трудности. Нагрузка на сервер может возникать по трем наиболее частым причинам:

1.  У вас действительно очень посещаемый сайт и софт при стандартных настройках начинает захлебываться. Появляются лаги, некоторые или все страницы открываются дольше, особенно в часы пик.
2. Вторая причина — это поисковые боты. Особенно если большое количество страниц — то при посещениях индексирующих ботов могут появиться проблемы с производительностью. Это может быть как самостоятельная причина, даже когда на сайте относительно небольшой трафик, так и в совокупности с первым случаем — и люди и боты. Определить это можно по логам вебсервера — access лог можно проанализировать и это сразу будет видно.
3. Паразитный трафик. Это может быть обычный тупой брутфорс(перебор паролей) на админки сайтов, может быть попытка атаки на xmlrpc, а может быть банальный парсинг контента с вашего сайта.

Так ли необходима оптимизация под Google Pagespeed Insights?

Теперь стоит ещё раз остановиться на ситуации второй — когда вам нужна оптимизация ради оценки Гугла, якобы для продвижения сайта. На самом деле это миф, по большей части. Ибо пока сайт открывается быстрей 1-2 секунд — это МГНОВЕННО! И это практически не влияет на продвижение. Проблемы действительно могут быть, если сайт грузится дольше одной-двух секунд. Тогда это в самом деле может ухудшать поведенческие факторы, и влиять на SEO. Пруфы.

Как решить рекомендацию гугла  «Сократите время ответа сервера»?

Тем не менее, Гугл считает, что сайт недостаточно быстр, если TTFB более 0.2 секунды (200 ms). Такой загрузки можно добиться обычно только лишь кэшированием, и на этом остановлюсь чуть подробнее далее.

Но без кэширования норма времени генерации страниц сервером для того же wordpress обычно в пределах 0.5-1 сек. На очень быстром сервере с дефолтным шаблоном и php 7 пустой вордпресс будет показывать что-то около 0.3-0.5 секунд.
Если же в вашем случае это ощутимо дольше, то скорей всего можно комплексной оптимизацией настроек софта на сервере добиться более быстрой работы сайтов.

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

Какой софт на сервере обеспечивает работу сайта?

Прежде всего надо говорить об nginx. В большинстве случаев он и так уже стоит. Он обрабатывает все входящие запросы, и делает это очень легко и быстро. Второй компонент это — обработчик PHP. Это чаще всего apache. Как универсальный обработчик он стал стандартом де-факто практически у любых хостеров. Апач — прекрасный софт, как раз в силу своей универсальности.

Но он не выдерживает конкуренции с режимом php-fpm там, где появляется нагрузка. Он как раз чаще всего и является узким местом в производительности системы. Это решается подбором более производительного вашем случае режима работы и/или подбором настроек. (подробней о режимах работы и связках вебсервера  — компоненты nginx, apache, php-fpm, php-cgi)

Но режим имеет значение при ооочень больших нагрузках. Сотни тысяч посещений в сутки. Хотя, иногда и при десятках килоуников могут быть проблемы. Надо понимать, что php-fpm не прибавляет скорости. Он даёт лишь производительность.

Что это такое? Это значит, что он позволяет быстрее обрабатывать запросы при больших нагрузках. Там, где появляется большой трафик — апач начинает захлебываться, потреблять больше ресурсов. И там для  быстрой загрузки страниц возникает потребность увеличивать ресурсы сервера, переходить на более мощные тарифы или серверы.  Php-fpm же может держать бОльшие нагрузки даже на минимальных аппаратных конфигурациях.

Если в цифрах — то php-fpm примерно в  3-5 раз производительней apache. Это не значит, что он будет быстрей отдавать страницы, но.   К примеру, возмем дешевый VPS с 1 GB памяти и 1 CPU. Возьмем типовой сайт на wordpress.  Без кэширования, сайт на apache при этих ресурсах будет работать с минимальным временем отклика примерно до посещаемости 2-3 тысячи посетителей в сутки. Там конечно еще имеет значение количество хитов, но в среднем из практики цифры примерно такие. (Кейс — как я оптимизировал сайты на недорогом VPS )

Свыше 3к суточного трафика  у wordpress на апаче на таком VPS начнутся тормоза.  Особенно в часы пик.  Часто эта проблема решается кэширующими плагинами.  С ними можно говорить уже о 5-10к трафика при такой конфигурации. Если же сайт на этих ресурсах запустить в режиме nginx+php-fpm, то он будет откликаться максимально быстро даже при 10-20к трафика.  Если поставить кэширующий плагин  — можно еще получить запас прочности в 2-3 раза — до 30к трафика.

И наконец, если использовать серверное кэширование nginx, на таком VPS можно держать сотни тысяч посещений 🙂

Настройка сайтов в режиме nginx+PHP-FPM

К примеру, любая из популярных CMS из заголовка статьи гораздо лучше держит нагрузку в режиме nginx+php-fpm. У меня почти все сайты на wordpress, так я только в таком режиме их и запускаю. Типовая конфигурация для wp имеет примерно такой вид:

server {
server_name vpsadm.ru www.vpsadm.ru;
charset off;
index index.html index.php;
disable_symlinks if_not_owner from=$root_path;
include /etc/nginx/vhosts-includes/*.conf;
include /etc/nginx/vhosts-resources/vpsadm.ru/*.conf;
access_log /var/www/httpd-logs/vpsadm.ru.access.log;
error_log /var/www/httpd-logs/vpsadm.ru.error.log notice;
set $root_path /var/www/user/data/www/vpsadm.ru;
root $root_path;
location / {
try_files $uri $uri/ /index.php?$args;
location ~ [^/].ph(pd*|tml)$ {
try_files /does_not_exists @php;
}
}
location @php {
fastcgi_index index.php;
fastcgi_param PHP_ADMIN_VALUE "sendmail_path = /usr/sbin/sendmail -t -i -f webmaster@vpsadm.ru";
fastcgi_pass unix:/var/www/php-fpm/vpsadm.sock;
fastcgi_split_path_info ^((?U).+.ph(?:pd*|tml))(/?.+)$;
try_files $uri =404;
include fastcgi_params;
}
listen *:80;
}


Это полная конфигурация сайта из наиболее популярной панели управления ISPmanager 5, которую я использую сам, и рекомендую клиентам. Но это можно настроить на любом сервере. Просто сия панелька позволяет это делать очень легко и удобно. Подробно я показывал все эти возможности в своем видео о настройке сервера с помощью ISPmanager 5
Конфиг, большой, но панель пишет его сама, и  самая важная строчка тут это:

try_files $uri $uri/ /index.php?$args;


Панель этого не умеет, по крайней мере пока. Именно она обеспечивает корректную работу ЧПУ, и заменяет привычный файл .htaccess, используемый в Apache. А вот в VestaCP есть шаблоны конфигов под работу популярных CMS в этом режиме.
Joomla тоже будет работать с аналогичным конфигом в связке nginx+php-fpm. А в случае с DLE все выглядит чуть сложнее:

Впрочем, ДЛЕ крайне редко нуждается в такой оптимизации, ибо сама CMS легкая и быстрая, да ещё и внутренний кэш имеет.

Но большой трафик способен нагрузить абсолютно любые, даже самые лёгкие и быстрые CMS. Все меры, которые я опишу дальше, основаны на кэшировании.

Основа оптимизации всего и вся — кэширование

Это единственный принцип, который даёт ощутимый эффект к производительности в работе любого серверного софта, и в том или ином виде он применяется на всех уровнях стека LAMP/LEMP(классически аббревиатура обозначает Linux Apache Mysql PHP, но сейчас уже давно стандартом де-факто стало использование nginx+apachе/php-fpm+mysql).

Что такое кэширование в терминах серверных программ? Это сохранение некоторых или всех результатов работы от первых обращений к софту в некий кэш в оперативной памяти или на диске. Поэтому при повторных обращениях софт уже может не исполнять код заново, а просто сверить — то что будет получено в виде результата совпадает ли с уже сохранным ранее результатом? И если это так, то просто отдает сохраненый результат, не выполняя работу заново. Это позволяет снизить использование ресурсов и добиться улучшения скорости и/или производительности в разы, а то и в десятки раз.

Аналогичным образом работает всем известный кэш браузера — он сохраняет на диск ранее полученные файлы сайта — т.н. статичные, и при повторных обращениях уже просто отдает их с диска, не напрягая сеть и сайт повторно.

Итак, теперь можно переходить к подробностям — какая оптимизация делается в том или ином случае, и что за параметры надо крутить.

Оптимизация и ускорение исполнения PHP-кода

С этим обычно связаны самые большие накладные расходы в работе CMS. Чтобы это было понятней вам, мне придется объяснить что такое язык PHP.

Дело в том, что языки программирования делятся на компилируемые и интерпретируемые. К первым относится например C++ и его дедушка C(си), на котором написано больше всего софта в мире. Это значит, что код однажды переводится в машинный язык и в таком виде остаётся, это и есть готовая программа. Поэтому он выполняется очень быстро — сразу в процессор, грубо говоря. PHP же, и многие другие языки, которые используются ныне для веб-разработки (python, js, ruby) относятся к языкам интерпретируемым или скриптовым. Это значит, что программа представляет собой набор команд и исполняется последовательно, «на лету».

Это даёт больше гибкости и удобства в разработке, но оказывается сильно медленней и требует гораздо больше ресурсов.

Представьте себе, ваш сайт работает на CMS, состоящей из десятков или даже сотен скриптов, которые друг о друга зависят и вызываются один из другого. Вы запрашиваете всего одну страницу, но к сайту идут десятки запросов для того чтобы эту страницу собрать. Это можно легко увидеть через отладчик браузера. Вот, для загрузки страницы моего блога посылается 66 запросов на сервер.

66 — это не много.  Чаще всего при работе с wordpress запросов около сотни. В случае с интернет-магазинами — может  быть и 200-300.

Обращение к PHP при этом производится к одному скрипту, но тому для получения результата нужно чтобы выполнились десятки или сотни других скриптов.  В случае с wordpress — обычно это index.php. И каждый из таких скриптов выполняется аналогично — последовательно и на лету. Это уже совсем дебри, но я, пожалуй, покажу вам, как это выглядит изнутри:

Для загрузки одной страницы веб-сервер исполняет 82 скрипта самого wordpress и плагинов  на этом сайте.  У меня не влез в один экран список вызовов скриптов, который я вытащил с помощью ядерного отладчика strace.  Но должно быть отчетливо видно, что все эти скрипты  от index.php до footer.php были исполнены в одну секунду  «17:22:59» и время исполнения составило  около 0,3 секунд.  0,304571, если быть точным 🙂

Обычно лазить туда системным отладчиком нет необходимости,  это время можно увидеть через отладчик браузера — это многим известный TTFB:

О нём же и говорит гугл в своей многим непонятной рекомендации о сокращении ответа сервера. Примерно соответствует, верно? Откуда взялись еще 80 милисекунд?  А это время, затраченное вебсервером nginx на «общение»  с обработчиком php и сборку html-страницы. Как видите, на фоне исполнения PHP он молниеносен. Это действительно так.  В этом легко убедиться, если исключить всю работу php и mysql, оставив отдачу страницы одному только Nginx:

Тут видим всё же не 0,08 сек, а чуть больше — 0,11. Чем объяснить? Я не знаю, а копаться еще и в системных вызовах nginx у меня желания нет 🙂 Тут  на таких малых цифрах может быть всё что угодно — может просто  скачки нагрузки на оборудование, а может быть во время обработки PHP nginx не всё время просерает ждёт, а делает что-то ещё параллельно. Зная его и восхищаясь этим крутым веб-сервером, я подозреваю что так и есть — и эти 0,03 сек никуда не теряются, а лишь накладываются  на время исполнения PHP. Ну да ладно.  На последнем скрине — это идеальный вариант отдачи страницы, и о нем будет речь чуть дальше.

Оптимизация исполнения PHP кода CMS с помощью акселераторов opcache, xcache, APC

А пока вернемся к PHP.  С некоторых пор научились сохранять частично или полностью результат выполнения скриптов. Так называемая прекомпиляция. Это не полноценная компиляция, потому что PHP в принципе не может быть скомпилирован. И в любой момент что-то где-то может измениться во входных данных, в коде, и тогда уже этот сохраненный результат будет не валидным, т.е. неправильным. Потребуется исполнение кода заново. Вот за реализацию этого механизма отвечают специальные модули (расширения) языка PHP, называемые акселераторами. Их есть несколько разных, некоторые из них уже устарели, но все они используют один и тот же принцип кэширования. На тему акселераторов в разных версиях PHP есть на хабре хорошая статья, с наглядными графиками.

Впервые я с этим столкнулся когда всюду использовалась версия PHP 5.3. Я стал использовать это в виде расширения APC, и это стало довольно таки прорывной вещью для меня и проекта, над которым я тогда работал. Начиная с версии 5.5 обычно используется opcache, и говорят он вроде как встроен. Но на самом деле не всегда. Обычно это дополнительное расширение, которое нужно доустанавливать.  С установкой проблем нет, его можно легко включить в том же ISPmanager в разделе «Расширения PHP». В случае если вы не юзаете панель управления, то оно ставится  с помощью yum (centos) или apt-get (ubuntu, debian).  Что-то вроде:

yum install php-opcache


Иногда достаточно одной лишь установки, если у вас один  небольшой сайт на простенькой CMS. И чаще бывает так, что акселератор opcache установлен, но работает неэффективно, ибо по-умолчанию ему выделено недостаточно памяти.

Как проверить установлен ли opcache или другой акселератор PHP?

Обычно из консоли можно просто просмотром версии PHP, комадной php -v:

Но то что он установлен ещё не гарантирует, что он задействован на вашем сайте. При проверке таким образом можно точно сказать что он оптимизирует ваши сайты, если на сервере установлена лишь одна версия PHP.  Кроме этого при проверке таким способом срабатывает PHP-CLI — интерфейс командной строки. Но расширение может быть не подключено для режима PHP, на котором работает сайт — для apache, например.

Во-первых, он может быть установлен не для той версии PHP, которая используется для сайта.  Как на 100% убедиться, что он задействован? Исполнить проверку с помощью функции phpinfo().  Этот метод (описывал тут ) позволяет со 100% точностью определить все настройки PHP для вашего сайта.

Но и это ещё не всё.  Дело в том, что opcache может не работать, если PHP запущен в режиме CGI. Почему — вдаваться в подробности не буду. Просто потому, что такие особенности у этого режима.  Недаром он самый низкопроизводительный.  Если вы хотите чтобы opcache работал, то нужно запускать сайт в режиме модуля apache или php-fpm.

Как посмотреть настройки и эффективность работы opcache?

Для этого можно добавить в корень сайта файлик opcache.php с таким кодом.  Затем, при обращении по адресу site.com/opcache.php можно будет увидеть статистику работы акселератора:

Чаще всего вы увидите аналогичную картину. Это значит что акселератору не хватает памяти. Кэшируется лишь часть скриптов.  Соответственно, те, что не закэшированы всякий раз исполняются полностью, что снижает производительность веб-сервера.  Там же можно посмотреть список закэшированных скриптов и прочие настройки расширения.   Эффективность работы можно увидеть на вкладке hits.

В данном случае казалось бы эффективность не сильно снижена, что и отражает данная статистика. Hits  это попадания — т.е. выполнение кэшированных скриптов, которые выполняются гораздо быстрей.  Misses — пропуски, т.е скриптов в кэше нет. В данном случае мимо кэша идёт всего лишь 0,7% скриптов.  Но тут надо понимать, что в эти 222 тысячи миссов может попадать тот самый скрипт, который требует больше памяти и выполняется по 5 секунд 🙂  Гораздо эффективней акселератор будет работать, если у вас статистика использования памяти имеет такой вид:

А статистика исполнения скриптов из кэша примерно такая, или еще лучше:

В данном случае opcache настроен «на грани» ибо память как видите забита почти вся, осталось 16 байт 🙂 Такая ювелирность связана с небольшим количеством памяти на VPS, я подсчитал чтобы ровно столько сколько нужно использовалось и не килобайтом больше…  На самом деле нет.  Просто я не заглядывал туда давно, и эти копейки там уже особо роли не играют, а значения 128 и 256 это стандартные «айтишные» числа — степень двойки, и «ювелирная точность» просто совпадение. Вряд ли у меня там упускается и не попадает в кэш что-то критичное. Вот, а в случае с клиентом, с которого взяты первые три скрина — увеличение памяти повлияло ощутимо.   Там нормальные настройки opcache ускорили сайт примерно с 2 сек до 1,3.

Какое ускорение и прирост производительности даёт opcache?

Тут  не угадаешь. Обычно от 30 до 100% ускоряет. Иногда больше, иногда меньше.   Но в целом примерно такая картина —  наличие и отлаженная работа акселератора ускоряет отклик страниц в 1,5-2 раза

Где и какие изменить настройки opcache?

Нужно искать файлик opcache.ini где-то в /etc/. В разных системах и разных версиях PHP он может называться по-разному — 20-opcache.ini например, быть в /etc/php5/apache2/conf.d/opcache.ini или в /etc/php/php.d/20-opcache.ini. А иногда даже в /opt/remi/php70/etc/php/php.d/2o-opcache.ini, как например при использовании ISPmanager 5 и настройке opcache для альтернативных версий PHP. Имеет он примерно такой вид:

zend_extension=opcache.so
opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.fast_shutdown=1
opcache.max_accelerated_files=7963
opcache.blacklist_filename=/etc/php.d/opcache*.blacklist ; (comment this out in your dev environment): 
opcache.revalidate_freq=0
opcache.validate_timestamps=0

Итак, для оптимизации требуется подобрать количество памяти в мегабайтах, в очевидном параметре opcache.memory_consumption, также стоит изменить и opcache.max_accelerated_files — количество прекомпилированных скриптов. Нужное вам количество можно подобрать поглядывая на третью вкладку scripts в статистике opcache.  Увеличивайте, пока количество кэшированных скриптов при работе сайтов не станет меньше чем указанное значение. Точно так же подбирайте.

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

Смысл в отключении валидации файлов скриптов на изменения. Кэшер всякий раз проверяет изменился ли скрипт, прежде чем использовать кэшированную версию. Это дополнительные ресурсы и время. Отключение этой валидации позволяет добавить еще процентов 20-30 к производительности выполнения кода. Причем, вам необязательно что-то реально разрабатывать чтобы столкнуться с проблемами. Элементарная настройка шаблона или плагинов через панель управления того же wordpress может глючить. Посему, не используйте эти настройки. О них очень легко забыть и потом биться в истерике пару часов, пока вспомните почему не работают настройки и не появляются изменения 😀 Проверено.

Оптимизация настроек xcache

Фухх. Это только opcache. Есть еще apc, который уже устарел, и после версии 5.4 больше не используется. Хотя и есть костыли для обратного портирования даже на php 7, но юзать их тот еще гемор. Да и смысла в этом обычно нет.  А вот Xcache в принципе заслуживает внимания. Просто потому что он по эффективности почти не уступает opcache (см. график с хабра выше). Но в них настройки сводятся все к тем же принципам — увеличение памяти и количества скриптов.  В Xcache еще нужно подбирать count — количество пулов в зависимости от количества ядер и/или процессоров в системе.  Но останавливаться на этом сильно не буду. Покажу лишь как выглядит его статистика до и после оптимизации, бо недавно делал и скрины недалеко:

Это работа неоптимизированного акселератора.  Всего 16 мегабайт памяти.

А вот так он работает после настройки:

Тут была сделана оптимизация под четырехядерный процессор. Как видите появились пулы, и все они стали заполняться данными. Под которые понадобилось более 512 мегабайт.

Настройка пулов PHP-FPM

При использовании PHP-FPM не стоит оставлять ему конфиг по-умолчанию. Дело в том, что он с ним работает нестабильно и непонятно потребляет ресурсы.  У fpm, кстати, довольно редко, но случаются странные зависания, выяснить причину которых практически невозможно. Ну по крайней мере я за 4 года работы с этим софтом способов не нашел.  Зато на сотнях серверов опытным путём нашел,  что при использовании режима dynamic FPM то чаще всего и ведёт себя неадекватно.  Поэтому конфиг пула я делаю примерно таким:

pm = ondemand

pm.max_children = 10

pm.max_requests = 500

Вот это три самые важные параметра, а все остальные можно оставить по-умолчанию.  Первое режим.   Всего там могут быть три варианта  — кроме указанного еще static и dynamic есть. По умолчанию стоит именно dynamic и он самый нестабильный из всех возможных. Static — более стабильный, но ресурсоёмкий. Ибо он сразу запускает все процессы и выделяет на них память, поэтому с количеством процессов в таком режиме нужно быть очень осторожным.  Ondemand самый удобный режим. Он работает так же стабильно как статик, но не жрет ресурсы. Как только ему нужны еще процессы — он их запускает. Не нужны — процессы умирают.

Далее,  максимальное количество процессов, которые могут быть запущены — pm.max_children.  Я обычно ставлю в зависимости от мощности сервера.  Примерно 10-15 процессов на каждые  2 Gb памяти.

pm.max_requests  —  это количество обработанных процессом  запросов (выполненных скриптов), после чего процесс будет перезапущен. Позволяет избегать зависаний и утечек памяти.

Этот конфиг по умолчанию находится где-то в /etc/php-fpm.d/www.conf в centos, и в /etc/php5/fpm/pool.d/www.conf в deb-based системах (debian, ubuntu). Но это, как всегда, не точно 🙂  Во-первых, у вас сайты и пулы могут быть запущены под другим юзером. Тогда вместо www.conf нужный файлик будет именован как username.conf. Соответственно пулов и конфигов может быть несколько, они могут запускаться параллельно. А во-вторых, у вас может быть использоваться php альтернативной версии, и тогда нужно искать конфигурации пулов в другом месте. В каком — лучше всего смотреть через phpinfo().

Очистка любого конфига от примеров и комментариев, документации

Часто в этом конфиге есть уже много чего, но большая часть — это описание конфига на английском. В большой портянке неудобно править настройки. Поэтому иногда бывает нужно очистить конфиг от лишних строк, оставив только значимые — строки самих параметров.

Сделать это можно так:

cat /etc/php/php-fpm.d/www.conf|grep -v  '^;|^$'

Это означает «вывести файл на консоль без пустых строк и строк, начинающихся с точки с запятой».   Можно сразу подготовить «чистую» конфигурацию для дальнейшей работы:

mv /etc/php/php-fpm.d/www.conf  /root/www.conf_orig cat /root/www.conf_orig |grep -v  '^;|^$' > /etc/php/php-fpm.d/www.conf

Таким образом можно очищать любые конфиги, однако надо помнить, что точка с запятой для комментов используется только в конфигурации PHP.  Большая часть софта имеет в качестве комментариев в начале строк конфигов решетку #.

Соответственно вариант будет таким:

cat /etc/httpd/conf/httpd.conf|grep -v '^#|^$'

Но у апача конфиг не такой большой, обычно в этом нет особой необходимости.

Базовые настройки PHP под нагрузку и тяжелые скрипты

Пулы и акселерация это хорошо.  Но кроме этого часто есть необходимость настроить глобальную конфигурацию самого PHP. Это делается через файлик php.ini.   В нем есть несколько наиболее важных параметров, без изменения коих часто бывает невозможно запустить тяжелые долговыполняющиеся скрипты.  Это более распостраненные настройки, обычно разработчики приложений и сайтов и сами знают о них.

Максимальное время исполнения скрипта.  К примеру, вы заливаете на дорвей миллион ключей из файла через какой-то веб-интерфейс.

По-умолчанию:

max_execution_time = 30

Это в секундах. Лучше добавить  сюда как минимум ноль, установив в 300. А иногда надо даже 600.

Максимальный объем памяти для выполнения одного (1!) скрипта.

memory_limit = 128M

По-умолчанию оно установлено в 128 мегабайт. Я недаром заострил внимание что речь идет лишь об одном скрипте. Помните сколько скриптов исполняется при запросе одной страницы? Это значит, что если у вас какое-то простое приложение, то обычно не нужно большое количество памяти для одного скрипта. И если приложение ее требует, то это повод задуматься о том, что что-то не так в коде. Но когда речь идет об импорте данных, это ситуация нормальная. Просто задавайте больший объем, перезапускайте apache и пробуйте еще раз. Увеличивать рекомендую с шагом в x2, обычно 256-512-1024 — ну просто для удобства используют эти числа.

Кроме этих параметров есть и другие, например максимальный объем загружаемого файла:

post_max_size = 8M
upload_max_filesize = 10M


Эти параметры тоже говорят сами за себя и обычно редактируются в паре. Максимальный объем POST-запроса — т.е. любых передаваемых на сервер данных и максимальный объем загружаемого файла, это именно по файлам.

В принципе больше особо никаких настроек тут не требуется.  Ну если вы настраиваете сервере с нуля, без панели, то может понадобиться включение  short_open_tag  и чего нибудь типа max_input_vars.

Оптимизация настроек производительности  apache (httpd)

Почему я пишу apache(httpd)? Потому что в rpm-based системах (centos, rhel, fedora)  сам apache нигде не фигурирует. Он там называется httpd. В deb-based системах это именно apache, причем apache2. Ну это не относится непосредственно к оптимизации, просто это следует знать, чтобы не потратить кучу времени на поиск конфигов и сервиса.

Соответственно конфигурации их будут где-то в /etc/apache2/apache2.conf и /etc/httpd/httpd.conf.

Оптимизация apache сводится к настройке количества процессов и запросов.  По аналогии с вышеописанными пулами PHP-FPM.

Однако в apache кроме этого есть разные режимы работы — prefork, worker, event. В 98% случаев у вас будет именно первый.

И его конфигурация имеет примерно такой вид:

StartServers 5
MinSpareServers 2
MaxSpareServers 4
ServerLimit 256
MaxClients 256
MaxRequestsPerChild 250

Этим в принципе оптимизация apache и исчерпывается. Ну иногда еще есть смысл настроить таймауты и KeepAlive, но в случае с обычными сайтами скорей  всего оно не влияет ни на что. А вот вышеуказанные настройки влияют на распределение и использование ресурсов.

StartServers — количество процессов запускаемых при старте Apache

MinSpareServers — минимальное число неиспользуемых процессов. Очевидно что не стоит его указывать слишком большим для меньшего потребления ресурсов.

MaxSpareServers — максимальное число неиспользуемых процессов. И тоже, не следует его слишком большим ставить. Так, например ставят часто по 20 или даже 50 процессов. В этом нет никакого смысла, по опыту. 5-10 процессов — это потолок, даже в самых нагруженных серверах. Тем более если будете проводить комплексную оптимизацию и менять настройки остального софта.
 

ServerLimit и MaxClients — максимальное количество одновременных соединений. Если указать их слишком большим, то при атаке или большом трафике есть риск, что апач ляжет пытаясь принять много соединений, но не успевая их обработать. И нужно понимать, что такое одновременные соединения. Это значит что пользователи одновременно в одну и ту же секунду нажали ссылку. 256 соединений могут образовать примерно 1-2 тысячи человек, находящихся на сайте онлайн. Таким образом, если ваш потолок трафика 10к в сутки — то никаким образом вы не упрётесь в эти ограничения — на апач будет лишь 10-20 одновременных подключений.
MaxRequestsPerChild — этот параметр задает максимальное количество запросов, обработанных каждым процессом, прежде чем оный будет перезапущен (уничтожен). Это означает, что ваше приложение с меньшей вероятностью может зависнуть или сожрать память. Процессы всегда «свежие», в которых наверняка нет каких-либо зависших запросов.

Настройка и оптимизация mysql или mariadb под нагрузку и производительность

Итак,  добрались  мы и до базы данных.  Чем больше и тяжелей приложение или CMS — тем больше оно использует базу данных.  По умолчанию mysql поставляется вообще без какой-либо настройки.   В случае с mysql многие проблемы с производительностью решает опять же кэширование. И вот, мы добрались уже до третьего компонента, где кэширование — есть наиболее понятная  и эффективная оптимизация.

Конфигурация mysql обычно где-то в /etc/my.cnf  (centos) или  /etc/mysql/my.cnf  (deb).

Основные настройки — это кэш и его объем, память под временные таблицы, буферы под выполнение определенных типов операций.


query_cache_size=256M
query_cache_limit=8M
join_buffer_size = 8M
tmp_table_size =256M
max_heap_table_size =64M
thread_cache_size=16
table_open_cache= 4000
max_connections=50
max_allowed_packet=300M


Все эти настройки описаны во множестве других мануалов, однако кратко пробежимся.

query_cache_size и  query_cache_limit — это первое что нужно включить.  Это объем кэша запросов. От его объема зависит эффективность работы, примерно так же как и с opcache — малый объем памяти не позволяет кэшировать все запросы, которые можно.

join_buffer_size — джоины — это наиболее сложные и ресурсоемкие операции. Поэтому под них часто недостаточно объема памяти по умолчанию. Из-за этого джоины могут выполняться гораздо дольше

tmp_table_size и max_heap_table_size  — это тоже парные параметры, которые стоит использовать вместе.   Объем временных таблиц.

Дальше идут тоже размеры кэшей, но я точно не знаю как они влияют. Честно сказать, это особо и не нужно знать. Сейчас расскажу почему.

max_connections  — это важный параметр, который влияет на максимальный объем памяти, выделяемый mysql. Количество подключений, опять же одновременных. Подключения к базе данных это тоже такие операции, которых может быть немного даже при очень большом трафике.  Поэтому без крайней необходимости увеличивать его не стоит. Обычно когда такая необходимость возникает — вы увидите соответствующие сообщения в логах ошибок mysql/mariadb.   Часто при оптимизации следует даже уменьшить, особенно при увеличении буферов, типа join_buffer_size.  Поскольку тут идет перемножение — эти буферы умножаются на количество подключений.

max_allowed_packet — этот параметр не влияет на производительность mysql, однако бывает необходим, когда нужно залить большой дамп в базу.  Без его увеличения вы просто не сможете этого сделать.

Самый главный вопрос — какие значения в my.cnf указывать?

Очевидно что довольно сложно подбирать их эмпирическим путём.  Тут и возвращаемся к вопросу почему не так уж важно знать все эти параметры для настройки.  Ибо есть замечательная утилита mysqltuner, которая упрощает настройку mysql.  Она сверяет в настройки mysql с мощностью сервера и со статистикой их использования, на основе этого выдаёт рекомендации по увеличению тех или иных параметров.

Утилита устанавливается аналогично всему остальному софту из репозиториев — yum install mysqltuner (centos)  или apt-get install mysqltuner (deb, ubuntu). Она правда редко обновляется в репозиториях, и там версия менее функциональная, чем если поставить новую из исходников с гитхаба.  Но на 98% вам будет достаточно и этой.

После чего запускается просто вызовом без параметров

mysqltuner


Как посмотреть и прописать логин пароль mysql чтобы его каждый раз не вводить?

Иногда она выдаст сообщение о том, что не может подключиться к серверу. В этом случае с сервером mysql  у вас всё плохо и он действительно лежит. Если данные для авторизации не прописаны в конфиге в домашней папке пользователя, то нужно указать данные логин пароль.  Тут варианта два. Нужно либо указать при подключении логин пароль административного юзера, как правило root.  Этот путь хорош, если вам пароль известен, либо вы его можете посмотреть. К примеру, в ISPmanager 5 можно его увидеть в панели, вот так:

Либо, если у вас нету ispmanager, можно подсмотреть логин-пароль в файлике /root/.my.cnf  (обратите внимание на точку, это скрытый файл):

cat /root/.my.cnf

Выдаст нечто подобное:

Правда тут есть одно «но». Если у вас этот файлик есть, то mysqltuner просто отработает и всё.

Но если его нет, то и вот, заодно тут виден формат этого файлика —  пользуйтесь лайфхаком. Просто создайте его, и тогда вам не нужно будет вводить пароль при работе с mysql из командной строки.  Зачем вам это может вам понадобиться — это уже другой вопрос, но это очень мощное средство, которое позволяет заливать любых размеров базы, например, не упираясь в ограничения веб-аплоада, типа ограниченного объема файла, таймаутов вебсервера или глюков phpmyadmin.

Как пользоваться mysqltuner, что означает его вывод?

А мы продолжаем тюнить mysql.

Утилита выдаст что-то вроде такого:

Вывод делится на два раздела. Это статистика работы и рекомендации. Причем с указанием конкретных параметров и пороговых значений. Расписывать всю интерпретацию вывода это очень муторно,  и еще сложней объяснить как этим всем пользоваться.  Но суть такова, что в первой части вывода есть пункты, напротив которых не стоит статус «ОК».  Это не всегда проблема, некоторые из пунктов часто даже не решить, например «[!!] Temporary tables created on disk» — он обычно будет вылазить снова и снова, сколько бы вы не увеличивали tmp_table_size.  Тем не менее, если на вашем сервере настройки по-умолчанию, там будут другие параметры, и рекомендации, которые дадут существенную прибавку к производительности.  В частности, включение кэша запросов (помните да, что кэширование — это самая эффективная оптимизация? здесь тоже!).  Также и буферы, пулы. В общем, в самом низу вам выведется список параметров и пороговых значений.   Сделайте как там указано.  После чего понадобится рестарт mysql:

systemctl restart mariadb #(centos 7)

/etc/init.d/mysqld restart #старые системы и дебиан

service mysqld restart #новые deb — ubuntu

Но может и не сработать, ибо могут быть и другие варианты перезапуска, тут зависит от вашей OS и варианта СУБД — mysql или mariadb.

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

Часто будут просить еще увеличить что-то, а могут и появиться новые параметры.  Дальше повторяем процедуру с их изменением, рестартом mysql и повторным запуском тюнера после  «прогрева» базы.  Это может повторяться и 5, и 10, и даже 20 раз, особенно при отсутствии опыта и… каком нибудь перфекционизме 😀   Не стоит зацикливаться на буфере под временные таблицы, например. Обычно можно ставить его сразу побольше  1-2 гб — и больше не обращать внимания.  Но вот, innod_buffer_pool и query_cache_size — это вещи довольно важные, и их за несколько итераций следует привести к статусу «ОК».  В идеале это может выглядеть примерно так:

Проблемы при оптимизации mysql

Иногда ( а при отсутствии опыта чаще всего 🙂 ), вы можете столкнуться с проблемами при попытке оптимизировать mysql.  Например, mysql может отказаться перезапускаться, и показать что-то вроде fail.

В этом случае нужно срочно что-то делать, ибо ваши сайты отдают ошибку что не могут подключиться к БД 🙂

Бэкапьте конфиги перед любой настройкой!

Поэтому, всегда(!) делайте бэкапы конфигов ПЕРЕД ЛЮБЫМ В НИХ ВМЕШАТЕЛЬСТВОМ!   Это касается не только mysql, а вообще любых манипуляций описанных в данной статье. Лучше всего сделать бэкап всех конфигов, а они лежат в папке /etc/ , как вы могли заметить, если были внимательны.    Бэкап можно сделать например так:

rsync -avh  /etc/  /root/etc_backup_before_tuning/

Это означает сделать синхронизацию папки etc — в другую папку — /root/etc_backup_before_tuning/.  Поэтому, в случае какого-либо фэйла вы всегда можете взять исходный конфиг, вернуть на место, рестартануть сервис, и, скорей всего, он поднимется.

К примеру так:

cp /root/etc_backup_before_tuning/mysql/my.cnf   /etc/mysql/my.cnf

Именно в таком виде, только проблемный конфиг,  ни в коем случае НЕ  обратным откатом всех файлов!

Другой вариант:

cp /etc/mysql/my.cnf  /etc/mysql/my.cnf_orig

И откат:

cp /etc/mysql/my.cnf_orig /etc/mysql/my.cnf

Почему надо делать именно так, а не просто разбираться с ошибкой? Чтобы как можно быстрей вернуть сайты в работу, очевидно.   Вот после отката, можно уже спокойно разбираться с проблемой и выяснять что это было.

Как решать проблемы?

Всего одно слово.  Л-О-Г-И. Нужно смотреть логи.  Это относится к любому софту и к любым проблемам.  Там есть всё. Даже в тех редких случаях, когда там ничего нет, скорей всего просто не там смотрите 🙂  Логи нужно читать внимательно. Ошибки там обычно видно. Любая ошибка в 98% случаев гуглится и решается.  Другой вопрос насколько это может быть легко и быстро.  Я вот показывал скрины о фейле при рестарте mysql. Это реальная ситуация, я пишу эту статью, и для того чтобы всё это показать вам на практике — я делаю оптимизацию mysql на сервере, где работает вот этот сайт.  Итак, допустим, у меня не запустился mysql. Я иду читать лог. В ubuntu у меня  лог mysql где-то в /var/log/mysql/error.log. Он может быть и чуть в другом месте, но чаще всего именно в /var/log/

Открываю лог, и вижу, что mysql не может запуститься, потому что не хватает памяти под пул innodb. Я задал его в 360 мегабайт, ибо в рекомендациях мне показывало что данные сейчас имеют объем в 340. По-хорошему, нужно бы делать мегабайт 512, но у меня на этом vps всего 1gb памяти, поэтому я сделал 360, с минимальным запасом.   И то, я получил ошибку при рестарте, что все равно не хватает.  Я иду и уменьшаю до 256, тогда все запускается.  Но 256 это не оптимальное значение. Я знаю, что у меня большая часть памяти занята обработкой php, и он просто берет памяти обычно больше чем надо. Если я его рестартану, то часть памяти он высвободит, и скорей всего mysql запустится сразу после этого нормально даже с пулом в 360 мегабайт. Так и происходит 🙂 А хватит ли потом памяти для PHP, резонный вопрос?)  Я думаю хватит, ядро линукс очень хитрая и мощная штука, оно разрулит.

Кроме этого, я запустил mysqltuner еще раз, и увидел такую картину, на которой я сразу же нарисую решение:

Нужно обращать внимание на сообщение:

*** MySQL's maximum memory usage is dangerously high ***
*** Add RAM before increasing MySQL buffer variables ***

Особенно если памяти на сервере мало. Мало — это 1-2 гб. Если у вас там 8 и более, то иногда бывает небходимо задрать настройки mysql  такб что оно будет выдавать этот алерт, но при большом количестве памяти на него можно забивать. Чем больше памяти — тем меньше вероятности что её не хватит, даже если вы там выделили для буферов mysql в 2-3 раза больше чем её есть в системе.  Но в моём случае это обязательно нужно решить, если я не хочу  чтобы у меня начал падать mysql. Тут он почти со 100% вероятностью будет падать, если этого не сделать.  Самое простое  решение  уменьшить максимально разрешенный объем — уменьшить количество возможных одновременных подключений — max_connections. По-умолчанию оно может быть слишком велико, и пропорционально этому растет разрешенный объем памяти. 151 — это обычно и есть значение по умолчанию. А тюнер показывает мне, что используется всего 2.  Я уменьшаю до 50, думаю это с большим запасом, но при этом практически в 2-3 раза сократится максимальный объем выделенной памяти.   Так и вышло.

После этого я сделал еще 2-3 итерации с изменением параметров и запуском mysqltuner. И только тогда у меня показало то, что выше там есть как пример близкой к идеалу настройки.   Но то было как раз  при снятии статистики на «холодную», пока буферы и кэши еще не заполнились.  Через полчаса работы mysql без рестартов это выглядит так:

Фуххх…

Это почти всё было  о бэкенде, о том, что влияет на время ответа сервера.  Эти все вещи подходят для абсолютно любых сайтов, хоть статейных-информационных, хоть для сервисов, хоть для интернет-магазинов.   Далее речь пойдёт только о том, что можно использовать только для простых сайтов — статейников, информационных и дорвеев, конечно.  Причем, на любых CMS и доргенах 🙂

Кэширование Nginx — 100% решение проблем с любой нагрузкой и временем отклика

Но это не точно, не 100%.  Обычно… на 1000% и более.   Можно вообще всё вышеописанное пустить побоку и ничего не делать — включить одно лишь только кэширование в nginx, причем можно только для самых нагруженных сайтов. И это мало того что ускорит время отклика чуть ли не в 10 и более раз, но еще и снимет 80% нагрузки с сервера, если таковая имеется.

Всё довольно просто:

Этот «шедевр изобразительного искусства» я рисовал для другой статьи об ускорении сайтов.   Механика такова, что nginx очень быстро обрабатывает входящие запросы. Просто неебически неимоверно быстро!  Он способен отдать любую страницу из своего кэша за 0,1-0,2 секунды (100-200 ms) .  А если еще и железо быстрое — то он это может и за 0,06 сек. делать.  Как-то так:

Как то поспорили мы со Спартанцем, широко известным в узких кругах человеком, который разрабатывает всякий разный софт для нужд дорвейщиков.  Речь была о его плагине для wordpress  c лаконичным названием d.  Плагин интересный, позволяет неплохо разогнать wordpress, отключить кучу функционала, который может быть «лишним». Но он не решает одной очевидной проблемы — он не может работать без бэкенда.  Ему в любом случае необходим PHP, а значит apache, а значит всё так же подвержен тормозам при сверхнагрузках.

В общем, так или иначе доспорились мы с ним до того что стали меряться письками  выяснять чьё кунг-фу круче — его плагин или кэширование nginx, которое настраиваю я.  И произвели тесты.  Вот замеры с тех тестов, там использовался дефолтный wordpress  с несколькими страницами:

632 ms   — это нормальное время отклика для дефолтного wordpress.   Иногда можно разогнать до 300, но в среднем 0,5-1 сек.

Кэширование nginx ускорило его вот так:

Так на реальных сайтах бывает очень редко,  ибо тут может быть ограничено еще и медленным железом, дисками например (как проверить скорость дисков на сервере?)

Итак, кэширование nginx для wordpress реализуется примерно таким конфигом:

set $no_cache 0; if ($request_method = POST) { set $no_cache 1; } if ($query_string != "") { set $no_cache 1; } if ($request_uri ~* "/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|sitemap(_index)?.xml") { set $no_cache 1; } if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") { set $no_cache 1; } fastcgi_cache one; fastcgi_cache_min_uses 1; fastcgi_cache_valid 200 301 302 304 1h; fastcgi_cache_key "$request_method|$host|$request_uri"; fastcgi_cache_bypass $no_cache; fastcgi_no_cache $no_cache; fastcgi_ignore_headers "Cache-Control" "Expires" "Set-Cookie";

Самый важный параметр, который надо понимать в этом конфиге — это fastcgi_cache_valid. Он задает срок жизни кэша. Тут указан 1 час. Это означает, что все изменения на сайте будут появляться не позднее, чем через час после того как они сделаны. От срока жизни зависит эффективность работы кэширования. Очевидно — что чем меньше срок жизни, тем чаще будут запросы на бэкенд поступать, тем больше нагрузка и чаще будут отдаваться страницы не из кэша, а значит время отклика в среднем дольше. Но для очень часто обновляемых сайтов по-другому никак — например новостники, там бывает нужно обновлять контент каждые 10 минут. Соответственно это значение и нужно менять на 10m. Если же у вас сайт чуть ли не статический, например дорвей — то можно ставить срок жизни хоть месяц — работать со временем будет только лучше. С другой стороны, чем больше посещаемость ресурса — тем эффективней кэширование даже при малом сроке жизни. Т.е. представьте себе на очень посещаемом сайте 100 запросов в минуту с откликом по 1 секунде. Это очень пригружает сервер. Если же вы кэшируете хотя бы на 10 минут — то в течение этих 10 минут 1000 гипотетических запросов практически не создадут никакой нагрузки на apache и mysql, кроме первого запроса, т.н. «холодного старта» — пока страница еще не в кэше.

Здесь кэширование для связки nginx+php-fpm. Для apache соответственно fastcgi_ нужно изменить на proxy_
Это нужно включить в конфигурацию сайта. Можно и просто вписать, а можно добавить в отдельный файл, и включить в нужный сайт с помощью include, как я обычно делаю сам и рекомендую делать. Это нужно включать до каких либо location в конфиге.  Примерно так:

Кроме этого, нужно описать сам кэш в /etc/nginx/nginx.conf такой директивой:

fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=one:10m max_size=1024m inactive=1h;


Это нужно добавить в блок http. И снова надо помнить, что для apache директива должна быть proxy_cache_path. Это все что касается настройки.
Как проверить что кэширование работает? Очевидно по времени отклика. Если все работает — сайт будет летать. Но есть и другие способы.
Можно добавить директиву:

add_header X-Cache $upstream_cache_status;


Как обычно, после любых изменений конфигов нужно делать /etc/init.d/nginx restart

У вас в заголовках ответа после этого должен появиться статус кэширования, который может принимать три основных значения. MISS, HIT, BYPASS:

Статус HIT — означает что страница выдана из кэша. Время отклика будет у нее максимально быстрым. Противоположный статус — MISS, означает, что это «холодный старт» и страницы еще нету в кэше. После обновления этой страницы он должен смениться на HIT. Если не меняется — значит что-то либо не так делаете, либо вам этот конфиг не подходит. Такое тоже бывает, что нужна отладка, менять какие-то директивы, ибо какие-то другие настройки вебсервера могут мешать работе кэшера.

Статус BYPASS — это значит страница не кэшируется в принципе. Потому что её кэшировать нельзя, и для неё задано соответствующее исключение. Например админка, комментатор, post-запросы, поисковые запросы по сайту. Это всё описано в конфигурации, в подробности вдаваться не буду. Всё очень подробно документировано на официальном сайте.

И ещё один способ — можно посмотреть файлы в папке кэша.

Эта команда означает «найти только файлы в папке /var/cache/nginx/ и подсчитать их количество». Если количество не 0 — значит как минимум что-то уже работает 🙂

Этот способ ускорения и защиты от атак используется у известного всем сервиса cloudflare. Есть так же менее популярные решения типа айри.рф —  однако странно, что у них в зависимости от тарифа меняется некий коэффициент ускорения 🙂  Впрочем, мне доподлинно неизвестно какие технологии используют они, но подозреваю,  что всё то же самое, что я тут и описал, плюс CDN.  Но в CDN обычно нет необходимости, если всё это настроено.  Они предлагают оптимизировать даже интернет-магазины, а я утверждаю что кэширование Nginx плохо подходит для интернет-магазинов.  Но  и остальных возможностей бывает достаточно для оптимизации и сокращения времени ответа сайта.

Очистка кэша Nginx

Иногда бывает и такая необходимость. Например при смене дизайна, и необходимости сразу же увидеть изменения. Тут можно использовать тот же самый метод с удалением только файлов, чтобы nginx’y не пришлось заново создавать структуру папок в кэше.

find /var/cache/nginx/ -type f -delete


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

find /var/cache/nginx/ -type f |xargs grep site.com|xargs rm -f


Вместо site.com нужно указать свой домен, конечно.

Вот теперь, пожалуй, всё… что мне известно на данный момент об оптимизации серверов в максимально сжатой форме 😀

Разумеется, всё я это писал, прежде всего,  не по доброте душевной.  А в расчёте  на то, что кому-то понадобится  просто заказать оптимизацию сервера под нагрузку или сократить время ответа сервера 🙂   Но гайд полностью рабочий, если есть время и желание, разумеется любой может по нему настроить свой сервер.  Рождал я его чуть ли не неделю. Ну как, неделю. Непрерывного времени я думаю потратил часов 8-10.  Пост претерпел 39 редакций.

Стоимость и сроки оптимизации сервера

1. Настройка  сайта  в режиме  php-fpm  — 2000 руб.   (для известных CMS. Для самописов  или каких-то малоизвестных CMS может быть дороже — от 3000 руб, ибо требует более сложной настройки и отладки)
2. Настройка кэширования Nginx —  2000 руб.  (Аналогично. Для сервисов и интернет магазинов хотя и возможно (дороже), но крайне не рекомендуется, оно может работать некорректно)
3. Установка и настройка акселератора PHP — opcache, xcache  — 2000 руб.
4. Оптимизация  настроек  mysql  — 2000 руб.
5. Оптимизация настроек  apache,  установка nginx — под нагрузку, или наоборот под меньшее потребление ресурсов — 2000 руб.

На этом собственно исчерпываются потенциальные возможности по тюнингу под сайты. На сервере обычно больше нечего настраивать.  Однако, не всегда есть необходимость настраивать это всё.  Если вы не знаете что именно нужно настроить — я обычно предлагаю предварительный аудит сервера. В рамках которого я могу исследовать настройки, протестировать время отклика сайтов, выявить узкие места и определить возможности для оптимизации. После чего всю инфу выдаю в виде отчёта — что, где, и почему тормозит, и как это можно улучшить и ускорить.   Такой аудит стоит 2000 руб, в том случае, если больше никаких работ не требуется, или вы будете заказывать их не у меня.  В случае, если вам нужен только аудит — он будет стоить 4000 руб.

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

Комплексная оптимизация сервера стоит  5000 рублей.   В неё входит настройка — nginx, apache, mysql и акселератора PHP. И это обычно гораздо выгоднее, чем брать отдельными опциями из прайса выше.

Сюда не включено кэширование Nginx, ибо оно идёт отдельной опцией, и стоимость его неизменна. При необходимости оно просто добавляется к стоимости комплекса работ.

Также и перевод на php-fpm обсуждается отдельно. Может быть включено в стоимость комплексной оптимизации только если у вас сайт на wordpress.

На любые работы я даю гарантию. Это означает, что в течение некоторого времени любые возникающие проблемы я решаю по возможности незамедлительно, а также консультирую по любым вопросам  в настройке сервера.   Если сделанная по результатам моего аудита оптимизация не дает никакого эффекта —  я не требую оплату.  ( Надо понимать, что сюда не отностится оптимизация, заказанная сразу — просто потому что вы решили что-то оптимизировать.  Разумеется я всегда предупреждаю что даст эффект, а что не даст. Но если вы всё равно хотите просто сделать оптимизацию — тут уже только ваши желания, и их исполнение должно быть оплачено в полной мере )

Кроме этого, также напомню, что я здесь не ускоряю сайт на 100 баллов по Google Pagespeed. Я ускоряю ответ сервера. А как оно повлияет (или не повлияет) на оценку гугла — это уже другой вопрос.

Оплату я принимаю исключительно после выполнения работ.  Разумеется, цены даны на текущий момент, и за мной остаётся право в любое время  их изменить.

Срок выполнения работ — примерно  2-3 часа, с момента, как я приступил к задаче. То есть всё будет готово обычно в тот же день. Но  последнее время всё реже бывает что я могу приступить сразу же, ибо бывает очередь из заказов.  Тогда я говорю день, в который я смогу заняться вашими задачами.

Ну вот, с коммерческой частью тоже вроде всё.

Вопросы и консультации  — в комментах. Или по контактам.  Желаю вам быстрых сайтов  и не «греющихся» серверов!

Как уменьшить время ответа сервера в WordPress (27 советов)

Время ответа сервера — это время, которое требуется браузеру посетителя для получения ответа от сервера вашего хостера.

Вот 27 способов уменьшить время отклика сервера.

Позиции с № 1 по № 10 загружаются менее чем за 2,3 секунды

В 2016 году SEO-мастер Брайан Дин проанализировал более 1 млн результатов поиска, чтобы выяснить, какие факторы приводят к тому, что страница занимает первое место в Google.

Брайан обнаружил, что веб-страницы, занимающие первые и вторые места в Google, имеют среднее время загрузки 2 секунды или меньше.

SEO — это настолько сложная тема, что кажется почти абсурдным, что такая простая вещь, как ускорение работы вашего сайта, может помочь вам достичь первой страницы результатов поиска.

Доказательства совершенно очевидны: ваши шансы попасть на страницу №1 Google резко возрастают , если вы сможете заставить свой сайт загружаться за 2 секунды или меньше.

И оказывается, что это не так уж и сложно.

Мне удалось сократить время загрузки моего сайта до 1,7 секунды, по данным Pingdom:

Как я это сделал?

Именно это я и собираюсь показать вам в этой статье: 27 способов уменьшить время отклика сервера в WordPress.

Но сначала, что такое время отклика сервера?

Как его проверить?

А что такое хорошее время отклика сервера?

Что такое время отклика сервера?

Время ответа сервера (SRT) — это время, которое проходит с момента запроса веб-браузером данных с сервера до момента ответа сервера на этот запрос.

Также упоминается как Time To First Byte (TTFB).

В тесте Google Page Speed Insights, показанном ниже, Google сообщил о времени отклика сервера как об одной из возможностей улучшения производительности данного конкретного сайта:

Как проверить время отклика сервера?

Лучший способ проверить время отклика вашего сервера — это Page Speed Insights от Google.

Если время отклика вашего сервера медленное, Google внесет его в список «Возможности» (для ускорения времени загрузки).

Вот два других инструмента для измерения времени отклика сервера:

Что такое показатель PSI Google?

Google создал тест Page Speed Insights в 2018 году, вскоре после объявления «Google Speed Update» в июле того же года.

В отличие от Pingdom и GT Metrix, тест Google PSI не измеряет время загрузки напрямую.

Выставляет оценку вашему сайту, основываясь на ряде факторов, влияющих на удобство работы с мобильными устройствами:

• От 90 до 100 — «Быстрый»
• От 50 до 89 — «Средний»
• От 0 до 49 — «Медленный»

Если вы получили оценку 90 или выше, индикатор PSI становится зеленым.

Читая между строк, кажется вероятным, что Google хочет, чтобы все сайты имели показатель PSI 90 или выше.

Как получить оценку 90+ в PSI Google?

Есть пять ключевых улучшений, которые вы можете сделать, чтобы ваш сайт получил оценку PSI 90+:

• Оптимизация изображений
• Минимизация CSS и JavaScript
• Используйте CDN (сеть доставки контента) для доставки таких вещей, как изображения и PDF.
• Устранение блокировки рендеринга ресурсов
• Включение GZIP-сжатия на вашем сервере

Потребность в скорости

Так что же заставляет уделять особое внимание скорости веб-сайта?

Как вы, возможно, знаете, мобильные устройства обгоняют настольные компьютеры.

В 2017 году впервые мобильные устройства превзошли настольные: 50,3% всего просмотра Интернета приходится на мобильные устройства.

Этот процент увеличился в 2018 году до 52,2%. И процент мобильного интернет-серфинга будет продолжать расти.

Но вот в чем проблема:

Настольные браузеры обычно подключены к высокоскоростному Интернету. Но большинство мобильных пользователей используют гораздо более медленные соединения (3G и 4G).

Если Google и другие поисковые системы намерены удовлетворить растущий спрос со стороны мобильных пользователей, им необходимо, чтобы веб-сайты предлагали более быстрое время отклика.

Именно здесь на помощь приходит Google Page Speed Insights.

Можно предположить, что сайты, не имеющие показатель PSI 90+, будут иметь проблемы с ранжированием на первой странице Google.

Итак, теперь, когда вы понимаете, почему скорость стала таким важным вопросом, давайте рассмотрим способы сделать ваш сайт быстрее.

27 способов уменьшить время отклика сервера в WordPress

#1 — Обновите версию PHP

В декабре 2015 года был выпущен PHP 7. Для примера, PHP 7 примерно в 3 раза быстрее, чем PHP 5.6.

Если вы не используете PHP 7, вы должны немедленно обновить .

После активации плагина перейдите в раздел ‘At a Glance’ вашей приборной панели WP и вы увидите вашу версию PHP:

Это плагин, который нужно использовать только один раз.

Как только вы проверили свою версию PHP, деактивируйте плагин и удалите его.

Если окажется, что ваш сайт не использует PHP 7, свяжитесь с вашим хостером и попросите его включить PHP 7.

#2 — Проверьте, используете ли вы HTTP/2

HTTP/2 — это новый сетевой протокол, представленный в 2015 году. Это может сделать ваш сайт на 10-15% быстрее.

Используйте этот инструмент, чтобы проверить, использует ли ваш сайт HTTP/2.

Если ваш сайт уже использует HTTP/2, поздравляем — вы входите в число 27% всех сайтов, использующих HTTP/2 в настоящее время.

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

#3 — Используйте GZIP-сжатие

Еще один способ уменьшить время отклика сервера — применить GZIP-сжатие.

GZIP означает GNU zip. Это формат файла и программное приложение, используемое для сжатия и распаковки файлов. Проще говоря, он уменьшает размер именованных файлов.

Сжатие GZIP делает ваши веб-страницы быстрее, уменьшая размер файла до 90%.

Используйте инструмент сжатия GZIP, чтобы проверить, использует ли ваш сайт GZIP.

Если нет, вы можете включить его на своем сервере (через cPanel) или использовать плагин Check and Enable GZIP Compression.

#4 — Загружайте скрипты позже

Еще один способ уменьшить время отклика сервера — загружать скрипты по мере необходимости.

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

Сценарии, необходимые для продолжения работы на странице, загружаются только тогда, когда пользователь попадает на нее.

Это называется ленивой загрузкой .

Вот пример рекомендации Google PSI использовать Lazy Loading для «отправки изображений за пределы экрана»:

#5 — Используйте серверы имен Cloudflare (бесплатно)

Это еще один простой (и бесплатный) способ уменьшить время отклика сервера. Когда вы меняете свои серверы имен на серверы имен Cloudflare, ваш сайт получаетвоспользоваться преимуществами глобальной сети центров обработки данных Cloudflare.

Cloudflare имеет 165 центров обработки данных по всему миру.

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

Это приводит к значительному ускорению загрузки .

Вот видео, в котором рассказывается о процессе настройки серверов имен Cloudflare:

Примечание: изменение серверов имен на Cloudflare не означает смену веб-хоста — ваш веб-хост остается прежним.

#6 — Используйте сеть доставки контента (CDN)

Еще один отличный способ сократить время отклика сервера — использовать сеть доставки контента или CDN.

CDN — это глобальная сеть серверов, которая доставляет страницы и другой веб-контент пользователю, основываясь на его географическом положении.

Cloudflare является примером CDN.

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

Я использую StackPath в качестве CDN ($10 в месяц).

Он сократил время загрузки моего сайта примерно на 2 секунды, по данным Pingdom.

При использовании CDN вы сможете увидеть в результатах Pingdom, что большая часть вашего контента доставляется CDN (в данном случае StackPath):

#7 — Уменьшение блокировки рендеринга JavaScript

Блокировка рендеринга происходит, когда браузер пытается отобразить страницу и сталкивается со сценарием, который он должен выполнить, прежде чем продолжить загрузку.

Это увеличивает время загрузки вашей страницы.

Решение? Минимизируйте JavaScript.

Большинство плагинов оптимизации производительности имеют опцию «минифицировать JavaScript»:

#8 — Используйте плагин кэширования

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

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

Примерами плагинов кэширования являются:

#9 — Сократите количество внешних скриптов

Когда вашему сайту приходится вызывать внешние скрипты для загрузки страницы, это может значительно замедлить время загрузки.

Старайтесь свести внешние сценарии к минимуму .

Вот несколько примеров внешних сценариев:

• Скрипты видео YouTube
• Блок комментариев Disqus
• Кнопки социального обмена
• Блок живого чата
• Формы опт-ин и всплывающие формы Формы опт-аут. в и всплывающие модули
• Google Fonts

#10 — Установка WP Disable

Платформа WordPress может быть быстро раздута различными «запросами». Эти запросы замедляют время загрузки ваших веб-страниц.

Плагин WP Disable делает ваш сайт быстрее, отключая определенные «запросы», такие как:

• Emoji
• Gravatars
• Embed
• Trackbacks,
• WooCommerce скрипты и CSS
• RSS
• XML-…RPC
• Автоматическое сохранение
• Теги Windows Live Writer
• Теги коротких ссылок
• WP API
• Комментарии
• Контроль сердцебиения

Панель управления позволяет выбрать, какие из этих элементов вы хотите отключить.

#11 — Очистка базы данных

Большинство плагинов для оптимизации производительности имеют функцию очистки базы данных.

В Swift это называется «оптимизацией базы данных».

На следующем снимке экрана показаны элементы базы данных, которые можно исключить для ускорения загрузки:

#12 — Оптимизация изображений

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

Для быстрой загрузки сайта ваши изображения должны быть не более 100 кб.

Используйте Screaming Frog для проверки содержимого вашего сайта. Установите фильтр изображений на «более 100 КБ», чтобы вы могли определить изображения, которые необходимо оптимизировать:

Если у вас много изображений, которые необходимо оптимизировать, рассмотрите возможность использования платной услуги, такой как Kraken.

Всего за несколько долларов в месяц вы можете оптимизировать свои изображения партиями.

И у вас будет лучшая степень сжатия, чем при использовании бесплатных сервисов.

#13 — Обновите свой хостинг

Лучший способ сократить время отклика сервера — просто выбрать хостинг с быстрыми серверами. Все советы и рекомендации, упомянутые в этой статье, будут бесполезны, если ваш веб-хост работает медленно.

Медленный веб-хостинг обычно вызван одним из этих двух факторов (или обоими):

• У вашего хостера недостаточно ресурсов сервера, или
• Ваш хостер размещает слишком много сайтов на одном сервере

Если любое из этих условий применимо к вашему сайту, вы никогда не добьетесь времени загрузки менее 2 секунд.

Как же узнать, какие веб-хостинги являются быстрыми?

Для многих блоггеров, как и для меня, это просто процесс проб и ошибок.

Я начал с HostGator, затем перешел на Bluehost, а теперь я с SiteGround.

Существует несколько сайтов, которые анализируют скорость работы веб-хостов.

Но имейте в виду, что эти сайты часто зарабатывают деньги через партнерские ссылки веб-хостов.

И это сразу ставит под сомнение объективность любого совета, который они дают.

Из личного опыта могу сказать, что SiteGround — самый быстрый хостинг, с которым я работал.

SiteGround показывает хорошие результаты в различных обзорах:

BitCatcha оценивает SiteGround как № 1 из 6 самых быстрых хостингов 2019 года.

Том Депюи отмечает, что SiteGround был признан лучшим веб-хостом 2018 года в группе Facebook ‘WordPress Hosting’.

#14 — Сведите количество плагинов WP к минимуму

Все плагины в той или иной степени замедляют время загрузки вашего сайта. Поэтому старайтесь, чтобы количество ваших плагинов не превышало 20.

Я недавно сократил количество своих плагинов с 40 (. ) до 28 и работаю над их дальнейшим сокращением.

#15 — Выбор правильных плагинов

Еще один хороший способ уменьшить время отклика сервера — устранить требовательные к ресурсам плагины WordPress. Известно, что некоторые плагины замедляют работу вашего сайта больше, чем другие.

Найдите альтернативы этим плагинам (а лучше вообще обойтись без них):

• Akismet
• JetPack
• WordPress Facebook plugin
• Contact Form 7
• The Divi Builder plugin
• Cursor Revolution
• SumoMe
• Любой плагин, который показывает «связанные сообщения» в конце каждой статьи или записи блога
• Essential Grid
• Система комментариев Disqus
• Проверка битых ссылок
• Безопасность Wordfence

#16 -… Убедитесь, что версия WP актуальна

Использование устаревшей версии WordPress сделает ваш сайт медленнее, чем необходимо.

Проверьте, какую версию WP вы используете в панели ‘At a Glance’ в приборной панели WordPress:

#17 — Убедитесь, что ваши плагины WP обновлены

Аналогично, использование устаревших версий ваших плагинов также приведет к тому, что ваш сайт будет загружаться медленнее, чем должен.

Поэтому обязательно обновляйте свои плагины всякий раз, когда видите уведомление об обновлении.

Для этого существует плагин: Easy Updates Manager (именно тогда, когда вы думали, что контролируете свои плагины).

#18 — Загрузите свой фавикон прямо в тему

Еще один способ уменьшить время отклика сервера — загрузить свой фавикон прямо в тему WordPress. Другими словами, не используйте отдельный плагин для загрузки своего favicon.

Вместо этого загрузите свой favicon прямо в тему:

#19 — Используйте плагины оптимизации скорости

Плагины оптимизации скорости сайта обычно делают любое (или все) из следующего в попытке ускорить ваш сайт:

• Оптимизация изображений
• Ленивая загрузка изображений
• Минификация HTML
• Минификация JavaScript
• Кэширование
• Ранняя загрузка
• Удаление мусорного содержимого (ревизии, комментарии, дублирование метаданных и т. д.))
• Удаление просроченных переходных процессов
• Оптимизация шрифтов

Вот некоторые популярные плагины для оптимизации скорости:

#20 — Используйте премиум DNS сервис

Все веб-хостинги предоставляют бесплатный DNS хостинг.

И это, вероятно, то, что вы имеете на данный момент.

Но за несколько долларов в месяц вы можете получить премиум-хостинг DNS.

DNS-хостинг премиум-класса обеспечивает минимальную задержку между поиском DNS и получением первого байта. Это уменьшит время отклика вашего сервера.

#21 — Удаление виджетов из боковой панели/футера вашего сайта

У вас куча виджетов в боковой панели?

Может быть, поисковая строка, форма регистрации, список популярных записей в блоге, список последних записей, список категорий записей в блоге и так далее?

Мой совет: удалите их .

Эти виджеты загружаются вечно, добавляя драгоценные миллисекунды к общему времени загрузки.

И вот в чем дело: боковая панель, как и нижний колонтитул, является элементом всего сайта.

Это означает, что эти виджеты должны быть загружены на каждой странице вашего сайта.

У меня были «блогроллы», которые состояли из последних записей, основных записей и категорий записей. У меня также был виджет «поиск по этому сайту» и форма оптина.

И я избавился от всего, кроме модуля opt-in.

Это сократило время загрузки на 2 секунды.

#22 — Выбор быстрой темы WordPress

За исключением официальной темы WP, бесплатные темы WordPress часто плохо закодированы и поэтому медленно загружаются.

Если вы хотите, чтобы ваш сайт загружался быстро, мой совет — приобретите тему премиум-класса.

ColorLib протестировал более 50 премиум WP тем и составил список самых быстро загружающихся WP тем.

Я был счастлив увидеть, что моя тема (MagazinePro) является одной из них!

#23 — Оптимизация домашней страницы для быстрой загрузки

Вы можете оптимизировать свою домашнюю страницу для быстрой загрузки:

• Показывать выдержки вместо полных сообщений
• Уменьшить количество сообщений блога на главной странице
• Выбрать меньший размер для основных изображений

Как видно из скриншотов ниже, мне, вероятно, следует выбрать меньший размер для основных изображений:

#24 — Используйте домены без cookies

Домен без cookies — это домен, который не обслуживает cookies.

Cookies — это небольшие пакеты информации, которые передаются между вашим сайтом и браузером посетителя.

Хотя файлы cookie являются ценным способом отслеживания производительности вашего сайта, большая часть вашего контента не нуждается в подключении файлов cookie.

Это содержимое может быть передано вашим посетителям с другого домена, домена без cookies. И это еще один способ ускорить время загрузки ваших сайтов.

#25 — Добавление заголовков Expires

Заголовки Expires — это часть кода, которая сообщает браузеру посетителя, должен ли он загрузить файл или просто перезагрузить его из своего кэша.

Если ваш посетитель уже был на вашем сайте, у него уже есть некоторые файлы, хранящиеся в его кэше.

Идея ‘expires headers’ заключается в том, что нет необходимости загружать файлы, которые браузер вашего посетителя уже загрузил в последний раз, когда он был на вашем сайте.

Заголовки ‘Expires’ экономят время и делают ваши веб-страницы быстрее.

Чтобы добавить ‘expires headers’ на свои веб-страницы, достаточно вставить около 15 строк кода в файл . htaccess.

Если вы предпочитаете использовать плагин, Far Future Expiry Header вставит код заголовка expires за вас.

#26 — Откладывание неиспользуемого CSS

В тесте Google Page Insights вы можете увидеть рекомендацию «отложить неиспользуемый CSS».

Неиспользуемый CSS загромождает страницы и делает их медленнее.

Вы можете удалить неиспользуемый CSS вручную, следуя инструкциям в этой статье.

Или вы можете использовать плагин Asset CleanUp: Page Speed Booster. Этот плагин очищает ваш код, создавая веб-страницы, которые загружаются быстрее.

#27 — Используйте ускоренные мобильные страницы (AMP)

Ускоренные мобильные страницы или AMP — это спонсируемый Google формат, который позволяет веб-страницам быстро загружаться на мобильных устройствах.

Когда вы включаете AMP на своем сайте, ваши страницы отмечаются в результатах поиска Google как быстрые, с небольшим значком молнии:

Одна из причин быстрой загрузки страниц AMP заключается в том, что они находятся на сервере Google, а не на вашем.

В статье под названием: Google AMP производит 600% увеличение скорости загрузки страниц мобильных сайтов, Кристин Чун сообщает, что использование Google AMP увеличило время загрузки веб-страницы с 6 секунд до 1 секунды.

Итак, простой акт включения AMP на вашем сайте WordPress может значительно увеличить скорость работы ваших страниц.

Как включить AMP?

Скачайте и установите официальный плагин AMP для WordPress (не другой плагин!)

Когда плагин включен, на экране редактирования записей вашего блога появится сообщение «AMP: Включено»:

Заключение

Люди, которые смогли довести время загрузки своего сайта до менее 2 секунд и показатель Google PSI выше 60, в настоящее время наблюдают огромный рост своего органического трафика в Google (включая этого автора).

Итак, потратьте время на реализацию некоторых из этих стратегий и сократите время отклика вашего сервера — оно того стоит!

Из перечисленных выше стратегий, вот те, которые дадут вам наибольшую отдачу:

• Использование сети доставки контента (CDN)
• Использование премиум DNS серверов
• Установка и активация плагина кэширования
• Удаление плагинов WordPress (target aмаксимум 20 плагинов)
• Удалите большинство виджетов из боковой панели вашего сайта
• Установите и активируйте плагин оптимизации скорости, например Swift
• Обновите ваш хостинг на более быстрый тарифный план или более быстрый хост

Поскольку мир переходит от настольных компьютеров к мобильным, время отклика сервера становится критическим фактором ранжирования .

Настанет время, когда только сайты, способные молниеносно доставлять контент мобильным пользователям, будут занимать первое место на странице Google.

Поэтому опережайте события и старайтесь, чтобы время отклика вашего сервера было менее 2 секунд .

Как уменьшить время отклика сервера в WordPress

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

Во-первых, вы знаете, что одним из многих преимуществ быстрого и отзывчивого сайта на WordPress является способность продвигать все больше конверсий; то есть, если у вас есть магазин электронной коммерции в WordPress. Более быстрый и отзывчивый веб-сайт также будет означать, что поисковые системы на вашей стороне, когда дело доходит до ранжирования и рекомендаций.

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

• Время отклика под секунду — это потрясающе
• Время отклика в две секунды тоже велико
• Время отклика, которое занимает более 4 или 5 секунд, является плохим

Теперь, если вы готовы воспользоваться преимуществами более быстрого сайта WordPress, мы дадим вам секретный рецепт.

Выбор управляемого хостинга

Хостинг является одним из основных аспектов, о которых вам нужно подумать в своем стремлении к более быстрому веб-сайту. Это один из первых компонентов, когда вы хотите сократить время отклика сервера в WordPress. Зачем? Потому что хорошая хостинговая платформа позволит ускорить передачу данных между серверами.

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

Конечно, более дешевые общие хостинги в порядке, когда вы только начинаете, но в наши дни управляемые хостинговые платформы лучше, когда дело доходит до новичков и являются предпочтительными.

Знаете ли вы, что, согласно недавнему опросу, управляемые услуги хостинга помогли ускорить веб-сайты WordPress до 60%? Почему бы не воспользоваться этим и не начать с самого начала? Кроме того, все, что управляется на заднем конце, вам не придется беспокоиться о времени простоя, поскольку, как известно, управляемые услуги хостинга увеличивают время отклика сервера до 70% в большинстве случаев.

Выберите правильные плагины

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

Как правило, вы должны уменьшить или удалить установленные вами плагины, которые не используются, или те, которые не будут влиять на функциональность веб-сайта.

Знаете ли вы, что многие плагины поступают из непризнанных источников, а разработчики ничего не делают, кроме спама на вашем сайте? Результатом этого является медленный сайт и практически ничего не будет делать, если вы хотите уменьшить время отклика сервера в WordPress. Эмпирическое правило включает в себя более не 15 плагинов на вашем сайте WordPress.

Если на вашем веб-сайте WordPress установлено более 15 плагинов, у вас есть несколько вариантов.

Вы можете либо обновить те, которые вам действительно нужны, либо найти лучшие заменители. Если вы обновите те, которые вам нужны, они не только помогут сократить время отклика сервера, но и повысить безопасность и стабильность.

Посмотрите лучшие плагины WordPress прямо здесь!

Выберите лучшую тему

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

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

Выберите тему, которая исходит от признанного источника или дизайнера, и это премиум. Прочитайте комментарии и обзоры перед покупкой, чтобы вы знали, куда вы тратите свои деньги. После того как вы купили тему, замените ее как можно скорее, чтобы ваш сайт был оптимизирован и быстр.  Если, однако, вы не можете найти тему по своему вкусу, лучше и безопаснее использовать тему, которая встроена в WordPress.

Мы понимаем, что ей не хватает форм, но мы заверяем вас, что у него нет недостатка в функциональности. Это действительно помогло бы уменьшить время отклика сервера в WordPress.

Включить и использовать кеширование

Обычная процедура, если вы хотите уменьшить время отклика сервера в WordPress. Некоторые говорят, что это легче сказать, чем сделать, поэтому мы объясним, в нескольких словах. Как только пользователь запрашивает сервер для показа страницы, серверу необходимо вытащить ресурсы, такие как изображения, темы, плагины и многое другое с другого сервера.

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

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

Конечно, это может означать просмотр страницы, которая не является свежей, но обычно это делается, чтобы быстрее ускорить загрузку сайта WordPress, что способствует конверсии и лояльности к бренду. Жизненно важным аспектом кэширования является то, что вы можете включить его в любом месте сайта по своему вкусу. Тем не менее, лучше включить кэширование через Apache или NGINX, которые немного сложны, но хорошо выполняют работу.

Выкиньте мусор

Теперь это может показаться странным, но нужно время от времени выкидывать мусор. Это удаление файлов, плагинов, тем и других ресурсов, которые вам больше не нужны.  Они являются настоящими преступниками, если вы хотите сократить время отклика сервера в WordPress.

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

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

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

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

У вас есть больше предложений? Отлично.  Мы хотели бы услышать от вас в разделе комментариев ниже.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Как сократить время ответа сервера wordpress

Как уменьшить время ответа сервера в WordPress (27 советов)

Время ответа сервера — это время, которое требуется браузеру посетителя для получения ответа от сервера вашего хостера.

Вот 27 способов уменьшить время отклика сервера.

Позиции с № 1 по № 10 загружаются менее чем за 2,3 секунды

В 2016 году SEO-мастер Брайан Дин проанализировал более 1 млн результатов поиска, чтобы выяснить, какие факторы приводят к тому, что страница занимает первое место в Google.

Брайан обнаружил, что веб-страницы, занимающие первые и вторые места в Google, имеют среднее время загрузки 2 секунды или меньше.

SEO — это настолько сложная тема, что кажется почти абсурдным, что такая простая вещь, как ускорение работы вашего сайта, может помочь вам достичь первой страницы результатов поиска.

Доказательства совершенно очевидны: ваши шансы попасть на страницу №1 Google резко возрастают , если вы сможете заставить свой сайт загружаться за 2 секунды или меньше.

И оказывается, что это не так уж и сложно.

Мне удалось сократить время загрузки моего сайта до 1,7 секунды, по данным Pingdom:

Как я это сделал?

Именно это я и собираюсь показать вам в этой статье: 27 способов уменьшить время отклика сервера в WordPress.

Но сначала, что такое время отклика сервера?

Как его проверить?

А что такое хорошее время отклика сервера?

Что такое время отклика сервера?

Время ответа сервера (SRT) — это время, которое проходит с момента запроса веб-браузером данных с сервера до момента ответа сервера на этот запрос.

Также упоминается как Time To First Byte (TTFB).

В тесте Google Page Speed Insights, показанном ниже, Google сообщил о времени отклика сервера как об одной из возможностей улучшения производительности данного конкретного сайта:

Как проверить время отклика сервера?

Лучший способ проверить время отклика вашего сервера — это Page Speed Insights от Google.

Если время отклика вашего сервера медленное, Google внесет его в список «Возможности» (для ускорения времени загрузки).

Вот два других инструмента для измерения времени отклика сервера:

Что такое показатель PSI Google?

Google создал тест Page Speed Insights в 2018 году, вскоре после объявления «Google Speed Update» в июле того же года.

В отличие от Pingdom и GT Metrix, тест Google PSI не измеряет время загрузки напрямую.

Выставляет оценку вашему сайту, основываясь на ряде факторов, влияющих на удобство работы с мобильными устройствами:

• От 90 до 100 — «Быстрый»
• От 50 до 89 — «Средний»
• От 0 до 49 — «Медленный»

Если вы получили оценку 90 или выше, индикатор PSI становится зеленым.

Читая между строк, кажется вероятным, что Google хочет, чтобы все сайты имели показатель PSI 90 или выше.

Как получить оценку 90+ в PSI Google?

Есть пять ключевых улучшений, которые вы можете сделать, чтобы ваш сайт получил оценку PSI 90+:

• Оптимизация изображений
• Минимизация CSS и JavaScript
• Используйте CDN (сеть доставки контента) для доставки таких вещей, как изображения и PDF.
• Устранение блокировки рендеринга ресурсов
• Включение GZIP-сжатия на вашем сервере

Потребность в скорости

Так что же заставляет уделять особое внимание скорости веб-сайта?

Как вы, возможно, знаете, мобильные устройства обгоняют настольные компьютеры.

В 2017 году впервые мобильные устройства превзошли настольные: 50,3% всего просмотра Интернета приходится на мобильные устройства.

Этот процент увеличился в 2018 году до 52,2%. И процент мобильного интернет-серфинга будет продолжать расти.

Но вот в чем проблема:

Настольные браузеры обычно подключены к высокоскоростному Интернету. Но большинство мобильных пользователей используют гораздо более медленные соединения (3G и 4G).

Если Google и другие поисковые системы намерены удовлетворить растущий спрос со стороны мобильных пользователей, им необходимо, чтобы веб-сайты предлагали более быстрое время отклика.

Именно здесь на помощь приходит Google Page Speed Insights.

Можно предположить, что сайты, не имеющие показатель PSI 90+, будут иметь проблемы с ранжированием на первой странице Google.

Итак, теперь, когда вы понимаете, почему скорость стала таким важным вопросом, давайте рассмотрим способы сделать ваш сайт быстрее.

27 способов уменьшить время отклика сервера в WordPress

#1 — Обновите версию PHP

В декабре 2015 года был выпущен PHP 7. Для примера, PHP 7 примерно в 3 раза быстрее, чем PHP 5.6.

Если вы не используете PHP 7, вы должны немедленно обновить .

После активации плагина перейдите в раздел ‘At a Glance’ вашей приборной панели WP и вы увидите вашу версию PHP:

Это плагин, который нужно использовать только один раз.

Как только вы проверили свою версию PHP, деактивируйте плагин и удалите его.

Если окажется, что ваш сайт не использует PHP 7, свяжитесь с вашим хостером и попросите его включить PHP 7.

#2 — Проверьте, используете ли вы HTTP/2

HTTP/2 — это новый сетевой протокол, представленный в 2015 году. Это может сделать ваш сайт на 10-15% быстрее.

Используйте этот инструмент, чтобы проверить, использует ли ваш сайт HTTP/2.

Если ваш сайт уже использует HTTP/2, поздравляем — вы входите в число 27% всех сайтов, использующих HTTP/2 в настоящее время.

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

#3 — Используйте GZIP-сжатие

Еще один способ уменьшить время отклика сервера — применить GZIP-сжатие.

GZIP означает GNU zip. Это формат файла и программное приложение, используемое для сжатия и распаковки файлов. Проще говоря, он уменьшает размер именованных файлов.

Сжатие GZIP делает ваши веб-страницы быстрее, уменьшая размер файла до 90%.

Используйте инструмент сжатия GZIP, чтобы проверить, использует ли ваш сайт GZIP.

Если нет, вы можете включить его на своем сервере (через cPanel) или использовать плагин Check and Enable GZIP Compression.

#4 — Загружайте скрипты позже

Еще один способ уменьшить время отклика сервера — загружать скрипты по мере необходимости.

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

Сценарии, необходимые для продолжения работы на странице, загружаются только тогда, когда пользователь попадает на нее.

Это называется ленивой загрузкой .

Вот пример рекомендации Google PSI использовать Lazy Loading для «отправки изображений за пределы экрана»:

#5 — Используйте серверы имен Cloudflare (бесплатно)

Это еще один простой (и бесплатный) способ уменьшить время отклика сервера. Когда вы меняете свои серверы имен на серверы имен Cloudflare, ваш сайт получаетвоспользоваться преимуществами глобальной сети центров обработки данных Cloudflare.

Cloudflare имеет 165 центров обработки данных по всему миру.

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

Это приводит к значительному ускорению загрузки .

Вот видео, в котором рассказывается о процессе настройки серверов имен Cloudflare:

Примечание: изменение серверов имен на Cloudflare не означает смену веб-хоста — ваш веб-хост остается прежним.

#6 — Используйте сеть доставки контента (CDN)

Еще один отличный способ сократить время отклика сервера — использовать сеть доставки контента или CDN.

CDN — это глобальная сеть серверов, которая доставляет страницы и другой веб-контент пользователю, основываясь на его географическом положении.

Cloudflare является примером CDN.

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

Я использую StackPath в качестве CDN ($10 в месяц).

Он сократил время загрузки моего сайта примерно на 2 секунды, по данным Pingdom.

При использовании CDN вы сможете увидеть в результатах Pingdom, что большая часть вашего контента доставляется CDN (в данном случае StackPath):

#7 — Уменьшение блокировки рендеринга JavaScript

Блокировка рендеринга происходит, когда браузер пытается отобразить страницу и сталкивается со сценарием, который он должен выполнить, прежде чем продолжить загрузку.

Это увеличивает время загрузки вашей страницы.

Решение? Минимизируйте JavaScript.

Большинство плагинов оптимизации производительности имеют опцию «минифицировать JavaScript»:

#8 — Используйте плагин кэширования

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

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

Примерами плагинов кэширования являются:

#9 — Сократите количество внешних скриптов

Когда вашему сайту приходится вызывать внешние скрипты для загрузки страницы, это может значительно замедлить время загрузки.

Старайтесь свести внешние сценарии к минимуму .

Вот несколько примеров внешних сценариев:

• Скрипты видео YouTube
• Блок комментариев Disqus
• Кнопки социального обмена
• Блок живого чата
• Формы опт-ин и всплывающие формы Формы опт-аут.в и всплывающие модули
• Google Fonts

#10 — Установка WP Disable

Платформа WordPress может быть быстро раздута различными «запросами». Эти запросы замедляют время загрузки ваших веб-страниц.

Плагин WP Disable делает ваш сайт быстрее, отключая определенные «запросы», такие как:

• Emoji
• Gravatars
• Embed
• Trackbacks,
• WooCommerce скрипты и CSS
• RSS
• XML-…RPC
• Автоматическое сохранение
• Теги Windows Live Writer
• Теги коротких ссылок
• WP API
• Комментарии
• Контроль сердцебиения

Панель управления позволяет выбрать, какие из этих элементов вы хотите отключить.

#11 — Очистка базы данных

Большинство плагинов для оптимизации производительности имеют функцию очистки базы данных.

В Swift это называется «оптимизацией базы данных».

На следующем снимке экрана показаны элементы базы данных, которые можно исключить для ускорения загрузки:

#12 — Оптимизация изображений

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

Для быстрой загрузки сайта ваши изображения должны быть не более 100 кб.

Используйте Screaming Frog для проверки содержимого вашего сайта. Установите фильтр изображений на «более 100 КБ», чтобы вы могли определить изображения, которые необходимо оптимизировать:

Если у вас много изображений, которые необходимо оптимизировать, рассмотрите возможность использования платной услуги, такой как Kraken.

Всего за несколько долларов в месяц вы можете оптимизировать свои изображения партиями.

И у вас будет лучшая степень сжатия, чем при использовании бесплатных сервисов.

#13 — Обновите свой хостинг

Лучший способ сократить время отклика сервера — просто выбрать хостинг с быстрыми серверами. Все советы и рекомендации, упомянутые в этой статье, будут бесполезны, если ваш веб-хост работает медленно.

Медленный веб-хостинг обычно вызван одним из этих двух факторов (или обоими):

• У вашего хостера недостаточно ресурсов сервера, или
• Ваш хостер размещает слишком много сайтов на одном сервере

Если любое из этих условий применимо к вашему сайту, вы никогда не добьетесь времени загрузки менее 2 секунд.

Как же узнать, какие веб-хостинги являются быстрыми?

Для многих блоггеров, как и для меня, это просто процесс проб и ошибок.

Я начал с HostGator, затем перешел на Bluehost, а теперь я с SiteGround.

Существует несколько сайтов, которые анализируют скорость работы веб-хостов.

Но имейте в виду, что эти сайты часто зарабатывают деньги через партнерские ссылки веб-хостов.

И это сразу ставит под сомнение объективность любого совета, который они дают.

Из личного опыта могу сказать, что SiteGround — самый быстрый хостинг, с которым я работал.

SiteGround показывает хорошие результаты в различных обзорах:

BitCatcha оценивает SiteGround как № 1 из 6 самых быстрых хостингов 2019 года.

Том Депюи отмечает, что SiteGround был признан лучшим веб-хостом 2018 года в группе Facebook ‘WordPress Hosting’.

#14 — Сведите количество плагинов WP к минимуму

Все плагины в той или иной степени замедляют время загрузки вашего сайта. Поэтому старайтесь, чтобы количество ваших плагинов не превышало 20.

Я недавно сократил количество своих плагинов с 40 (. ) до 28 и работаю над их дальнейшим сокращением.

#15 — Выбор правильных плагинов

Еще один хороший способ уменьшить время отклика сервера — устранить требовательные к ресурсам плагины WordPress. Известно, что некоторые плагины замедляют работу вашего сайта больше, чем другие.

Найдите альтернативы этим плагинам (а лучше вообще обойтись без них):

• Akismet
• JetPack
• WordPress Facebook plugin
• Contact Form 7
• The Divi Builder plugin
• Cursor Revolution
• SumoMe
• Любой плагин, который показывает «связанные сообщения» в конце каждой статьи или записи блога
• Essential Grid
• Система комментариев Disqus
• Проверка битых ссылок
• Безопасность Wordfence

#16 -… Убедитесь, что версия WP актуальна

Использование устаревшей версии WordPress сделает ваш сайт медленнее, чем необходимо.

Проверьте, какую версию WP вы используете в панели ‘At a Glance’ в приборной панели WordPress:

#17 — Убедитесь, что ваши плагины WP обновлены

Аналогично, использование устаревших версий ваших плагинов также приведет к тому, что ваш сайт будет загружаться медленнее, чем должен.

Поэтому обязательно обновляйте свои плагины всякий раз, когда видите уведомление об обновлении.

Для этого существует плагин: Easy Updates Manager (именно тогда, когда вы думали, что контролируете свои плагины).

#18 — Загрузите свой фавикон прямо в тему

Еще один способ уменьшить время отклика сервера — загрузить свой фавикон прямо в тему WordPress. Другими словами, не используйте отдельный плагин для загрузки своего favicon.

Вместо этого загрузите свой favicon прямо в тему:

#19 — Используйте плагины оптимизации скорости

Плагины оптимизации скорости сайта обычно делают любое (или все) из следующего в попытке ускорить ваш сайт:

• Оптимизация изображений
• Ленивая загрузка изображений
• Минификация HTML
• Минификация JavaScript
• Кэширование
• Ранняя загрузка
• Удаление мусорного содержимого (ревизии, комментарии, дублирование метаданных и т.д.))
• Удаление просроченных переходных процессов
• Оптимизация шрифтов

Вот некоторые популярные плагины для оптимизации скорости:

#20 — Используйте премиум DNS сервис

Все веб-хостинги предоставляют бесплатный DNS хостинг.

И это, вероятно, то, что вы имеете на данный момент.

Но за несколько долларов в месяц вы можете получить премиум-хостинг DNS.

DNS-хостинг премиум-класса обеспечивает минимальную задержку между поиском DNS и получением первого байта. Это уменьшит время отклика вашего сервера.

#21 — Удаление виджетов из боковой панели/футера вашего сайта

У вас куча виджетов в боковой панели?

Может быть, поисковая строка, форма регистрации, список популярных записей в блоге, список последних записей, список категорий записей в блоге и так далее?

Мой совет: удалите их .

Эти виджеты загружаются вечно, добавляя драгоценные миллисекунды к общему времени загрузки.

И вот в чем дело: боковая панель, как и нижний колонтитул, является элементом всего сайта.

Это означает, что эти виджеты должны быть загружены на каждой странице вашего сайта.

У меня были «блогроллы», которые состояли из последних записей, основных записей и категорий записей. У меня также был виджет «поиск по этому сайту» и форма оптина.

И я избавился от всего, кроме модуля opt-in.

Это сократило время загрузки на 2 секунды.

#22 — Выбор быстрой темы WordPress

За исключением официальной темы WP, бесплатные темы WordPress часто плохо закодированы и поэтому медленно загружаются.

Если вы хотите, чтобы ваш сайт загружался быстро, мой совет — приобретите тему премиум-класса.

ColorLib протестировал более 50 премиум WP тем и составил список самых быстро загружающихся WP тем.

Я был счастлив увидеть, что моя тема (MagazinePro) является одной из них!

#23 — Оптимизация домашней страницы для быстрой загрузки

Вы можете оптимизировать свою домашнюю страницу для быстрой загрузки:

• Показывать выдержки вместо полных сообщений
• Уменьшить количество сообщений блога на главной странице
• Выбрать меньший размер для основных изображений

Как видно из скриншотов ниже, мне, вероятно, следует выбрать меньший размер для основных изображений:

#24 — Используйте домены без cookies

Домен без cookies — это домен, который не обслуживает cookies.

Cookies — это небольшие пакеты информации, которые передаются между вашим сайтом и браузером посетителя.

Хотя файлы cookie являются ценным способом отслеживания производительности вашего сайта, большая часть вашего контента не нуждается в подключении файлов cookie.

Это содержимое может быть передано вашим посетителям с другого домена, домена без cookies. И это еще один способ ускорить время загрузки ваших сайтов.

#25 — Добавление заголовков Expires

Заголовки Expires — это часть кода, которая сообщает браузеру посетителя, должен ли он загрузить файл или просто перезагрузить его из своего кэша.

Если ваш посетитель уже был на вашем сайте, у него уже есть некоторые файлы, хранящиеся в его кэше.

Идея ‘expires headers’ заключается в том, что нет необходимости загружать файлы, которые браузер вашего посетителя уже загрузил в последний раз, когда он был на вашем сайте.

Заголовки ‘Expires’ экономят время и делают ваши веб-страницы быстрее.

Чтобы добавить ‘expires headers’ на свои веб-страницы, достаточно вставить около 15 строк кода в файл .htaccess.

Если вы предпочитаете использовать плагин, Far Future Expiry Header вставит код заголовка expires за вас.

#26 — Откладывание неиспользуемого CSS

В тесте Google Page Insights вы можете увидеть рекомендацию «отложить неиспользуемый CSS».

Неиспользуемый CSS загромождает страницы и делает их медленнее.

Вы можете удалить неиспользуемый CSS вручную, следуя инструкциям в этой статье.

Или вы можете использовать плагин Asset CleanUp: Page Speed Booster. Этот плагин очищает ваш код, создавая веб-страницы, которые загружаются быстрее.

#27 — Используйте ускоренные мобильные страницы (AMP)

Ускоренные мобильные страницы или AMP — это спонсируемый Google формат, который позволяет веб-страницам быстро загружаться на мобильных устройствах.

Когда вы включаете AMP на своем сайте, ваши страницы отмечаются в результатах поиска Google как быстрые, с небольшим значком молнии:

Одна из причин быстрой загрузки страниц AMP заключается в том, что они находятся на сервере Google, а не на вашем.

В статье под названием: Google AMP производит 600% увеличение скорости загрузки страниц мобильных сайтов, Кристин Чун сообщает, что использование Google AMP увеличило время загрузки веб-страницы с 6 секунд до 1 секунды.

Итак, простой акт включения AMP на вашем сайте WordPress может значительно увеличить скорость работы ваших страниц.

Как включить AMP?

Скачайте и установите официальный плагин AMP для WordPress (не другой плагин!)

Когда плагин включен, на экране редактирования записей вашего блога появится сообщение «AMP: Включено»:

Заключение

Люди, которые смогли довести время загрузки своего сайта до менее 2 секунд и показатель Google PSI выше 60, в настоящее время наблюдают огромный рост своего органического трафика в Google (включая этого автора).

Итак, потратьте время на реализацию некоторых из этих стратегий и сократите время отклика вашего сервера — оно того стоит!

Из перечисленных выше стратегий, вот те, которые дадут вам наибольшую отдачу:

• Использование сети доставки контента (CDN)
• Использование премиум DNS серверов
• Установка и активация плагина кэширования
• Удаление плагинов WordPress (target aмаксимум 20 плагинов)
• Удалите большинство виджетов из боковой панели вашего сайта
• Установите и активируйте плагин оптимизации скорости, например Swift
• Обновите ваш хостинг на более быстрый тарифный план или более быстрый хост

Поскольку мир переходит от настольных компьютеров к мобильным, время отклика сервера становится критическим фактором ранжирования .

Настанет время, когда только сайты, способные молниеносно доставлять контент мобильным пользователям, будут занимать первое место на странице Google.

Поэтому опережайте события и старайтесь, чтобы время отклика вашего сервера было менее 2 секунд .

Разгоняем WordPress до скорости света

Чтобы узнать изменилось ли что-нибудь после нашей оптимизации, не помешает замерять для начала текущую скорость загрузки страниц блога, чтоб было с чем сравнивать. Есть несколько инструментов, которые помогут сделать это:

1.1 Pingdom

1.2 YSlow

YSlow– плагин для Firefox, который встраивается в, пожалуй лучший плагин для веб разработчика, Firebug. Он анализирует более 20 факторов, которые влияют на скорость работы сайта и оценивает общую производительность по 100 бальной системе, а каждый отдельный элемент оценкой от A до F.

1.3 Количество запросов и время их выполнения

2 Web Hosting

• Shared Hosting – на одном сервере может хоститься в среднем около 100 человек;
• VPS – на одном сервере может хоститься около 20 человек;
• Dedicated – сервер будет использоваться только вами.

Это, конечно, не означает, что вы не сможете ускорить блог, работающий на виртуальном хостинге(Shared Hosting), однако стоит помнить – производительность тем выше, чем большие ресурсы мы имеем в своем распоряжении.

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

3 Установка и настройка сервера

Удостоверьтесь, планируемая нагрузка соответствует мощности сервера и он сможет с ней справиться. В первую очередь это будет зависеть от объема оперативной памяти и процессора. Как правило, WordPress ставят на Apache, но много удачных решений существует и на базе других http серверов: nginx, lighttpd и т.д.

Не забудьте обновить до последней версии PHP и Apache.

3.1 Отключите неиспользуемые сервисы

• Удалите ClamD;
• Настроить SpamD на использование только 1 дочернего процесса;
• Удалите Mailman, если, конечно, вы не собираетесь запускать почтовый сервис.

3.2 MYSQL Query Cache

Чтоб настройки вступили в силу придется перезапустить сервис MySQL сервис.

3.3 Кэш компилятора: XCache или Eaccelerator?

Кэш компилятора увеличивает производительность откомпилированных скриптов на сервере, кэшируя их – это поможет сократить время выполнения PHP скриптов. Стоит попробовать и то и другое решение, однако по результатам опытов увеличение производительности при использовании Xcache на 5% выше, чем с Eaccelerator.

3.4 Увеличьте максимальное число соединений на Apache

Не забудьте рестартить сервис Apache, чтоб применить настройки.

4 Оптимизация кода и графики

Итак, сервер заработал и теперь настало самое время поиграть с кодом WordPress.

4.1 Отключите хотлинки

4.2 Используйте внешний хостинг для хранения изображений

Хостинг изображений на внешних серверах поможет значительно снизить нагрузку на сервер. В примере ниже вы можете видеть снижение объема используемой оперативной памяти на одном из блогов после переноса изображений на сервис Amazon S3.

4.3 Сжимайте java-скрипт код

Сжатие javascript довольно простая задача. Поскольку он выполняется при каждом просмотре страницы, вы можете уменьшить размер Javascript, удалив все незаполненное пространство. Вот простой инструмент, который поможет сделать это за вас — JavaScript Compressor.

4.4 Javascript в начале страницы

Часто случается так, что сайт начинает загружаться медленно или вообще останавливается, т.к. другой ресурс, с которого вызывается javascript(на пример Digg badges, Tweetmeme и т.д.), не доступен или оффлайн. Чтобы избежать этого вынесите весь javascript код в конец страницы, а то что по каким-то причинам вынести не удалось – попробуйте заключить в iFrame.

4.5 Используйте кэш браузера

4.6 Сжимайте статические данные

4.7 Используйте CDN для статических файлов

Если хранить все изображения на одном и том же домене, то браузер будет ожидать их загрузки одного за другим. Допустим на странице их у вас есть 12 штук, если вы разделите их между тремя поддоменами, они будут загружаться одновременно из трех «разных» источников вместо того, чтоб загружаться браузером по очереди из одного.
Можете попробовать перенести все css & javascript файлы на files.yoursite.com, а изображения и временные файлы на static.yoursite.com. Или же просто использовать CDN(Content Delivery Network) – большая сеть серверов, расположенных по всему миру, которые позволят не только хранить ваши файлы на разных поддоменах, а значит загружать их параллельно, но и доставлять пользователю данные с самого близкого к нему сервера. Все это позволит загружать данные намного быстрее.

5 WordPress

В этой части статьи мы рассмотрим приемы для улучшения производительности, которые можно применить непосредственно к WordPress.

5.1 Обновитесь до последней версии

Обновления до более новых версий позволяют не только устранять обнаруженные уязвимости, но и улучшают производительность. Для примера в wordpress 2.8 была существенно оптимизирована работа с БД.

5.2 Отключите Post Revisions

5.3 Сократите количество запросов

Уже на два запроса меньше. Довольно просто, не правда ли?

6 WordPress Plugins

И на последок предлагаю вашему вниманию несколько плагинов, которые могут повысить производительность wordpress. Как только все, описанное выше, будет выполнено, эти плагины помогут добиться еще более высокой производительности.

WP Super Cache
Это, пожалуй, лучший плагин к WordPress. WP Super Cache создает статические html версии каждой страницы и загружает их каждый раз, обходясь тем самым без запросов к БД. Это значительно увеличивает скорость загрузки страниц и снижает нагрузку на сервер. Строго рекомендуется к установке.

PHP Speedy WP
Этот плагин решает другую проблему, обозначенную в этой статье – удаление незаполненного пространства в CSS & javascript. Однако есть некоторые проблемы совместимости этого плагина с WP Super Cache, кроме того он долгое время уже не обновлялся, потому используйте на свой страх и риск.

Optimize DB
Плагин позволяет оптимизировать таблицы MySQL без помощи PHPmyadmin.

Сколько времени до первого байта и как его улучшить на вашем сайте WordPress

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

Время до первого байта на самом деле не является концепцией или идеей, которую должны понимать только технические специалисты. Каждый должен уметь понять его значение и применить на практике.

В этой статье я собираюсь объяснить вам в нескольких словах: что такое время до первого байта, как это влияет на ваш сайт и почему вам следует уделять этому вопросу значительное внимание, если вы хотите, чтобы ваши читатели получили лучший опыт. при просмотре вашего сайта.

Что такое время до первого байта?

Время до первого байта (TTFB) – это измерение, используемое в качестве показателя скорости отклика веб-сервера или другого сетевого ресурса.

TTFB измеряет продолжительность от пользователя или клиента, отправляющего HTTP-запрос, до первого байта страницы, полученного браузером клиента. Это время складывается из времени подключения к сокету, времени, затраченного на отправку HTTP-запроса, и времени, затраченного на получение первого байта страницы. Хотя иногда это неправильно понимается как вычисление после DNS, исходное вычисление TTFB в сети всегда включает сетевую задержку при измерении времени, необходимого для начала загрузки ресурса.

Это объяснение «технарей», взятое непосредственно из Википедии. Теперь давайте переведем это на более простой, который обслуживает всех.

Время до первого байта – это время, которое требуется от нажатия этой кнопки для загрузки веб-сайта до момента его начала рендеринга. Если говорить об этом в игровых терминах, время до первого байта было бы похоже на «задержку» или «задержку» во время игры. Задержка – это прямое представление о том, насколько воспринимается ваш сайт отзывчивым.

Какие факторы влияют на время до первого байта?

Время до первого байта может быть представлено несколькими факторами, но поскольку это статья о WordPress, мы собираемся свести все к тому, что затрагивается, когда WordPress находится на месте.

• Время ответа DNS
• Конфигурация и производительность сервера (PHP и веб-сервер)
• Плагины / тема WordPress
• Кэширование HTML включено / отключено

Каждый из этих факторов добавляет дополнительную задержку ко времени, которое требуется вашему сайту для начала рендеринга. Это означает, что все складывается. Дело не в том, что некоторые из этих факторов могут влиять на задержку, все эти факторы способствуют увеличению задержки! Итак, вы можете догадаться, что в идеальном сценарии все должно быть быстрым, чтобы вы могли получить очень хорошее время до первого байта, и если что-то в этой цепочке требует больше времени для обработки, ваше последнее время до первого байта пострадает.

Это важно, потому что время до первого байта влияет на все, что вы или ваши читатели делаете на своем сайте. Каждый раз, когда читатель нажимает на ссылку, изображение, сообщение в блоге или страницу, время до первого байта будет приниматься во внимание. Вы можете видеть, что плохое время до первого байта будет означать, что у читателя будет ситуация, аналогичная ситуации, когда игрок подключился к плохому серверу. С каждым щелчком будет связана значительная задержка, что повлияет на восприятие.

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

1 Время ответа DNS

Разрешение DNS – это первый фактор в уравнении. Всегда убедитесь, что используете хорошие DNS-серверы и что у них есть узлы, разбросанные по всему миру, чтобы получить наилучшее возможное разрешение. Хороший способ уменьшить TTFB на этом этапе – использовать хороший глобальный сервис, такой как CloudFlare, поскольку такой сервис реализует глобальное кэширование DNS. Этот метод очень хорош для уменьшения TTFB за счет кэширования дальнейших разрешений.

2 Конфигурация сервера

Второй шаг задержки TTFB – это фактический сервер. Вот здесь и появляется ваш хостинг. Тип конфигурации веб-сервера, который он использует, и методы кэширования значительно уменьшат TTFB. Например, если на вашем сервере реализован старый интерпретатор PHP 5.4, вы получите очень высокий TTFB, тогда как использование современной конфигурации PHP 7.1 сократит это время в 2 или более раз.

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

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

Кроме того, если ваш хостинг реализует кеширование PHP, это будет еще больше уменьшено по второму запросу, поскольку он предоставит кешированную версию этого файла вместо того, чтобы обрабатывать файл PHP заново.

Теперь вы можете видеть, что существует 2 типа хостингового бизнеса: общие (некэшированные) услуги и эксклюзивные услуги хостинга WordPress, которые обычно реализуют механизм кеширования для PHP, уменьшая при этом ваш TTFB.

3 Плагины и тема WordPress

Третий шаг в уравнении TTFB – это ваш фактический сайт. Это самый важный фактор, и я покажу вам, почему.

Обычно WordPress предоставляет вашему хостингу несколько файлов PHP для обработки, и чем они сложнее, тем больше времени потребуется на обработку. WordPress обслуживается плагинами, и эти плагины добавляют дополнительный код к окончательной обработке PHP, поэтому вы можете ясно видеть, что чем больше плагинов вы установили, тем больше времени потребуется вашему хостингу для их обработки и, следовательно, вашему TTFB повысится.

Чем меньше, тем лучше

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

Следующий пример может быть проблематичным (опять же – это частично зависит от того, что вы установили).

И, конечно же, все, что превышает барьер 30 плагинов, скорее всего, не поможет вашей задержке. Вы можете быть уверены, что веб-сайт с более чем 40 плагинами будет иметь очень высокий TTFB, даже если он размещен на великолепном хостинге, и я покажу вам, почему.

4 Кеширование HTML

Последний фактор является наиболее важным и связан с механизмом кеширования, который вы решили реализовать в своей установке WordPress. Хотя в WordPress существует несколько типов механизмов кэширования, наиболее эффективным из них является кэширование HTML.

Наличие хорошего плагина, такого как KeyCDN Cache Enabler, окажет огромное влияние на ваш TTFB, даже больше, чем сам хостинг. Он преобразует все эти файлы в HTML, поэтому после активации кеша вашим читателям не нужно будет проходить через препроцессор PHP на вашем хостинге, и только сам веб-сервер будет отвечать за обслуживание вашего контента. Вы даже можете ускорить процесс еще больше, если решите использовать хостинг, который включает nginx вместо apache в качестве основного веб-сервера, как я объяснил в этой статье.

Время до первого байта: примеры использования: почему это важно

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

Медленный веб-сайт на медленном сервере

Наличие медленного сайта может быть проблемой для TTFB, и если вы не заботитесь о хорошем хостинге, вы должны быть готовы к худшему из возможных результатов.

Разберем этот сайт подробнее. Для этой цели я собираюсь использовать Pingdom Tools, потому что это отличный инструмент, позволяющий вам увидеть TTFB. Хитрость заключается в том, чтобы раскрыть подробности при первом запросе к сайту.

Как видите, у сайта TTFB не менее 4,2 секунды! Это означает, что пройдет 4 полных секунды, пока вы не получите никаких указаний на то, что веб-сайт действительно доступен.

Теперь умножьте это время на все клики, которые вы собираетесь сделать на сайте, и вы увидите, сколько боли это может причинить читателю. Конечно, TTFB необходимо добавить к общему времени рендеринга сайта. Результат будет катастрофическим для производительности, поскольку для правильного рендеринга сайта иногда требуется до 7 секунд.

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

Быстрый сайт на среднем сервере

Давайте посмотрим, что произойдет, если мы поместим очень быстрый сайт на средний сервер, использующий Apache и PHP 7.1.

Если на сайте меньше 10 плагинов без кеша, результат будет как минимум в 5 раз лучше предыдущего. Вы можете видеть, что TTFB теперь установлен на 521 мс. Это означает, что сайту потребуется 0,5 секунды, чтобы начать рендеринг в вашем браузере, с момента его перехода с сервера до момента, когда он достигнет вашего компьютера.

Что происходит, когда мы активируем кеш на этом веб-сайте? Волшебство случается. Обычно средний сервер, работающий на Apache, может дать отличные результаты с TTFB всего 152 мс. Вы можете увидеть, насколько хороший механизм кеширования WordPress влияет на результаты.

Очень медленный веб-сайт на быстром сервере

А теперь посмотрим на обратное. Что произойдет, если мы поместим очень медленный сайт на очень быстрый сервер.

Оптимизированному серверу, на котором запущен Plesk с nginx и PHP 7.1.11, потребуется 1,29 секунды для рендеринга сайта, заполненного плагинами (более 27).

Но когда мы активируем кеширование на WordPress с помощью прекрасного KeyCDN Cache Enabler, результат просто потрясающий. На очень медленном сайте TTFB уменьшен до 400 мс.

Быстрый веб-сайт на быстром сервере

Теперь посмотрим на оптимальную ситуацию. Быстрый сайт, работающий на быстром сервере.

Тот же сервер, который давал 1,29 секунды TTFB на медленном сайте, отвечает менее чем за 500 мс на быстром сайте без кеша.

Если мы включим кеш, результаты просто потрясающие. Быстрый сервер в сочетании с быстрым веб-сайтом с включенным кешированием дает менее 150 мс TTFB!

Результаты тестов

Для любителей тестов давайте посмотрим результаты на одном большом графике.

Вы можете видеть, что хостинг играет важную роль в сокращении TTFB и улучшении задержки и воспринимаемой производительности вашего сайта, но то, что вы делаете с сайтом, оказывает наибольшее влияние на производительность.

Заключение

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

Я хочу закончить эту статью, сказав, что это ни в коем случае не «единственная метрика, чтобы управлять ими всеми», поскольку есть другие факторы, которые следует учитывать, включая производительность базы данных, доступную пропускную способность и скорость сети. Но поскольку на TTFB обычно влияют все эти факторы, это хороший показатель узких мест в других местах.

Надеюсь, у вас будет возможность поэкспериментировать со своим TTFB. Оставляйте свои комментарии ниже. Мы будем рады узнать о вашем собственном тестировании или помочь с любыми вопросами, которые могут у вас возникнуть.

8 способов сократить начальное время отклика сервера в WordPress

Вордпресс
Направляющие

21 сентября 2022 г.

Will M.

11min Read

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

К счастью, вы можете улучшить Time to First Byte (TTFB) , чтобы свести к минимуму эту задержку. Если вы получили низкий балл по PageSpeed ​​Insights , есть много способов уменьшить начальное время отклика вашего сайта. Эти методы могут быть такими же простыми, как внедрение кэширования, обновление плана хостинга или оптимизация файлов сайта.

В этой статье объясняется, что такое время до первого байта и почему оно важно. Затем мы покажем вам, как измерить время отклика вашего веб-сайта и улучшить низкий показатель TTFB. Давайте начнем!

Скачать Ultimate WordPress Cheat Sheet

Сколько времени до первого байта (TTFB)?

Один из лучших способов WordPress сократить начальное время отклика сервера — улучшить время до первого байта. Проще говоря, это время между первоначальным запросом сервера и доставкой первого байта вашей страницы.

Однако не следует путать TTFB с той же метрикой, что и время загрузки страницы, так как эти два показателя соответствуют разным временам в запросе.

Когда кто-то пытается получить доступ к веб-сайту, время до первого байта — это время, затрачиваемое на подключение к серверу и запуск рендеринга страницы. После того, как первоначальный ответ будет доставлен в веб-браузер, контент будет загружен, и страница загрузится.

Время до первого байта состоит из следующих ключевых компонентов:

• Время перенаправления
• Время загрузки Service Worker
• Поиск DNS
• Согласование Connection and Transport Layer Security (TLS)
• Время запроса до первого байта response

Веб-сайт будет иметь низкий показатель TTFB, если он быстрый и отзывчивый. Более высокое время до первого байта указывает на более длительную задержку при отправке первого байта ресурсов обратно в веб-браузер, отправивший запрос.

Почему важно время до первого байта?

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

Основные показатели Core Web Vitals:

• Largest Contentful Paint (LCP) отображает время загрузки
• First Input Delay (FID) иллюстрирует интерактивность
• Кумулятивное смещение макета (CLS) отражает визуальную стабильность

Время до первого байта не является одним из трех показателей Core Web Vitals, но тесно связано с LCP. Улучшая TTFB, вы можете уменьшить начальное время отклика сервера и, в свою очередь, уменьшить общее время загрузки.

Хотя время до первого байта измеряет скорость отклика сайта, а не скорость, плохой результат в любой области может вызвать аналогичные проблемы. Когда сервер не отвечает быстро, пользователям придется долго ждать загрузки страницы. Эта задержка может привести к ухудшению пользовательского опыта и более высокому показателю отказов.

Оценка времени до первого байта также может повлиять на рейтинг сайта в поиске. Поскольку скорость сайта является одним из факторов ранжирования Google, сокращение начального времени отклика сервера может стать ключом к улучшению поисковой оптимизации WordPress.

Однако время до первого байта — не единственный фактор, который следует учитывать при улучшении SEO и удобства страницы. Вот другие способы оптимизации веб-сайта:

• Отдайте предпочтение контенту, удобному для мобильных устройств
• Сосредоточьтесь на функциях веб-доступности
• Улучшение общего веб-дизайна

В сочетании с хорошей оценкой TTFB эти методы обеспечат максимальную производительность вашего веб-сайта. Вы можете ускорить работу WordPress, привлечь новых посетителей и дольше удерживать внимание пользователей.

Причины медленного времени отклика сервера

Поскольку TTFB влияет на FCP и LCP, важно сократить время отклика сервера для достижения хороших показателей Core Web Vitals. В общем, вы должны стремиться к показателю TTFB 800 миллисекунд или меньше.

Одной из распространенных причин медленного времени до первого байта является динамическое содержимое. Статическая веб-страница может мгновенно доставлять контент по каждому запросу. Однако PHP и запросы к базе данных требуют больше времени для обработки больших динамических файлов.

Вот некоторые дополнительные причины, по которым у вас может быть высокое время до первого байта:

• Неэффективный код сервера
• Медленные запросы к базе данных
• Задержка в сети
• Высокий веб-трафик
• Задержка ответа DNS
• Нехватка ресурсов ЦП или памяти

Часто большинство этих проблем можно решить, приобретя более качественные услуги веб-хостинга. Скорее всего, у вас будет неправильно настроенный сервер, если у вас некачественный хостинг-план. В свою очередь, это может привести к замедлению времени отклика.

Как измерить начальное время отклика сервера (3 варианта)

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

1. Google PageSpeed ​​Insights

Одним из самых популярных инструментов для измерения производительности сайта является Google PageSpeed ​​Insights. Используя данные реального взаимодействия с пользователем, программное обеспечение предоставляет отчеты Core Web Vitals, а также экспериментальные показатели, такие как Interaction to Next Paint (INP) и Time to First Byte .

Просто вставьте URL своего сайта в текстовое поле и нажмите Анализ , чтобы проверить время отклика сервера.

С планом Hostinger вы также можете получить доступ к PageSpeed ​​Insights из hPanel:

1. Сначала войдите в свою учетную запись и перейдите в раздел Hosting -> Manage .

1. Прокрутите вниз до раздела Веб-сайт и выберите Скорость страницы .

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

Вы увидите Core Web Vitals Assessment в верхней части оценки PageSpeed ​​Insights. В зависимости от результатов, ваш сайт будет либо пройти или не пройти .

При переходе к разделу Время до первого байта (TTFB) можно просмотреть время ответа веб-сайта в секундах. Для этого измерения оценка Хорошо считается 0,8 секунды или менее .

Если показатель TTFB вашего веб-сайта равен от 0,8 до 1,8 секунды , он будет показывать статус Needs Improvement . Оценка Плохо — это что-нибудь за 1,8 секунды .

PageSpeed ​​Insights автоматически покажет вам Core Web Vitals Assessment для мобильных экранов. Однако вы можете выбрать Рабочий стол тоже.

Вы увидите одни и те же метрики, но они могут отображать разные оценки. Обязательно снова проверьте время до первого байта. Если оценка отмечена зеленым кругом, вам не нужно уменьшать начальное время отклика сервера в WordPress.

2. GTmetrix

Вы также можете выполнить тест скорости с помощью GTmetrix. Этот инструмент анализирует веб-сайт с помощью Google Lighthouse и находит способы оптимизации веб-производительности:

Введите URL-адрес вашего сайта в GTmetrix и нажмите 9.0013 Протестируйте свой сайт . Возможно, вам придется подождать несколько секунд, пока GTmetrix извлечет и проанализирует содержимое.

После загрузки отчета GTmetrix вы получите оценку общей производительности веб-сайта. На вкладке Summary можно просмотреть схему Speed ​​Visualization .

С левой стороны найдите свой показатель TTFB. Это число покажет общую задержку в миллисекундах. Это сумма времени перенаправления, подключения и серверной части.

Вы также можете просмотреть эту информацию, если вам нужно знать баллы Core Web Vitals. Прямо под TTFB вы увидите баллы First Contentful Paint и Largest Contentful Paint . Справа проверьте Время полной загрузки .

GTmetrix запустит аудит TTFB, только если превысит 600 миллисекунд . Вы можете просмотреть сведения об аудите в разделе Top Issues , если это произойдет.

Откройте схему водопада для получения дополнительной информации о поведении загрузки вашего веб-сайта. Здесь вы можете навести указатель мыши на определенный запрос ресурса, чтобы увидеть, сколько времени требуется для его выполнения.

В этих данных оценка TTFB будет отображаться как Время ожидания . Эта диаграмма может помочь вам обнаружить неоптимизированные ресурсы и сократить начальное время отклика сервера.

3. KeyCDN

Тест производительности KeyCDN измеряет время отклика вашего веб-сайта в десяти тестовых местах. Этот инструмент может быть полезен, если вы предоставляете контент глобальной аудитории.

Чтобы начать, введите свой URL-адрес и нажмите Test . Затем вы увидите, как ваш сайт работает в разных местах.

Справа от каждой локации вы можете просмотреть свой счет TTFB. Имейте в виду, что это число должно быть до 800 миллисекунд .

Используя KeyCDN, вы также можете оценить код состояния HTTP для каждого запрошенного местоположения. Далее вы увидите время, необходимое для поиска DNS. Эти результаты также сообщат вам, есть ли задержка при подключении к серверу.

Однако этот инструмент производительности не предоставляет подробной информации о Core Web Vitals. Этот вариант следует рассматривать только в том случае, если вы хотите быстро оценить время до первого байта по всему миру.

Как уменьшить начальное время отклика сервера в WordPress (8 способов)

Если вы заметили, что ваш сайт имеет высокий показатель TTFB, вы, вероятно, захотите его уменьшить. Вот восемь способов начать.

1. Обновите свой веб-хостинг

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

При поиске потенциального веб-хостинга вы хотите оценить производительность его серверов. Например, в Hostinger мы используем веб-серверы LiteSpeed ​​(LSWS), работающие в четыре раза быстрее, чем другие типичные типы серверов.

Также полезно выбрать веб-хост с несколькими серверами. Возможно, вам не нужен веб-хост только с серверами в Северной Америке, если у вас глобальная аудитория. Сеть серверов может обеспечить быструю доставку данных по всему миру.

С Hostinger вы получите доступ к десяти различным хранилищам данных по всему миру. При необходимости вы также можете изменить расположение сервера на панели управления hPanel. Просто найдите информацию о сервере и нажмите Редактировать значок .

Затем используйте раскрывающееся меню, чтобы изменить местоположение сервера. Имейте в виду, что завершение переноса может занять до 24 часов.

Как только вы найдете веб-хостинг, отвечающий вашим потребностям, вам также нужно будет выбрать правильный хостинг-план. Хотя планы виртуального хостинга недороги, они предполагают совместное использование сервера с другими пользователями. Эта настройка означает, что вы можете столкнуться с дополнительными проблемами производительности и безопасности.

Благодаря выделенному хостингу WordPress вы можете избежать многих из этих проблем. Вы получите быстрый и безопасный сервер, специально оптимизированный для WordPress. Эта настройка может эффективно сократить начальное время отклика сервера и повысить производительность сайта.

2. Установите плагин кэширования

После выбора хостинг-плана мы рекомендуем реализовать кэширование на вашем сайте. WordPress должен обрабатывать и отображать динамический контент, когда кто-то посещает ваш сайт. Если это происходит для каждого запроса, это может замедлить работу веб-сайта.

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

Установка плагина кэширования может уменьшить TTFB. Этот инструмент может мгновенно настроить кеш для вашего сайта. Хотя есть много плагинов на выбор, LiteSpeed ​​Cache — один из лучших доступных вариантов.

В отличие от других подключаемых модулей кеширования, LiteSpeed ​​Cache интегрируется с вашим сервером для создания кеша на уровне сервера. Этот инструмент может значительно повысить производительность сайта за счет автоматического кэширования и очистки страниц.

Кроме того, планы Hostinger включают предварительно установленный LiteSpeed ​​Cache. Чтобы убедиться, что этот инструмент активирован на вашем веб-сайте, откройте hPanel и выберите Dashboard в разделе WordPress .

Затем найдите параметр настройки LiteSpeed ​​ и убедитесь, что превратил в .

Когда вы откроете панель управления WordPress, вы заметите, что LiteSpeed ​​Cache установлен и активирован. Этот плагин автоматически настроит кеш и ускорит время отклика сайта.

3. Используйте сеть доставки контента (CDN)

Другим эффективным способом снижения TTFB является использование сети доставки контента (CDN). CDN — это группа серверов, размещенных по всему миру для быстрой доставки онлайн-контента.

После внедрения CDN множество различных прокси-серверов будут хранить копии вашего веб-контента. Даже если основной сервер находится далеко от международного пользователя, они смогут получить доступ к вашему сайту через кешированные данные. Эта настройка сведет к минимуму нагрузку на основной сервер и ускорит доставку контента.

Когда вы начинаете искать CDN для WordPress, вам следует учесть несколько моментов:

• Время отклика DNS
• Время приема-передачи (RTT)
• Время ожидания
• Коэффициент попаданий в кэш
• SSL-сертификаты
• Защита от DDoS-атак

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

Cloudflare использует граничные вычисления для обеспечения быстрой и эффективной передачи данных. Это может сократить количество времени, которое посетители тратят на ожидание загрузки веб-сайта. Кроме того, вы можете бесплатно получить доступ к Cloudflare с нашими 9Планы 0013 Hostinger Business WordPress или WordPress Pro .

4. Сжатие файлов вашего сайта

Если ваш веб-сайт имеет тяжелый неоптимизированный код, серверу может потребоваться больше времени для обработки HTTP-запросов. Когда вы минимизируете CSS и комбинируете внешний JavaScript в WordPress, вы можете уменьшить размер этих файлов и ускорить загрузку.

Чтобы сжать файлы сайта, не нужно быть профессиональным разработчиком. Плагин LiteSpeed ​​Cache может удалить лишние пробелы, символы новой строки и комментарии из ваших CSS, HTML и JavaScript. Этот инструмент также может устранить код JavaScript и CSS, блокирующий рендеринг, в содержимом верхней части страницы.

После установки и активации LiteSpeed ​​Cache перейдите на вкладку Оптимизация страницы . Здесь вы увидите настройки для CSS , JavaScript и HTML .

Для каждого из них убедитесь, что параметр Minify включен. Это будет первая опция на каждой странице настроек.

После этого нажмите Сохранить Изменения . LiteSpeed ​​Cache удалит файлы вашего сайта, не затрагивая функции скрипта, если файлы вашего сайта содержат ненужные строки кода.

5. Обновление установленного программного обеспечения

Для владельца веб-сайта одной из наиболее важных задач управления является обновление программного обеспечения WordPress. Часто разработчики создают новые версии программного обеспечения с оптимизацией производительности. Если вы не будете регулярно обновлять плагины, темы или ядро ​​WordPress, ваш сайт, скорее всего, не будет таким отзывчивым.

Чтобы узнать, есть ли доступные обновления, откройте панель управления WordPress и щелкните страницу Обновления . Здесь посмотрите, нужно ли вам установить новую версию WordPress.

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

Также рекомендуется просмотреть установленные вами плагины. Если вы не используете их активно, рассмотрите возможность их удаления навсегда. Удаление может быть особенно полезным, если программное обеспечение больше не получает активной поддержки.

У вас также может быть постоянно работающее программное обеспечение. Такие плагины, как Broken Link Checker, продолжают работать в фоновом режиме, что негативно влияет на время отклика сервера. Чтобы уменьшить TTFB, рассмотрите возможность деактивации или полного удаления этих плагинов.

6. Обновите версию PHP

Программное обеспечение WordPress написано с использованием языка программирования с открытым исходным кодом под названием PHP. Наряду с обновлением основного программного обеспечения, тем и плагинов важно обновить версию PHP.

Вы можете повысить производительность веб-сайта, используя новейшую версию PHP. Обновление PHP может увеличить скорость и время отклика за счет улучшения кодирования и сокращения использования памяти.

Обновление до новейшей версии PHP не позволяет хакерам использовать ошибки, найденные в более старых версиях, поскольку оно получает активную поддержку и исправляет ошибки.

Перед переходом на новую версию PHP вам необходимо сделать резервную копию веб-сайта. Вы всегда можете восстановить сайт в исходное состояние, если что-то пойдет не так.

С учетной записью Hostinger вы можете обновить конфигурацию PHP непосредственно в панели управления hPanel. Сначала найдите раздел Advanced и нажмите PHP Configuration .

Затем выберите новую версию PHP, которую вы хотите использовать. По умолчанию отображаются только поддерживаемые в настоящее время версии PHP.

После выбора последней версии нажмите Обновить . Теперь ваш сайт будет работать на новой версии PHP.

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

7. Оптимизируйте вашу базу данных

Когда ваша база данных содержит слишком много ненужной информации, это может увеличить ваш TTFB. Регулярная оптимизация базы данных WordPress необходима для сокращения начального времени отклика сервера. Вы можете ускорить работу сайта, удалив отправленные в корзину сообщения, исправления и спам-комментарии.

WP-Optimize — это бесплатный плагин, который может оптимизировать вашу базу данных. Он удаляет лишние данные, сжимает изображения, кэширует страницы и минимизирует ваши скрипты. Используя этот универсальный инструмент, вы можете сократить время, необходимое серверу для обработки запросов.

Сначала загрузите и установите WP-Optimize. Затем откройте вкладку База данных . Здесь вы можете выбрать множество различных вариантов оптимизации сайта.

Чтобы очистить базу данных, выберите оптимизацию таблиц базы данных, отправку исправлений, автоматические черновики сообщений и удаление сообщений в корзину. Вы также можете удалить спам, неутвержденные или удаленные комментарии. Наконец, нажмите на Запустить все выбранные оптимизации .

Вы также можете создать запланированное время для запуска этих оптимизаций базы данных. Для этого перейдите на вкладку Параметры и прокрутите вниз до Параметры плановой очистки .

Установите флажок рядом с Включить запланированную очистку и оптимизацию . Затем выберите, выполнять ли это ежедневно, еженедельно, раз в две недели или ежемесячно.

Наконец, выберите некоторые из доступных служб очистки. Если вас устраивают эти изменения, нажмите Сохранить настройки .

8. Сократите количество запросов к базе данных

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

Для мониторинга запросов к базе данных рассмотрите возможность установки диагностического инструмента, такого как Query Monitor. Этот бесплатный плагин отлаживает запросы, ошибки PHP, скрипты и таблицы стилей.

Как только вы активируете Query Monitor, нажмите на новую числовую вкладку в верхней части панели инструментов. Это автоматически откроет 9Страница 0013 Обзор , на которой можно просмотреть общее время, затраченное на обработку запросов к базе данных.

Затем перейдите на страницу Запросы для управления полным списком запросов к базе данных. Рядом с каждым запросом вы увидите время, необходимое для его обработки, а также плагин, влияющий на него.

Отфильтруйте результаты, используя раскрывающиеся меню в верхней части страницы. Затем вы увидите тип запроса, вызывающий объект или компонент. Кроме того, вы можете просмотреть расширенную информацию в Дублированные запросы , Запросы по вызывающему абоненту и Запросы по компонентам вкладки.

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

Заключение

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

Напомним, вот как вы можете уменьшить начальное время отклика сервера в WordPress:

1. Обновите свой хостинг-план.
2. Установите плагин кэширования, например LiteSpeed ​​Cache.
3. Используйте сеть доставки контента (CDN).
4. Сжатие файлов сайта с помощью инструмента минимизации.
5. Обновление установленного программного обеспечения, плагинов и тем.
6. Оптимизируйте базу данных с помощью плагина, такого как WP-Optimize.
7. Уменьшите количество запросов к базе данных с помощью Query Monitor.

После принятия этих мер вы повысите скорость отклика вашего сайта! Если у вас есть дополнительные вопросы или предложения, не стесняйтесь поделиться ими в разделе комментариев.

Уилл Моррис — штатный писатель WordCandy. Когда он не пишет о WordPress, ему нравится выступать со своими стендап-комедиями на местных каналах.

Подробнее от Уилла М.

Как сократить время до первого байта (TTFB) и время отклика сервера

Если вы когда-либо запускали тест PageSpeed ​​Insights, вы, вероятно, сталкивались со следующей рекомендацией: «Сократите начальное время отклика сервера». Начальное время отклика сервера влияет на общее время загрузки и показатели производительности, такие как «Самая крупная отрисовка контента», одна из основных показателей Web Vitals. Следовательно, это также повлияет на ваш показатель PageSpeed.

Уменьшение начального времени ответа сервера означает, что вам следует уменьшить время вашего сайта до первого байта (TTFB) . TTFB относится к количеству времени, которое требуется браузеру для установления соединения с сервером и начала загрузки содержимого веб-страницы. Таким образом, чем больше вы сможете улучшить свой TTFB, тем лучше будет ваша производительность.

Давайте разберемся, что такое TTFB и что вызывает медленный TTFB. Вы узнаете, как уменьшить его, и выполните рекомендации PSI. Вы ускорите загрузку своих страниц и улучшите свой рейтинг LCP.

Во-первых, вы можете посмотреть наше видео:

Что такое время до первого байта (TTFB)?

Google определяет время до первого байта как период «ожидания»:

«Время ожидания первоначального ответа, также известное как время до первого байта. Это время фиксирует задержку пути к серверу в оба конца в дополнение к времени, затраченному на ожидание ответа сервера».

Проще говоря, TTFB — это количество времени с момента перехода на веб-страницу до момента начала ее рендеринга, то есть момента, когда вы начнете видеть некоторый контент, отображаемый на вашем экране.

TTFB состоит из трех отдельных компонентов:

1. Время, необходимое для отправки HTTP-запроса

TTFB, начинается с HTTP-запроса . Время, необходимое серверу для получения запроса, зависит от времени, необходимого для выполнения поиска DNS, скорости сети пользователя, расстояния до сервера и любых прерываний соединения.

2. Время, необходимое для обработки запроса

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

3. Время, необходимое серверу для отправки первого байта ответа браузеру.

Наконец, серверу необходимо отправить ответ пользователю. Этот шаг зависит как от скорости сети сервера, так и от пользователя. Если у пользователя медленное соединение Wi-Fi, это повлияет на TTFB.

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

Почему важен TTFB?

TTFB — это фактор, влияющий на общую скорость страницы, поэтому это важный показатель, за которым нужно следить и оптимизировать, а также для улучшения ваших оценок Core Web Vitals .

Также стоит отметить, что не следует путать TTFB со скоростью страницы. Это просто показатель, который дает вам представление об отзывчивости вашего сайта.

TTFB — это показатель, который (в основном) находится под вашим контролем, и вы можете настроить его, чтобы ускорить работу вашего сайта. Так почему бы не уменьшить его, чтобы сделать ваш сайт быстрее и повысить показатель PageSpeed?

Более того, когда вы уменьшаете TTFB:

• Пользователи тратят меньше времени на ожидание загрузки вашего сайта, улучшая взаимодействие с пользователем — не забывайте, что LCP связан с обновлением Page Experience Update, последним фактором ранжирования SEO.
• Пользователи с меньшей вероятностью отказываются от просмотра, ожидая появления контента на странице, что означает более высокую вовлеченность и удержание.

Что такое хорошее время для первого байта (TTFB)?

Google рекомендует TTFB ниже 200 мс. Аудит Lighthouse завершается сбоем, когда браузер ожидает ответа сервера на основной запрос документа более 600 мс.

Если значение TTFB превышает несколько сотен миллисекунд, возможно, на вашем сервере есть узкие места, которые необходимо изучить.

Google рекомендует сайтам обрабатывать действия/вводы пользователей в течение 50 мс, чтобы обеспечить видимый ответ в течение 100 мс. Для действий, выполнение которых занимает более 50 мс, всегда предоставляйте обратную связь, т. е. отображайте индикатор загрузки или меняйте цвет для активного состояния.

В чем причина медленного TTFB?

Когда речь идет о сайтах WordPress, на время до первого байта могут влиять несколько различных факторов:

• Задержка в сети
• Высокий веб-трафик
• Конфигурация и производительность сервера
• Динамический контент
• Время отклика DNS

90 Вы мало что можете сделать для решения проблем с интенсивным веб-трафиком или сетью. Но есть способы решения проблемы с конфигурацией сервера, динамическим содержимым и временем отклика DNS, которые мы рассмотрим ниже.

Как измерить время до первого байта: 4 варианта

Первый шаг к выяснению того, почему время TTFB велико, — это его измерение. Существует несколько способов измерения TTFB, но имейте в виду, что каждый из приведенных ниже инструментов будет выводить разные значения TTFB, поэтому я рекомендую использовать инструмент, который вам более знаком и удобен.

1. Измерение TTFB с помощью GTmetrix




Вы можете легко измерить TTFB с помощью GTMetrix, который относится к этой метрике как «время ожидания».

Чтобы увидеть результаты, просканируйте свой сайт и откройте водопад. Когда вы наведете курсор на первый результат в списке, вы увидите свои показатели загрузки, включая время ожидания (также известное как TTFB).

GTmettrix – TTFB

2. Измерение TTFB с помощью WebPageTest

Вы также можете измерить TTFB с помощью WebPageTest . Когда вы просканируете свой сайт, вы получите свой TTFB за считанные секунды.

WebPage Test – TTFB

3. Измерение TTFB с помощью Pingdom

Pingdom также измеряет TTFB, называя его временем ожидания. Чтобы использовать этот инструмент, просто отсканируйте свой сайт и прокрутите результаты вниз до раздела «Запросы файлов», где вы увидите время ожидания для вашего сайта и отдельных запросов.

Pingdom — TTFB

4. Измерение TTFB с помощью KeyCDN Web Performance Tool

Еще одним замечательным инструментом для измерения TTFB является онлайн-тест KeyCDN Web Performance Test . Он позволяет быстро измерить показатель TTFB в 14 различных тестовых точках. Как видно из приведенных ниже результатов, TTFB для сайта WordPress.org ниже в США и выше в Европе, Азии и Австралии, что доказывает, что расстояние и задержка играют большую роль в TTFB.

KeyCDN — TTFB

9 способов сократить время до первого байта (TTFB) в WordPress

Давайте посмотрим, как вы можете уменьшить TTFB и время отклика сервера для вашего сайта WordPress.

1. Используйте быстрый веб-хост

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

Вы должны учитывать, где расположены серверы вашего хоста. Выберите хост, который физически расположен ближе к месту, где находятся ваши пользователи. Например, если большинство ваших пользователей находятся в Европе, имеет смысл разместить ваш сайт в Европе, а не в США. (Хотя вы можете обойти это с помощью CDN, о котором мы поговорим ниже.)

Хотя вы не можете контролировать объем трафика вашего сайта, вы можете управлять его масштабируемостью. Поэтому, если вы ожидаете высокий трафик на свой сайт, убедитесь, что ваш хост может быстро масштабировать ваш сайт, чтобы улучшить его TTFB.

2. Используйте кэширование

Один из самых простых способов уменьшить TTFB — настроить кэширование на вашем сайте WordPress . Кэширование помогает уменьшить TTFB, помогая сократить время обработки сервером.

Узнайте у своего веб-хостинга, что они предлагают в отношении кэширования объектов. Часто все, что вам нужно сделать, это попросить вашего хоста включить его.

Вы также можете разрешить WP Rocket кэшировать страницы на вашем сайте , чтобы ваши страницы быстрее доставлялись вернувшимся посетителям сайта. Вы справитесь с работой без каких-либо усилий с вашей стороны. Как только вы включите WP Rocket, плагин сделает всю работу за вас.

Получите WP Rocket прямо сейчас и протестируйте улучшение прямо сейчас!

3. Используйте сжатие GZIP

Применяя сжатие GZIP, вы уменьшите размер файлов HTML, CSS и JS — все ресурсы будут загружаться быстрее, и вы уменьшите TTFB.

Проверьте своего хостинг-провайдера: некоторые хосты по умолчанию включают сжатие GZIP.

WP Rocket также применяет сжатие GZIP на сайтах, работающих на Apache — вам нужно только включить его!

В качестве бесплатной альтернативы вы можете использовать такой плагин, как Enable Gzip Compression.

4. Оптимизируйте вашу базу данных

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

WP Rocket дает вам простой способ оптимизировать вашу базу данных, уменьшить раздувание и запланировать автоматическую очистку.

Вы найдете специальную вкладку со всеми функциями, такими как публикации, комментарии и автоматическая очистка (ежедневно, еженедельно или ежемесячно):

Вкладка базы данных — WP Rocket

В качестве альтернативы вы можете выбрать простой плагин базы данных, такой как WP-DBManager, или универсальный плагин, такой как WP-Optimize, который очищает базу данных, сжимает изображения и кэширует сайт.

5. Используйте CDN

Использование CDN хорошего качества, например RocketCDN, может помочь быстрее доставлять статическое содержимое, например изображения и сценарии, пользователям через сеть серверов по всему миру. Это означает, что если ваш сервер географически расположен, например, в Европе, а ваши пользователи в основном находятся в Соединенных Штатах, они будут получать контент вашего сайта с сервера, расположенного ближе к ним.

Это уменьшает задержку в сети между сервером вашего сайта и вашими посетителями.

Чтобы узнать больше о сетях CDN и выбрать одну из них, ознакомьтесь с разделом . Как выбрать сеть CDN: откройте для себя лучшие сети CDN для WordPress. Вы также можете узнать больше о преимуществах CDN.

6. Постоянно обновляйте WordPress, плагины и темы

Основная команда WordPress, а также авторы плагинов и тем часто добавляют в свои обновления оптимизацию производительности. Иногда это означает, что они оптимизировали запросы, которые их код выполняет к базе данных, или внесли обновления, влияющие на эффективность кода PHP.

Лучше всего оставить нужные вам плагины и темы и удалить остальные. Поэтому регулярно просматривайте свои плагины и темы и удаляйте те, которые вы больше не используете.

Качество ваших плагинов также может повлиять на показатель TTFB, поэтому обратите внимание на плагины, влияющие на производительность вашего сайта. Broken Link Checker, например, предназначен для работы в фоновом режиме, время от времени проверяя наличие неработающих ссылок. Результатом является медленный администратор WordPress и увеличение TTFB.

7. Сокращение запросов

Часто количество запросов, которые ваш сайт выполняет для получения информации из базы данных, может повлиять на TTFB. Чтобы выявить узкие места в запросах, попробуйте установить диагностический плагин, например Query Monitor , или рассмотрите возможность использования более мощного инструмента, такого как New Relic . Последнее поможет вам разобраться в запросах к базе данных, которые занимают больше всего времени или имеют самое медленное время запроса, чтобы вы могли найти, какие плагины, темы или настройки влияют на скорость страницы вашего сайта.

8.

Используйте службу DNS премиум-класса

Типичные пакеты хостинга не предлагают DNS премиум-класса (хотя некоторые управляемые хосты WordPress предлагают). Инвестиции в поставщика DNS премиум-класса гарантируют, что DNS-запросов будут отвечать с малой задержкой за счет использования глобальной сети DNS-серверов, что, в свою очередь, поможет уменьшить ваш TTFB.

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

9. Не забывайте последнюю версию PHP

Использование версии PHP 7+ также улучшит ваше время до первого байта. Чтобы дать вам простую причину, PHP 7+ может обрабатывать почти на 50% больше запросов в секунду. Итак, если вы все еще используете PHP 5.6, пришло время обновиться!

Сократите время до первого байта прямо сейчас

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

WP Rocket — это самый простой способ улучшить ваш TTFB и добиться выдающихся улучшений скорости без использования различных плагинов для повышения производительности. И вам даже не нужно прикасаться к коду!

Как сократить время отклика сервера на WordPress

Следите за @Cloudways

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

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

В этой статье я расскажу вам о том, что такое время отклика сервера и как вы можете уменьшить его на своем WordPress.

Содержание

• Что такое время отклика сервера?
• Зачем уменьшать время отклика сервера?
• Как уменьшить время отклика сервера?
• Как Cloudways сокращает время отклика?
• TTFB на серверах Cloudways
• Резюме

Прежде чем я начну, давайте посмотрим на четырехэтапный процесс, который приводит к отображению веб-страницы на вашем экране.

1. Запрос: Это запрос, инициированный браузером посетителя (или клиента).
2. Ответ: Запрос обработан, необходимые активы (файлы веб-страниц, ресурсы и т. д.) обрабатываются сервером и отправляются обратно в веб-браузер посетителя.
3. Сборка: Веб-браузер использует эти ресурсы для запуска процесса рендеринга запрошенной веб-страницы.
4. Render:
   Наконец, веб-страница отображается для посетителя.

Из четырех, второй шаг (ответ) полностью зависит от хост-сервера. Если сервер не может выполнить этот шаг (по какой-либо причине), следующие шаги задерживаются, и, таким образом, страдает UX для посетителя.

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

Эта низкая производительность также влияет на SEO сайта и пользовательский опыт.

Что такое время ответа сервера?

Время ответа сервера (также известное как время до первого байта) — это время, необходимое серверу для ответа на запрос посетителя. TTFB относится к временному интервалу, в течение которого клиент отправляет запрос, и браузер клиента начинает отображать запрошенную веб-страницу.

Меры TTFB включают три компонента.

Отправка HTTP-запроса

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

Обработка запроса

Когда сервер получает запрос от браузера, он инициирует различные процессы, такие как выполнение сценариев, получение данных из базы данных и выполнение внутренних задач.

Обработка ответа

После того как все компоненты ответа сгенерированы, сервер отправляет их конечному пользователю. Этот шаг зависит от производительности сервера хостинга вашего веб-сайта и скорости интернет-соединения пользователя.

При просмотре результатов, полученных с помощью онлайн-инструмента анализа производительности, такого как WebPageTest, вы могли заметить TTFB. Согласно рекомендациям Google, веб-сайт не должен иметь TTFB более 200 мс.

Примечание: Если вы запустите тест скорости сайта WordPress, вы, вероятно, найдете ссылки на медленный admin-ajax.php в своих результатах. Если да, узнайте, как это исправить!

Зачем уменьшать время отклика сервера?

Медленный сайт может иметь негативные последствия для бизнеса. Время загрузки вашего веб-сайта значительно влияет на взаимодействие с пользователем (UX) и поисковую оптимизацию (SEO).

Согласно исследованиям, более 40% веб-пользователей покидают сайт, если он загружается более 3 секунд. Кроме того, чем дольше он загружается, тем ниже его рейтинг на странице результатов поисковой системы (SERP).

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

Как уменьшить время отклика сервера?

Многие факторы могут вызвать медленное время отклика сервера. Но здесь я выделю наиболее важные факторы, которые владельцы сайтов могут контролировать.

1. Используйте сеть доставки контента

Начнем с фундаментальной проблемы — расстояния, которое данные должны пройти в обе стороны!

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

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

CDN играет важную роль в производительности, и об этом можно судить по статистике. Давайте посмотрим на некоторые результаты тестов, которые мы провели на веб-сайте с CDN и без него.
Расположение сервера: Сан-Хосе, Калифорния, США. Во-первых, мы проводим тест без интеграции CDN. Время загрузки 633 мс .

После интеграции CDN с сайтом WordPress мы протестировали веб-сайт в том же месте, и время загрузки улучшилось до 523 мс , которое ранее было 633 мс .

Ваш медленный сайт может повлиять на коэффициент конверсии!

Попробуйте Cloudways и максимизируйте производительность вашего WordPress.

Улучши сейчас!

2. Мониторинг трафика веб-сайта

При постоянном росте вашего бизнеса всплески трафика могут стать очень частыми (практически без предупреждения).

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

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

Эксперты рекомендуют выбирать хостинг с функциями мониторинга серверов и приложений. Таким образом, вы можете проверить ресурсы сервера и при необходимости принять незамедлительные меры.

Вы можете анализировать и отслеживать статистику трафика, медленные страницы, запросы к БД, выполнение которых занимает слишком много времени, дисковое пространство и многое другое с помощью функции мониторинга на уровне приложений.

3. Обновление ресурсов хостинга

При запуске онлайн-бизнеса первым делом должен быть проведен тщательный сеанс сбора требований к ресурсам сервера. Это должно дать вам представление об объеме серверных ресурсов, необходимых для запуска бизнеса, а также о будущем прогнозе потребностей в ресурсах.

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

Выберите хостинг-провайдера, который постоянно обновляет свою инфраструктуру и использует новейшее оборудование и обновленное программное обеспечение, такое как серверы PHP 7. 3 и HTTP/2.

Debian 10 доступен на всех серверах Cloudways, запущенных после 12 января 2022 года. Веб-стек Cloudways основан на Ngnix. Это помогает быстро обслуживать больше аудитории, снижая нагрузку на ваш сервер. Кроме того, Cloudways предлагает базу данных MariaDB, поскольку MariaDB является расширенной версией и совместимой заменой эквивалентной версии MySQL.

Кстати, это не всегда самое мудрое решение — использовать самый большой сервер. Эффективное управление ресурсами и применение всех лучших методов разработки и управления сервером также помогут вам сократить время отклика вашего сервера.

4. Оптимизация базы данных WordPress

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

Чтобы устранить проблемы, связанные с базой данных, попробуйте удалить ненужные и устаревшие данные и переписать запросы для более эффективного и быстрого выполнения.

Вы также можете рассмотреть возможность использования советов по оптимизации базы данных WordPress для повышения производительности, включая настройку структуры базы данных и подключаемых модулей WordPress, связанных с оптимизацией базы данных.

У вас может возникнуть вопрос Почему Cloudways предлагает MariaDB, а не MySQL?

MariaDB — это расширенная и совместимая замена эквивалентной версии MySQL. В настоящее время Cloudways поддерживает MySQL 5.5, MySQL 5.6, MySQL 5.7, MariaDB 10.0, MariaDB 10.1, MariaDB 10.2, MariaDB 10.3, MariaDB 10.4, MariaDB 10.5 и MariaDB 10.6.

5. Динамическое и статическое содержимое

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

Статическое содержимое жестко закодировано в HTML, JS, CSS и изображениях веб-сайта. Эти активы не меняются для разных пользовательских входов, и сервер доставляет один и тот же контент каждому посетителю. Это самый быстрый способ доставки контента, так как он не потребляет много ресурсов сервера, а время отклика сервера увеличивается.

Эксперты предлагают выгрузить статический контент в CDN WordPress, чтобы сократить время загрузки и потребление ресурсов сервера.

6. Используйте обновленный серверный стек

Стек сервера серьезно влияет на время отклика сервера. Стек обычно состоит из комбинации серверов и кэш-памяти, которые вместе обеспечивают вычислительную мощность сервера. Популярные компоненты стека включают Apache, NGINX и MySQL/MariaDB.

Не забывайте обновлять версии WordPress и PHP. Старые версии часто требуют больше ресурсов сервера и неэффективны в обработке ответов. Основная команда WordPress рекомендует использовать PHP 8 из-за оптимизированной обработки.

WordPress на PHP 7–8: тесты производительности и руководство по обновлению

7. Выберите оптимизированный хостинг

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

Если вы не разбираетесь в технологиях, выберите высокооптимизированного управляемого хостинг-провайдера WordPress, который решает проблемы с управлением сервером.

Как Cloudways сокращают время отклика?

Cloudways — это управляемая платформа облачного хостинга с оптимизированным стеком серверов, которая идеально подходит для сайтов WordPress. Базовый сайт WordPress, размещенный на Cloudways и установленный Breeze, может быть загружен всего за несколько мс.

Разве это не впечатляет?

Загрузка сайтов WordPress за 37 мс ! Спасибо Лучшему хостингу для WordPress

Расстояние между сервером и посетителями

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

Помните, чем ближе сервер, тем быстрее загружается сайт для аудитории. Для глобальной аудитории используйте CloudwaysCDN.

Трафик

Чтобы справиться с пиками трафика, ресурсы сервера в Cloudways можно масштабировать всего одним щелчком мыши.

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

Опора

Эксперты по облачным технологиям Cloudways доступны круглосуточно и без выходных, чтобы помочь вам. Не стесняйтесь обсуждать и сообщать службе поддержки Cloudways о ваших требованиях / запросах, чтобы они могли помочь вам соответствующим образом.

Базы данных

В настоящее время официальный WordPress поддерживает только MySQL и MariaDB. Учитывая это, мы в Cloudways оставили выбор пользователям WordPress, добавив их на платформу. Преобразование MySQL в MariaDB выполняется одним щелчком мыши.

Динамический и статический

Как описано выше, это решение зависит от пользователя. В Cloudways серверы поставляются с предустановленным PHP 7.4 (как вы читали, последняя версия — PHP 8.0), что значительно повышает динамическую обработку контента. Но вы должны убедиться, что база кода вашего приложения совместима с PHP7. Для этого создайте промежуточную среду WordPress для своего работающего сайта и протестируйте все. Когда вы будете удовлетворены, отправьте изменения в действующую версию. Для статического контента наша формула ThunderStack работает лучше всего!

Серверное программное обеспечение

Серверы Cloudways сочетают в себе Apache, NGINX, Varnish, Memcached, PHP-FPM, Redis и поддержку PHP 8.x. Все это объединяется и повышает производительность сайта WordPress.

TTFB на серверах Cloudways

Ради тестирования я запустил сервер DigitalOcean объемом 2 ГБ (в лондонском дата-центре) со всеми настройками по умолчанию. Затем я установил Breeze, чтобы включить минификацию и группировку.

Затем я запускаю тест через GTMetrix. Вот результаты.

Вы можете видеть, что время до первого байта (TTFB) составляет менее 200 мс, что соответствует рекомендациям Google.

Когда тот же сайт тестируется в Pingdom. Вот что я получил!

Резюме

Повышение общей производительности и сокращение времени отклика сервера для сайта WordPress — это вопрос следования всем передовым методам. Когда вы удовлетворены значением TTFB вашего хостинг-провайдера, вы можете приступить к реализации советов по ускорению сайта WordPress.

Хотите протестировать TTFB вашего существующего сайта WordPress на Cloudways? Начните с бесплатной пробной версии и перенесите свой сайт WordPress всего за несколько кликов. И не забудьте поделиться результатами в разделе комментариев ниже.

В: Как уменьшить время отклика сервера на WordPress?

A: Существует несколько способов сократить время отклика сервера, но наиболее важными из них являются следующие:

1. Модернизация ресурсов хостинга и использование обновленного стека серверов может помочь сократить время отклика сервера.
2. Оптимизируйте то, как ваш сервер запрашивает базы данных.
3. Используйте CDN, если посетители вашего сайта из разных регионов.

В: Как исправить медленное время отклика сервера?

A: В WordPress есть семь способов исправить медленное время отклика сервера. Он может варьироваться от сайта к сайту. Чтобы найти лучшее решение, всегда внимательно читайте рекомендации инструментов проверки скорости, таких как GTMetrix, Pingdom и PageSpeed ​​Insights.

1. Использовать сеть доставки контента
2. Мониторинг трафика веб-сайта
3. Обновление ресурсов хостинга
4. Оптимизация базы данных WordPress
5. Динамическое и статическое содержимое
6. Использовать обновленный стек сервера
7. Выберите оптимизированный хостинг

В: Как проверить, уменьшилось ли время ответа сервера?

A: Протестируйте свой сайт с помощью инструментов тестирования скорости, таких как GTMetrix и Pingdom, и просмотрите раздел результатов.

1. 	28.07.2016 13:28
   	Письмо от Яндекса : При обращении к серверу среднее время ответа превышает 3 секунды. Долгая загрузка страниц затрудняет работу с сайтом. Проверьте ответ сервера и при необходимости свяжитесь с хостинг-провайдером. Письмо от хоста: В рамках услуги виртуального хостинга приемлемым временем ответа считается время до 5 сек. Скачки отклика сервера в пределах рабочего дня являются нормой. Сервера виртуального хостинга настроены для обеспечения максимальной производительности и работают в штатном режиме, нагрузки не наблюдается. Время ответа сервера зависит от того, как организована работа сайта. Видим, что для Вашего сайта не включено сжатие ресурсов с помощью функций gzip или deflate, не используется кеш и не оптимизированы изображения. Рекомендуем обратиться к квалифицированным разработчикам, которые оптимизируют программный код сайта _wstroy.minsk.by. Также если Вы желаете улучшить время отклика сервера, то рекомендуем рассмотреть переход на услугу Cloud Server: _http://www.active.by/ru-by/services/cloudserver/ ———- Сообщение добавлено 13:28 ———- Предыдущее 13:22 ———-Может кто-то расшифрует как решить проблему?
   0

2. 	28.07.2016 13:33
   Super Moderator Репутация: 1574 Webmoney BL: ?	Ну варианта два — либо тормозит сайт, либо хостинг. Сайт стал сам по себе тормозить или всегда так работал? Какие-то изменения производили? Сообщение от free время до 5 сек. У кого хоститесь?
   0

3. 	28.07.2016 14:34
   	Хостинг белорусский Активные технологии, жалобы идут от всех и всегда, но у нас законы такие, приходиться ютиться на нем( Сайт вел себя вроде так всегда, хост конечно полное г…, но и не откидываю сам движок wordpress и плагины. Про рекомендации хостинга. Особо это не когда и не делал, на других сайтах. ———- Сообщение добавлено 14:11 ———- Предыдущее 14:04 ———-И с Директа пишут Согласно данным мониторинга, обнаружены проблемы с доступностью сайта: wstroy.minsk.by (28 июля в 11:41).———- Сообщение добавлено 14:34 ———- Предыдущее 14:11 ———-ответ хоста: Добрый день! В логах доступа к Вашему сайту, расположенных в папке logs в корне Вашей подписки, присутствуют следующие записи: 93.85.140.109 — — [28/Jul/2016:11:41:34 +0300] «GET /price/ HTTP/1.0» 200 51530 «_http://wstroy.minsk.by/» «Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36» 973253 93.85.140.109 — — [28/Jul/2016:11:41:35 +0300] «GET /wp-content/themes/realhomes/images/feature-list-bullet.png HTTP/1.0» 200 1012 «_http://wstroy.minsk.by/wp-content/themes/realhomes/css/main.css?ver=2.5.5» «Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36» 1215 93.84.31.235 — — [28/Jul/2016:11:41:42 +0300] «POST /wp-admin/admin-ajax.php HTTP/1.0» 200 47 «_http://wstroy.minsk.by/wp-admin/post.php?post=25&action=edit» «Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36» 1151479 Это говорит о том, что в 11:41 сервером были успешно обработаны три запроса к Вашему сайту.
   0

5. 	04.08.2016 12:12
   Опытный Репутация: 30 Webmoney BL: ?	Сообщение от free В рамках услуги виртуального хостинга приемлемым временем ответа считается время до 5 сек. Скачки отклика сервера в пределах рабочего дня являются нормой. нормальный такой хостер до 5 секунд, норма? гугл считает нормой до 0,2 секунды, а сайты с ответом сервера более 2 секунд — медленные. Поковыряйтесь в wp, если не поможет (я бы порекомендовал плагины кэширования, но бывают глюки), попробуйте залить на хостинг голый вордпресс на субдомен и посмотреть время ответа на нем, если тоже около 3 секунд — меняйте хостера не задумываясь, скорость работы сайта не самый важный фактор ранжирования, но это работает. сам живу в этой замечательной стране картошки и могу сказать, что с хостингом как повезет. вернее как повезет с сервером и соседями на нем. мы с одним клиентом тоже воевали с эктивом, по итогу поменяли сервер и соседи на сервере попались более адекватные, время ответа стало не супер, но приемлемым.
   1
   Спасибо сказали: free(04.08.2016),

Недавно я описал процесс оптимизации скриптов и стилей на своих сайтах, получилось все хорошо, но вот одна большая проблема осталась — Сократите время ответа сервера, пишет мне добрый Google.

И вправду, задержка перед загрузкой моего сайта про линукс очень большая, намного больше, чем на всех остальных сайтах в несколько раз, и это очень плохо!

Видите первую зеленую длинную линию? Вот такая дикая задержка и мне пока не понятно, чем это вызвано. По ходу написания статьи буду разбираться и чем дольше буду разбираться, чем длиннее будет статья.

Где проверить скорость сайта?

Есть много сервисов, хороших и не очень, простых и сложных, которые предназначены для проверки скорости сайта.

Google Speed Page — текст скорости сайта от самого Гугла, показываем проблемные моменты как для десктопной версии, так и для мобильной. В времени загрузки не указывает.

PR-CY — русский аналог предыдущего теста, скорее всего данные берет именно там, в пользовании удобнее первого.

SiteSpeed — проверка скорости сайта. Мне очень нравится этот тест, не раз его использовал, выдает полную информацию о загрузке всех объектов.

Pingdom Website Speed Test — зарубежный аналог предыдущего сервиса, выдает очень подробную информацию.

Web Page Test — еще один очень подробный тест, которым я не раз пользовался.

MainSpy — показывает время загрузки сайта. Больше никакой информации нет, показывает заниженное время.

Raskruty — очень простенький тест скорости загрузки сайта.

Web Site Optimisation — еще один зарубежный тест скорости ресурса. Выдает подробную таблицу, но вот с кириллице слабовато…

Show Slow — тоже неплохой анализатор скорости сайта. Для работы требует авторизации, но можно войти и через социальные сети.

Red Boot — проверяет доступность и степень сжатия тех или иных компонентов страницы.

Site Speed — показывает время отклика сайта в разных странах. Удобная и важная вещь, особенно, если ваш хостинг находится далеко от ваших целевых посетителей.

Loadimpact — этот сервис не проверяет скорость сайта, а проверяет, какую нагрузку может выдержать ваш сайт. Хотя цель теста в первую очередь другая, но и тут показывается скорость сайта.

Prolog — очень простой и удобный сервис проверки скорости сайта, показывает, что больше всего тормозит сайт.

Если вы знаете еще как проверить скорость загрузки сайта, то напишите о них и я добавлю их в этот список.

Но сначала поставлю на тестируемый сайт небольшой код в подвал, который будет показывать, какое время уходит на генерацию страницы. Вот этот код:

Посмотрим, какое состояние сайта на данный момент:

26 — столько SQL запросов к базе.
1,205022 — за столько сгенерировалась страница.

Это главная страница сайта про линукс. Теперь проверю таким же образом главную страницу этого сайта:

34 — столько SQL запросов к базе.
0,351147 — за столько сгенерировалась страница.

Как видите, запросов к базе данных больше, а скорость генерации страницы в ЧЕТЫРЕ раза меньше. При этом оба сайта на одном сервере, стоят практически одни и те же плагины, правда база данных на этом сайте поменьше, но все базы оптимизированы и весь хлам удален.

Все это приводит к мысли, что сам сервер не виноват, иначе все сайты тормозили бы примерно одинаково. Значит причина может быть в следующем:

1. Есть какой то кривой плагин, который тормозит генерацию страницы.

2. Кривой шаблон и какие то ошибки в верстке мешают нормальной работе.

3. На сайте есть вирус, который тормозит его работу. Как проверить на вирусы сайт читайте по ссылке…

4. Ошибки в базе данных и данные долго считываются.

Даже не знаю, что еще можно предположить, начнем с этого, буду шаг за шагом проверить теории и смотреть на результат.

1. Как вычислить кривой плагин?

Тут все просто: сначала вырубаем СРАЗУ ВСЕ плагины и смотрим на результат:
15 — столько SQL запросов к базе.
0,937074 — за столько сгенерировалась страница.
Как видите, мало что изменилось, а это значит, что плагины не причем. Эта теория проверена, идем дальше…

2. Как проверить шаблон WordPress?

Тут действуем сначала по той же схеме, закачиваем какой-нибудь бесплатный шаблон, вставляем в него наш код и смотрим на результат.
27 — столько SQL запросов к базе.
1,170909 — за столько сгенерировалась страница.
Мда, результат тот же, значит тема не при чем, нужно рыть дальше.

3. Как проверить сайт на вирусы?

Что то я сомневаюсь, что проблема в этом, можно проверить сайт антивирусом айболит, давно не делал такой проверки. Но это все займет много времени. Все же я склоняюсь к мысли, что проблема именно в базе данных, так как при загрузке сайта идет обращение в первую очередь к ней.

4. Как проверить базу данных?

У меня ушли сутки, прежде чем я решил проблему. Сразу хочу показать результат:

29 — столько SQL запросов к базе.
0,168516 — за столько сгенерировалась страница.

Видите разницу? 1,2 секунды или 0,16 секунд? Это разница в ДЕСЯТЬ РАЗ! Как мне этого удалось достичь?

Как я и предполагал, дело было в базе данных. Никакие чистильщики не помогали, и тогда я стал делать все вручную. Очень помогла ВОТ ЭТА СТАТЬЯ, не знал о таких приемах при работе с базой данных.

Первое, что я сделал, это отсортировал таблицы базы данных, чтобы увидеть, что занимает больше всего места. Получилось вот что:

Самыми большими и поэтому вызывающими подозрение были 4 таблицы, в порядке убывания:

post — в этой таблице хранятся все статьи, к ней вопросов быть не может.
options — тут хранятся все настройки и к этой таблице вопросы есть.
postmeta — тут хранятся мета описания к статьям — к ней вопросы есть.
comments — в этом разделе хранятся комментарии, к нему вопросов нет.

Сначала я взялся за таблицу POSTMETA и вычистил из нее немного мусора, в основном кэш, который оставил один плагин. Но все это не помогло. Тогда я взялся за таблицу OPTIONS.

Я установил плагин Clean Options (плагин создан ИСКЛЮЧИТЕЛЬНО для чистки ЭТОЙ таблицы), который нашел у меня более ТЫСЯЧИ осиротевших опций! Я удалил примерно 700 ненужных строк из таблицы, осталось 300, которые кажется нужны.

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

Далее я сделал так: скачал эту таблицу на компьютер и открыл в обычном текстовом редакторе (лучше для разработчиков, у меня в линукс это Geany), сделал перенос строк и сразу увидел, что занимает ОГРОМНОЕ количество места!

Виновником всему был cron! Если не знаете что это, то вот для справки:

cron — демон-планировщик задач в UNIX-подобных операционных системах, использующийся для периодического выполнения заданий в определённое время.

Я ничего не планировал, и я даже не знаю, какой плагин создал столько заданий! Я зашел в PHPMYADMIN и нашел в этой таблице этот раздел, затея я его безжалостно удалил! Таблица сократилась с 3,5 мегабайт до 168 килобайт! После этого сайт стал летать как ошпаренный!

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

Если вы знаете, почему у меня все так вышло и как этого избежать в будущем, то охотно послушаю экспертный совет. А в целом я ОЧЕНЬ рад, так как сутки у меня были мысли только об этом. Осталось только все это сделать на других сайтах, вдруг и там есть эта проблема, пусть и не в таком масштабе? И напоследок похвастаюсь, плагин кэширования отключен:

1,7 секунды — это кажется круто?

Как найти мусор от плагинов?

Нашел еще такой интересный плагин — Plugins Garbage Collector. Он сканирует базу данных и ищет таблицы, которые не принадлежат самому wordpress:

У меня нашлись таблицы, которые уже не используются плагинами, так как я их удалил — в топку! Так тоже можно немного очистить базу данных от мусора.

Как уменьшить время отклика от сервера?

Все это мне очень помогло ускорить сайт, но все же Google Speed сигнализировал мне, что время отклика от сервера очень большое. И виноват в этом не сам сам сервер, так как простые html документы загружаются без всяких задержек, а движок сайта WordPress, который как не ускоряй ракетой не станет. Что же делать?

Проблема решилась легко — установкой на сайт плагином для кэширования и установка плагина, который сжимает стили и скрипты. Но не все было так просто на самом деле, так как далеко не все плагины для кэширования страниц работали так как нужно.

Одни не работали совсем, хотя кэш создавали. Но если некоторые и делали в этом отношении все хорошо, была другая проблема — мобильная версия сайта. Если в плагине кэширования нет разграничения между мобильным и обычным кэшем, то вы столкнетесь с такой проблемой.

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

Из всех плагинов, которые имели разделения между мобильным и обычным кэшем, я нашел лишь один — HYPER CACHE.

В этой вкладке нужно вот так выставить настройки, чтобы мобильная версия сайта кэшировалась отдельно. После этого время проблема времени отклика от сервера исчезла.

До 100/100 в Google Speed мне осталось совсем немного и уверен я достигну этого результата, так как почти все уже сделано, осталось совсем немного…

Если вам интересна тема создания и продвижения сайтов, то без постоянного обучения не обойтись. Вот интересные книги на данную тему: