Почему возрастает время ответа от сервера

Каким должно быть время ответа сервера?

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

Что значит «время ожидания ответа сервера» и каким оно должно быть?

Речь идет о параметре TTFB. Эта аббревиатура расшифровывается как Time-to-first-byte, что в переводе означает «время до получения первого байта». Это тот момент времени, когда сервер отвечает на изначальный запрос клиента.

Такая проверка. Установка первоначального соединения между браузером и сайтом. Чем меньше длится процесс подключения, тем лучше. Причем как для сервера, так и для клиента. Пользователь сразу получит данные, за которыми пришел, а сайт будет на хорошем счету у поисковых машин. Важно удерживать этот показатель в пределах 400 миллисекунд. Это некий стандарт. Но если получится сократить до 100, то надо это сделать. Нижнего предела нет.

Помимо TTFB (времени ответа сервера), есть и «время дозагрузки контента». Часть советов из этой статьи помогут сократить и его тоже. Сразу замечу, что это субъективный параметр, зависящий от десятка критериев, влияющих на конечный результат. Скорость может сократиться или увеличиться от расположения дата-центра, где хранятся файлы, относительно клиента, до мощности устройства, с которого заходят на страницу.

Почему этот параметр так важен для оптимизации сайта?

Как я уже сказал выше, TTFB полезен и людям, и «машинам».

С человеческим и поведенческим факторами все предельно логично:

Пользователи не станут ждать загрузки сайта по 8–10 секунд. Они уйдут к конкурентам уже спустя 4.
Посетители сайта быстрее получат нужную информацию и охотнее задержатся на нем, если все работает быстро.

С технической точки зрения все менее логично, но не менее важно:

Google, Яндекс и их аналоги учитывают время загрузки сайтов при их ранжировании. Поэтому медленные ресурсы оказываются на второй-третьей-десятой странице поисковой выдачи.
Оптимизировав сервер и увеличив скорость его работы, можно снизить нагрузку на «железо».

Почему возрастает время ответа от сервера?

Есть шесть направлений, в которых надо размышлять. Проблемы таятся в:

неправильно выбранном типе сервера (Apache вместо Nginx) ;
использовании OpCache для ускорения PHP-скриптов;
запросах к базе данных;
неправильно настроенной логике скриптов;
недоступности сторонних сервисов, на которые полагается сайт;
сбойных плагинах или темы WordPress.

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

Apache

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

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

Отсутствие модулей кэширования

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

Некорректно настроенная база данных

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

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

Сложная логика обработки данных

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

Отправление запросов в сторонние сервисы

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

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

Плагины и темы, пожирающие все ресурсы

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

Плохой хостинг

Ответственность за медленные сайты можно переложить на провайдера. Если очевидно, что проблемы на стороне «железа», то стоит задуматься о переходе на другой хостинг. Каждый провайдер предлагает тестовый период хотя бы на пару дней. Можно перенести сайт к другому провайдеру и посмотреть, как он работает, провести пару тестов.

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

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

Яндекс.Вебмастер

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

Указываем ссылку в поисковом поле на главной странице.
Затем жмем на кнопку «Проверить».

Вебмастер покажет базовую информацию о вашем веб-ресурсе. Но главное — время ответа сервера. У нас — это 236 миллисекунд. И сигнал ОК. Статус HTTP — 200.

WEBO Pulsar

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

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

Скрипт для проверки времени ответа

Надо прописать в index.html (в футер) код, прописанный ниже:

Здесь важно оценивать радикальные изменения. От 2 секунд и больше.

Как уменьшить время ответа сервера?

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

Удалить проблемные плагины

Первое, что надо проверить – все дополнения, которые вы используете в своей CMS. Все, что стоит поверх условного WordPress, надо проанализировать. Любой плагин может криво встать и заметно снизить скорость работы сайта.

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

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

Поменять шаблон сайта

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

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

Проверить сервер на наличие вирусов

Вирусы могут напасть на устройство, подгрузить его, отобрать ресурсы. Из-за этого упадет скорость загрузки сайта. Проверить сервер на вирусы можно несколькими способами – либо через онлайн-сервис, либо через скрипт, встраиваемый в index.html.

Есть такая вещь, как Antivirus Alarm. Простенький сайт с поисковой строкой. Вводим в него адрес страницы, которую нужно проверить, и ждем. Сайт покажет все угрозы, которые сможет найти. Правда, находит он мало.

С серьезными подозрениями лучше использовать решения посерьезнее. Например, AI-Bolit. Облачный антивирус показывает подозрительные переадресации, хакерские скрипты, незащищенные директории.

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

Похожее: Тест Правительство Российской Федерации

Почистить базу данных (на примере WordPress)

Есть две таблицы, за которыми стоит наблюдать тщательнее, чем за остальными:

options, где лежат настройки;
postmeta, где лежат мета-теги к единицам контента на сайте.

Трогать post и comments необязательно. Там будет контент и комментарии.

В postmeta надо удалить весь бесполезный кэш, что удастся найти руками. Не факт, что поможет, но процедура сама по себе полезная. Потом надо почистить options. Это можно сделать специальным плагином — Clean Options. Он разработан для работы конкретно с этой таблицей. Он оже вынесет кучу мусора. Кэш от сторонних дополнений может поедать ресурсы и занижать производительность.

Еще есть Plugins Garbage Collector, который вычищает хлам, который остается от других плагинов. Ну и HYPER CACHE, который сжимает все скрипты и CSS-файлы.

Выключить cron-демон

cron — это планировщик задач для Linux. В него можно прописать любые процессы, которые будут автоматически запускаться в указанное время. В базе данных есть отдельная таблица под cron. Можно через phpMyAdmin открыть ее и стереть ненужные задачи.

Их там может быть с несколько сотен и тысяч. Такая таблица может весить несколько мегабайт и увеличивать время ответа сервера секунд на 8.

Если не пользуетесь планировщиком или в нем мало задач, то можно удалить все связанное с cron. Проще будет настроить все заново, чем разгребать то, что могло накопиться ранее.

Перенести скрипты в нижнюю часть страницы

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

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

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

Установить WordPress-плагин для сжатия данных

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

Установить плагин Cloudflare для кэширования страниц

Хороший плагин для кэширования есть у компании Cloudflare. Не так давно они запустили собственный сервер, на котором пользователи WordPress-сайта могут за 5 долларов в месяц разместить свой сайт (его кэш). Это ускоряет отклик сервера на 71%. Принцип работы прост – в аш сервер используется только для контакта с Cloudflare и обновления контента на нем. А пользователи видят и взаимодействуют с тем, что лежит на серверах Cloudflare. Их железо однозначно быстрее, поэтому сервис заметно сократит время ответа сервера.

Смена хостинга

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

1 из 9 методов сработает. Нерешаемых проблем с производительностью веб-ресурсов не бывает.

Источник

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

Nginx – это быстрый и легкий веб-сервер, альтернатива Apache 2. Конечно же, как и любой сервер, для оптимальной производительности Nginx нуждается в тонкой настройке.

Требования

Для выполнения данного руководства понадобятся:

новый сервер Debian 7. Чтобы получить инструкции по начальной настройке такого сервера, читайте данную статью.
установленный и настроенный Nginx. Необходимые инструкции можно найти в статьях “

Директивы worker processes и worker connections

Первые переменные, которые нужно отладить, – worker processes и worker connections.

Директива worker_processes – основа работы Nginx. Она сообщает виртуальному серверу о запущенных рабочих процессах при подключении к правильному IP-адресу или порту. Как правило, на ядро запускается 1 рабочий процесс. Большее количество таких процессов не повредит систему, но может стать причиной простаивания процессов.

Чтобы определить необходимое количество процессов, которое нужно установить в worker_processes, просто посмотрите на количество ядер. Изменив размер сервера, не забудьте проверить количество ядер и соответствующим образом отредактировать значение директивы worker_processes. Чтобы узнать количество ядер, выполните команду grep на cpuinfo:

grep processor /proc/cpuinfo | wc -l

К примеру, если данная команда вернула значение 1, то это значение нужно внести в worker_processes.

Директива worker_connections сообщает директиве worker_processes, сколько пользователей могут одновременно обслуживаться Nginx. Значение по умолчанию – 768. Однако, учитывая, что каждый браузер обычно открывает, по крайней мере, 2 соединения, этого может быть недостаточно. Именно поэтому нужно настроить worker_connections на полную силу. Чтобы проверить ограничения ядра, используйте команду ulimit:

На небольшом сервере (512 Мб) данное значение ограничивается 1024, чего вполне достаточно для начала.

Теперь нужно обновить конфигурационный файл:

sudo nano /etc/nginx/nginx.conf
worker_processes 1;
worker_connections 1024;

Запомните: количество клиентов, которые могут быть обслужены, можно умножить на количество ядер. В этом случае можно обслуживать1024 клиентов в секунду. В дальнейшем это значение уменьшает директива keepalive_timeout.

Буферы

Размер буфера – следующий невероятно важный аспект, который требует тонкой настройки. Если размер буфера слишком мал, то Nginx придется писать во временный файл, из-за чего диску придется постоянно считывать и записывать. Прежде чем принимать какое-либо решение, нужно учесть некоторые директивы.

client_body_buffer_size: данная директива обрабатывает размер буфера клиента, то есть любые POST-запросы, отправленные на Nginx.

client_header_buffer_size: эта директива подобна предыдущей, только вместо размера буфера она обрабатывает размер заголовка клиента. Для всех целей 1K, как правило, достаточно.

client_max_body_size: максимально допустимый размер запроса клиента. Если максимальный размер превышен, то Nginx выведет ошибку 413 (Request Entity Too Large).

large_client_header_buffers: максимальное количество и размер буферов больших заголовков клиентов.

client_body_buffer_size 10K;
client_header_buffer_size 1k;
client_max_body_size 8m;
large_client_header_buffers 2 1k;

Время ожидания

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

Директивы client_body_timeout и client_header_timeout отвечают за интервал времени, на протяжении которого сервер будет ждать тело запроса или заголовок запроса от клиента. Если ни тело или заголовок не были получены, сервер выдаст ошибку 408 (Request time out).

Директива keepalive_timeout устанавливает лимит времени ожидания Keep-Alive соединения с клиентом. Проще говоря, Nginx закроет соединения с клиентом по истечении этого периода времени.

Директива send_timeout ограничивает время ответа клиенту. Она устанавливается не на всю передачу ответа, а только на две операции чтения; если по истечении этого времени клиент ничего не примет, то Nginx прервет соединение.

client_body_timeout 12;
client_header_timeout 12;
keepalive_timeout 15;
send_timeout 10;

Сжатие Gzip

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

gzip on;
gzip_comp_level 2;
gzip_min_length 1000;
gzip_proxied expired no-cache no-store private auth;
gzip_types text/plain application/x-javascript text/xml text/css application/xml;

Кэширование статических файлов

Можно также настроить выдачу заголовков Expires для файлов, которые не меняются и обслуживаются регулярно. Эту директиву можно добавить к существующему блоку server Nginx.

* .(jpg|jpeg|png|gif|ico|css|js)$ <
expires 365d;
>

Не забудьте добавить необходимые типы файлов в вышеприведенную строку (и удалить ненужные).

Журналирование

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

Сохраните и закройте файл, а затем запустите:

sudo service nginx restart

Итоги

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

Источник

как рассчитать среднее время обработки в nginx

Я хочу рассчитать среднее время обработки запросов, проходящих через nginx. В частности, было бы здорово получить различные процентили. И было бы еще лучше, если бы я мог получить их по HTTP-методу (post / get и т. д.).

У меня есть куча плохих / не очень хороших решений:

откажитесь от nginx и сделайте математику из журналов балансировщика
отображать время обработки каждого запроса в журнале доступа nginx, отправлять его, а затем обрабатывать (или просто делать это локально с помощью cron / bash).

Но должен быть лучший способ сделать это.

2 ответа

Думаю, я нашел хорошее (и бесплатное!) Решение: комбинацию nginx, nginx-statsd-module и statsd. Общая идея состоит в том, чтобы использовать модуль nginx-statsd для передачи времени обработки от nginx на сервер statsd (а оттуда в любой механизм сбора данных, который вы используете).

С модулем statsd (https://github.com/kinecosystem/nginx-statsd), вы можете настроить nginx для выдачи времени обработки для каждого метода HTTP, для каждого местоположения nginx:

Результаты, напечатанные statsd, выглядят примерно так:

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

Также я пытался получить различную статистику по производительности Nginx. Существует несвободный nginx-ampify-doc, который может дать вам то, что вы хотите. Я не уверен, какова там ценовая политика — Я проанализировал журналы доступа, потому что не хотел платить за такую услугу.

Источник

Время отклика страницы

Подскажите, пожалуйста, в какую сторону смотреть? Спасибо!

/etc/nginx/nginx.conf

/etc/nginx/users/u00001.conf

Apache Server MPM: ITK

/etc/apache2/apache2.conf

/etc/apache2/users/u00001.conf

/etc/mysql/my.cnf

/proc/user_beancounters

По статистике /proc/user_beancounters заголовки:

Где limit пустой получился — там held = 0

Как тестировалось? Какая загрузка cpu при тестировании?

Сами посмотрите что дольше всего отрабатывает. Попробуйте статику/php подергать В mysql можно врубить slow log и поглядеть будет ли туда чтото валиться. Для php прикрутить memcache да много чего наворотить можно, хоть чтолибо продебажте и определите «узкое место»

Т.е. конфигурация в общем нормальная?

Тестировалось панелью производительности Битрикс

Нагрузка на процессор ощутимая За минуту теста load average: 20.24, 6.07, 2.09 И во время него в top много apache2 процессов, которые по 10-20% CPU

Интересно ещё то, что пробовал тот же тест на хостинге, там при 32 соединениях аж 1700 хитов!

memcache прикручен, но используется только на хранение сессий

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

зарегайся в newrelic, подключи себе триалку с полным функционалом — она тебе покажет о твоем приложении всё, включая статистику — сколько времени уходит на какой mysql-запрос, сколько на БД в общем, на обработку в PHP, на мемкеш, на внешние сервисы, загрузку disk IO на сервере.

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

Битрикс — неплохая штука, но дело не в этом

На хостинге при тех же 32 соединениях 1700 хитов, как писал выше, и время отклика 0.02 сек

А эталон у них 0.03 вообще 🙂 это при тестах процессора и др. тоже время отклика есть. Там-то и у меня 0.04, но это не при нагрузке

Сейчас заценю что это!

Настройки нжинкса те же? Такие результаты можно получить, только при включенном кеше нжинкса. Или при неработающей странице 🙂

Не, мне не нужно тестировать приложение 🙂

На хостинге и у меня Битрикс, только там ещё сайт полноценный, а у меня голая минимальная редакция, так что не в коде дело, а в самом сервере

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

NR покажет тебе примерно следующее:
на PHP потрачено: сколько-то процентов времени
на MySQL: сколько-то
на Memcached: сколько-то
на внешние сервисы (типа запрос лицензии с сервера битрикса и т.п вещи): сколько-то

время загрузки страницы он разобьет тебе на App server, Network, DOM Processing и Page render, покажет какие классы/процедуры в php-коде занимают сколько времени, время выполнения каждого запроса в мускуле, статистику по серверу (cpu, disk IO, memory) тоже. короче это реально комплексный мониторинг, но жутко дорогой.

Сорри, это я лошок!

Системный тест выполнял (оставил путь пустым) и там, и там
На хостинге указал сейчас главную страницу

32 70 23.33 3.038560 3.075850

Вот это уже реальнее, а то я сам что-то удивился 😀

Пjлучается 100% дело в настройках сервера, т.к. при том же системном вызове там 1700 хитов и 0.02, а у меня 200-300 и 0.4-0.6 ;(

А в эталонных 0.03 — это «Среднее время отклика», т.е. не всей страницы, а видимо обращается и к статике, и скрипт, все делит на общее кол-во, как-то так, наверное

Источник

TTFB, или время ответа сервера: как увеличить скорость загрузки сайта

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

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

Хотите получать дайджест статей?

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

Что такое TTFB (Time to First Bite)

Начнем с теории. Time to First Bite (или сокращенно TTFB, оно же – время ответа сервера) – характеристика, которая обозначает временной интервал до получения самого первого байта страницы, сразу после отправки соответствующего запроса. Чем меньше значение TTFB, тем лучше и быстрее загружаются страницы сайта.

Время ответа сервера тесно связано со временем отправки запроса и временем получения ответа:

Хорошее время отклика – от 250 до 350 миллисекунд, приемлемый отклик – до 500 миллисекунд. Все, что больше, определяется как долгий отклик, и в отчете Google PageSpeed Insights это будет обозначено как проблема.

Проверяем TTFB на своем сайте

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

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

Webpagetest.org

Удобный и функциональный сервис для проверки TTFB с возможностью выбора браузера и местоположения. Возможность выбрать ГЕО – нужная функция во многих случаях. Дело в том, что скорость загрузки сайта зависит не только от внутренних, но и от внешних факторов. К последним относят локацию сервера и его удаленность от конечного сервера. Во многих случаях нужно проверять скорость загрузки сайта из определенного региона, так что сервис в этом плане весьма удобен.

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

При необходимости – выбираем локацию (+ устройство):

Нажимаем Start Test:

Тест займет от десятка секунд до нескольких минут. Интересующая нас характеристика будет отображаться в самом первом столбце – First Byte:

Мне нравится, что Webpagetest позволяет использовать дополнительные настройки. Например, можно выбрать тип подключения (по кабелю, кастом, несколько вариаций 3G, 4G и LTE, DSL):

Для более точного тестирования и выполнения специфических задач можно заблокировать Java Script, очистить кэш SSL-сертификата, захватить tcpdump, можно добавить кастомный хедер или выполнить собственный скрипт:

Приятно, что есть пакет настроек Chromium:

Можно задать правила для авторизации с логином и паролем:

Есть возможность добавить собственный скрипт:

Можно симулировать сбой определенного домена:

Также есть функция, позволяющая заблокировать требуемые домены:

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

РаgeSpeed Insights

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

Чтобы проверить время до получения первого байта страницы, необходимо указать домен в поисковой строке и нажать кнопку «Анализировать»:

Будут указаны результаты имитации загрузки страницы и сопутствующие данные:

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

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

Если существуют проблемы со временем ТТFB, будет отображаться рекомендация «Сократите время ответа сервера». В нашем случае все нормально:

Инструменты браузера

Чтобы проверить время до получения первого байта страницы, можно воспользоваться встроенным отладчиком в браузере. Он есть в Google Chrome и Mozilla Firefox. В обоих браузерах он вызывается аналогичным образом: при помощи F12 или сочетания горячих клавиш Ctrl + Shift + I.

Покажу, как найти показатель TTFB в браузере Mozilla Firefox:

1. запускаем отладчик;
2. выбираем пункт «Сеть» (либо – Network);
3. нажимаем клавишу F5;
4. выбираем фильтрацию HTML (цифрами на скриншоте обозначен порядок выбора пунктов для попадания в необходимый раздел)

5. Смотрим раздел «Тайминги»:

Указанное значение и есть искомый нами ТТFB.

Netpeak Spider

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

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

Google Analytics

Аналитика Google – это удобный и функциональный инструмент для получения детальной статистики по всем посетителям сайта. Она также позволит узнать скорость загрузки вашего сайта – для этого необходимо обратиться в раздел «Поведение» – «Скорость загрузки сайта» – вкладка «Обзор»:

Нас интересует параметр, выделенный красным прямоугольником:

Основные причины продолжительного ответа сервера

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

Итак, наиболее часто встречаются четыре проблемы, приводящие к росту TTFB:

сайт не использует кэширование;
не оптимизирована работа с БД;
некорректно настроен сервер;
недостаточная производительность системы (со стороны устройства посетителя сайта).

Как уменьшить TTFB

Чтобы уменьшить TTFB, необходимо устранить бо́льшую часть найденных ошибок из отчета PageSpeed Insights. Да, сервисов для оценки TTFB много, но PageSpeed Insights дает практические рекомендации – что именно нужно сделать, чтобы ускорить сайт, с позиции Google. После проработки всех замечаний в отчете PageSpeed Insights скорость загрузки веб-ресурса должна заметно вырасти.

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

Кэширование страниц

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

Когда я создавал первый сайт, время загрузки страниц на нем было вполне приемлемым. Но по мере того, как сайт стал разрастаться (появлялись новые страницы, обновлялась коллекция медиафайлов), скорость загрузки значительно снизилась. После включения серверного кэширования мне удалось понизить TTFB вдвое

Оптимизация БД

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

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

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

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

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

PHP-расширения

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

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

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

Zend OPcache;
APC;
XCache;
eAccelerator;
WCE (Windows Cache Extension);
PhpExpress.

Серверные ограничения

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

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

дисковая квота;
нагрузка на базу данных;
разрешенная статическая нагрузка;
почтовая квота.

Комментирует отдел разработки TexTerra

Михаил Половодов web-тестировщик в отделе разработки сайтов TexTerra

Для быстрой загрузки сайта важны три основные переменные:

1. содержимое сайта;
2. сторона сервера;
3. сторона пользователя.

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

Со стороны содержимого сайта замедлять загрузку может:

1. JavaScript

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

Решение: оптимизировать, избавиться от лишнего кода. Задействовать асинхронную загрузку, которая не зависит от загрузки остальных элементов страницы. Также можно разместить крупные скрипты в заключительной части кода страницы, перед </body>. Не допускать конфликта элементов страницы с кодом скриптов. Также рекомендуется задействовать минифицированные (сжатые) версии JS-файлов.

2. CSS

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

3. Избыточное количество плагинов и модулей

Если сайт разработан с применением CMS, то на поддержание стабильной работы здесь тоже необходимы ресурсы – память. За каждым плагином или модулем может храниться массив данных, который иногда бесполезен и с течением времени будет только замедлять загрузку сайта, так как, разрастаясь, сайт будет требовать больше памяти для утоления «аппетита».

4. Кэш

Тут есть несколько путей оптимизации. Например, задействование сторонних ресурсов (по типу CDN-систем) и/или оптимизация настроек хранения кэша в браузерах пользователей и/или на сервере.

5. Изображения

Существует несколько форматов изображений, которые и по-разному весят, и по-разному воспринимаются браузерами. Есть однозначно применимый совет ко всем форматам: сокращайте размер загружаемых изображений, так как как они занимают место на сервере и довольно-таки сильно влияют на загрузку страниц. Для оптимизации изображений существует множество сервисов, плагинов, которые существенно уменьшают вес, но при этом изображения минимально теряют в качестве (за счёт удаления EXIF-данных, некоторых цветов). Одним из последних актуальных форматов для использования изображений является WebP. Также можно использовать сжатый формат PNG.

6. Реклама

Обилие баннеров, попап-окон, видеороликов в состоянии серьезно нагрузить сайт HTTP-запросами. Рекомендую, если задействуете рекламу, делать это в умеренном количестве. Здесь речь еще и о реакции пользователей.

Со стороны сервера подводить может:

1. Хостинг

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

2. Отсутствие компрессии файлов в обмене данными

Gzip-компрессия поможет скомпоновать в архив и отправить запросившему браузеру данные сайта: стили, JS, изображения и прочее.

3. Вирус

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

Со стороны пользователя подводить может:

1. Устройство

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

2. Браузер

Разросшийся кэш, масса установленных расширений, которые грузят устройство.

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

Если вы недовольны скоростью работы вашего сайта и не знаете, как это исправить, обратитесь за консультацией к специалистам TexTerra. Мы работаем со всеми популярными CMS, а среди наших клиентов – «Ростелеком», «ВТБ» и «СДЭК».

Источник