Каким должно быть время ответа сервера?
Хороший сайт — быстрый сайт. Все интернет-ресурсы должны быть отзывчивыми, иначе они вмиг потеряют аудиторию и станут неинтересны потенциальным пользователям. Поэтому в данной статье мы говорим о том, как долго можно ждать отклик от сервера и почему важно ускорять свой сайт всеми доступными способами.
Что значит «время ожидания ответа сервера» и каким оно должно быть?
Речь идет о параметре 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 это отличный веб-сервер, который уже давно зарекомендовал себя, как надежное решение даже для больших проектов. Несмотря на то, что nginx отлично работает из коробки, рекомендую проделать некоторые настройки по оптимизации, которые уменьшат время ответа сервера.
Не забывайте, что после внесения изменений необходимо проверять их корректность командой:
А чтобы применить настройки, необходимо перезапустить nginx:
Сжатие GZIP
Один из самых эффективных методов ускорить ответ от вашего веб-сервера nginx — это включить GZIP сжатие.
gzip включает сжатие.
gzip_min_length устанавливает минимальную длину ответов, для которых будет применяться сжатие. По умолчанию 20, но имеет смысл поставить больше, так как постоянное сжатие приведет к повышению нагрузки на процессоры сервера и клиента.
gzip_proxied перечисляет параметры проксированных запросов, для которых будет разрешено сжатие.
gzip_types по умолчанию включено сжатие для ответов типа текст. В данном параметре можно перечислить все необходимые типы ответов.
gzip_disable запрещает для перечисленных параметров заголовка User-Agent сжатие. В данном примере для Internet Explorer 6 сжатие применяться не будет, так как данный браузер не умеет принимать сжатые ответы.
Кэширование
Еще один способ увеличить скорость ответа — это включить кэширвоание на стороне клиента.
Оптимизация работы соединений
Настроим несколько основных параметров, которые отвечают за количество обрабатываемых соединений и сроки их поддержания.
worker_processes — Определяет количество рабочих процессов. Обычно, выставляют равному числу ядер, но в новых версиях его лучше устанавливать в auto. По умолчанию 1
worker_connections — Устанавливает максимальное количество соединений одного рабочего процесса, то есть nginx будет обрабатывать worker_processes * worker_connections , остальные запросы ставить в очередь. Следует выбирать значения от 1024 до 4096. По умолчанию 512.
multi_accept — Позволяет принимать максимально возможное количество соединений. Иначе, процесс nginx за один раз будет принимать только одно новое соединение. По умолчанию off.
keepalive_timeout — Отвечает за максимальное время поддержания keepalive-соединения, в случае, если пользователь по нему ничего не запрашивает. Для современных систем, стоит выставить от 30 до 50. В нашем случае 45. По умолчанию 75.
reset_timedout_connection — Если клиент перестал читать страницу, Nginx будет сбрасывать соединение с ним. По умолчанию off.
client_body_timeout — Ждет выставленное количество секунд тело запроса от клиента, после чего сбрасывает соединение. По умолчанию 60.
send_timeout — Если клиент прекратит чтение ответа, Nginx подождет выставленное количество секунд и сбросит соединение. По умолчанию 60.
Оптимизация работы с файлами
sendfile позволяет использовать более совершенный системный вызов, который обеспечивает прямую передачу файла, то есть без системных вызовов read + write.
aio включает использование асинхронного обращения к файлам, что избавит от очередей запросов.
tcp_nopush позволит передавать заголовок ответа и начало файла в одном пакете.
open_file_cache по умолчанию выключена. Задает настройку для кэширования информации о файлах, с которыми работает nginx. По умолчанию выключено.
open_file_cache_valid задает время, через которое веб-сервер будет проверять актуальность данных. По умолчанию 60 секунд.
open_file_cache_min_uses задает минимальное число обращений к файлу, чтобы дескриптор файла оставался открытым в кэше.
open_file_cache_errors включает или выключает кэширование ошибок.
Безопасность
Помимо уменьшения времени отклика веб-сервера, необходимо позаботиться о безопасности. Разберем основные http заголовки, которые могут представлять угрозу.
X-XSS-Protection
Заголовок X-XSS-Protection может предотвратить некоторые XSS-атаки.
Вы можете реализовать защиту XSS, используя три варианта в зависимости от конкретной потребности.
- X-XSS-Protection: 0; Это полностью отключит фильтр
- X-XSS-Protection: 1; Это включает фильтр, но очищает только потенциально вредоносные скрипты
- X-XSS-Protection: 1; mode = block; Это включает фильтр и полностью блокирует страницу.
X-Frame-Options
Заголовок X-Frame-Options позволяет снизить уязвимость вашего сайта для clickjacking-атак. Этот заголовок служит инструкцией для браузера не загружать вашу страницу в frame/iframe. Не все браузеры поддерживают этот вариант.
Настроить X-Frame-Options можно тремя способами:
- DENY : это полностью отключит функции iframe.
- SAMEORIGIN : iframe может использоваться только кем-то из того же источника.
- ALLOW-FROM : Это позволит размещать страницы в окнах iframe только с определенных URL-адресов.
X-Permitted-Cross-Domain-Policies
Аналогично механизму браузеров блокировки стороннего контента Adobe Flash имеет свой. Он регулируется файлами crossdomain.xml сайта, начиная с корневого каталога. Проблема с механизмом в том, что на любом уровне вложенности корневой регулирующий файл (политика безопасности) может быть переопределен. Чтобы избежать таких ситуаций, необходимо задать этот HTTP-заголовок.
Доступно несколько вариантов настройки:
- none — никакая политика не допускается
- master-only — разрешить только главную политику
- all — все позволено
- by-content-only — Разрешить только определенный тип контента. Пример — XML
- by-ftp-only — применимо только для FTP-сервера
Strict-Transport-Security
Заголовок Strict-Transport-Security запрещает использование незащищенного HTTP соединения на сайте, если есть защищенное HTTPS.
X-Content-Type-Options
Рейтинг наиболее опасных к использованию возможностей браузера возглавляет возможность Internet Explorer «угадывать» тип файла, игнорируя его MIME-тип.
При передаче от сервера к браузеру все файлы имеют тот или иной тип, который прямо указывает на суть содержимого файла. Однако, Internet Explorer имеет встроенный механизм, который позволяет по-содержимому файла переопределить его тип.
Таким образом, обычные текстовые файлы могут быть интерпретированы как JavaScript со всеми вытекающими последствиями. Например, если у вас на сайте запрещена загрузка текстовых файлов с расширениями .js пользователями, то они могут загрузить в виде картинок текстовый файл, содержащий JavaScript-код, который может быть исполнен браузером.
Подводя итог
Вот и все, потратив немного своего времени, вы ускорили загрузку вашего сайта для клиентов, а также немного обезопасили его от некоторого вида атак.
Источник
10 рабочих способов по сокращению времени ответа сервера
Появление Java-технологий навсегда изменило формирование дизайнов сайтов. Появились разные виды выплывающего меню, живые обои, дополнительное видео и графика. Эти нововведения привели к увеличению объема сайтов, что в свою очередь негативно повлияло на время их загрузки, незвисимо от того, на wordpress они или другой cms.
Фактически скорость загрузки сайтов равняется времени его отображения на экране браузера. Но этот процесс можно условно поделить на несколько отдельных этапов, каждый из которых имеет влияние на окончательный результат:
- Подключение к стороннему серверу;
- Получение ответа;
- Загрузка всей информации сайта (включая графику, видео, изображения и т.д.);
- Отображение страницы в окне браузера (компиляция).
Оптимальное время загрузки сайта
На этот вопрос нет однозначного ответа. Ведь все сайты имеют разный объем информации, следовательно, разное время загрузки. Задача владельца страницы как раз состоит в том, чтобы максимально уменьшить это время.
Идеальным вариантом считается тот, при котором страница загружается менее, чем за одну секунду. Но в некоторых особо тяжелых случаях результат в несколько секунд можно тоже считать оптимальным. Конечно же все зависит не только от размера сайта. Расположение сервера, скорость интернета пользователя, задачи веб-сайта – все это имеет важное значение для скорости загрузки страницы.
Множество корпораций проводили свои исследования в области замеров скорости загрузки. И все они закончились ожидаемым результатом. Ведь сокращение времени загрузки сайта даже на полсекунды в большинстве случаев давали отличные результаты:
- Большую конверсию;
- Увеличение времени просмотра;
- Увеличение чека и выручки в целом;
- Улучшение ранжирования в поисковиках;
- Меньшее количество отказов.
Все эти показатели имеют прямое влияние на прибыльность ресурса. Существует сервис (https://www.sharpedigital.com/seo/speed-conversion-rate-tool/), который показывает конверсию сайта относительно скорости загрузки.
Решение проблем со скоростью загрузки страницы
В первую очередь нужно уменьшить время ответа сервера. Чаще всего для проверки результатов используется сервис ping-admin.ru или webpagetest.org (здесь отсутствуют наши сервера, но для сравнения результатов он тоже подходит). Они подходят для сайтов с разными cms wordpress, joomla и другие.
Результат с ping-admin.ru до правок
Результат с webpagetest.org до правок
Время загрузки HTML
Результат с webpagetest.org до правок
Время полной загрузки страницы (включительно с фото- и видеоматериалами)
Как видим, результаты сайта довольно слабые. Время ответа сервера заняло больше одной секунды, а на отображение страницы ушло около 7 секунд. И того, десять секунд ожидания. Даже для популярного сайта это очень большой результат.
Способы сокращения количества запросов к серверу
Для того чтобы сократить время ответа сервера, необходимо провести ряд действий:
- Определить по логам самых затратных по времени операций. Далее следует исправление и удаление лишних. Упрощение серверной логики.
- Сократить базу данных. Удаление «мусора».
- Включить Gzip сжатие на сервере для поточного архивирования текстовых данных.
- Расширить кеш для CSS и JavaScript.
- Объединение всех стилей JavaScript и CSS в один файл (точнее в два файла – каждый для своего формата).
- Сократить порядок загрузки (стили CSS→ контент→JavaScript).
- Уменьшить код JavaScript и CSS (удаление пробелов и комментариев).
- Внедрение HTTP/2 для одновременной обработки большего количества запросов.
- Подключение Lazyload (загрузка изображений только во время прокрутки до них).
- Для того чтобы избежать двойной отрисовки отдельных частей элементов дизайна, необходимо перенести стили CSS с тела страницы в head.
- Согласование МЕТА-тегов с HTTP-заголовками.
- Внешне подключенные стили CSS и JavaScript необходимо перенести в общий файл стилей сайта. Это сократит общее количество запросов.
- Смена абсолютных URL на относительные (название сайта.ru/page→/page)
- Использование поддоменов для распределения части контента. Это позволяет сократить расстояние сервера и пользователя.
- Уменьшить размер изображений (сжатие).
- Связывание nginx и Apache. Это повышает скорость вычисления сервера.
- Настройка OPcache.
Результаты оптимизации
Результат с ping-admin.ru после правок
Результат с webpagetest.org после правок
Как видите, в результате подобных манипуляций удалось сократить время ответа сервера почти в десять раз: с одной секунды до 12 миллисекунд.
Результат с webpagetest.org после правок
Удалось уменьшить время отображения страницы на 5,8 секунд. Полная загрузка сайта составила чуть больше трех секунд.
Итоги
Если обобщить весь список проделанных манипуляций, то можно выделить некоторые общие действия:
- Оптимизация и настройка сервера;
- Уменьшить количество запросов, что позволит сократить время ответа сервера;
- Сжатие всей информации на странице (изображения, видео, скрипты);
- Использование облачных сервисов для распределения общей нагрузки.
Выше показаны не все способы увеличения скорости работы сайта. У каждого ресурса могут быть свои проблемы, но выше перечисленные действия можно считать самыми эффективными. Скорость работы сайта имеет прямое влияние на серию важных показателей, таких как:
- Ранжирование сайта в поисковике.
- Конверсию.
- Количество отказов.
- Размер получаемой прибыли.
Фактически перед владельцем сайта или оптимизатором стоит задача сократить объем сайта, что производит к увеличению скорости отображения.
Источник
Как проверить время ответа сервера и уменьшить его
Что такое ответ сервера (TTFB) и как понять, причину долгого ответа сервера. Опишем кратко, что показывает наш сервис при замере скорости загрузки сайта.
Узнать время ответа сервера можно в панели веб-мастера Яндекс или сторонних инструментах. Норма до 400 мс, если дольше, то надо уменьшать ответ сервера с помощью разных методов, которые опишем в этой статье.
Проверить отклик сервера вашего сайта:
Проверка времени ответа сервера
Время отклика сервера — период от запроса до вывода 1-ого байта страницы на экран. Важно не путать ответ сервера со скоростью полной загрузки страницы.
Узнать время ответа сервера можно в панели веб-мастера. В Яндекс.Вебмастере введите ваш домен в строку и нажмите «Проверить»:
Код статуса HTTP должен быть 200, а время ответа сервера — не больше чем 400 мс. Идеально сделать его до 100 миллисекунд. Есть такой миф, который распространяют в сети, что чем скорее генерируется запрашиваемая страница, тем выше она ранжируется в поиске. Эту зависимость SEO-продвижения от скорости серверного ответа находили в 2013 году специалисты MOZ.
В 2020 году уже мало кто скажет, что эта зависимость существует. Но есть обратная зависимость. Медленные страницы не дают SEO-трафика.
Ускоряете полную загрузку страницы и мобильная версия начинает приносить свой SEO-трафик. Такие кейсы ходят по рунету и из уст в уста от хороших SEO-специалистов.
Почему Google Analytics и Яндекс.Метрика показывают «не тот» ответ сервера
Ответ сервера можно смотреть и в Google Analytics. Но, это замер от реального посетителя, не от системы замера. Тут данные будут сильно разнится, потому что если я открою сайт на 3G интернете, в Хабаровске, с андроид планшета за 3 000 рублей, то сервер мне ответит гораздо медленнее, чем если я зайду на сайт с макбука, вай-фай интернета из Москвы.
Понимаете? То есть, замер от системы или настоящего посетителя даст совершенно разные значения.
Поэтому замер системы покажет узкие места гораздо более явно, чем реальные данные посетителей.
Как найти данные ответа сервера в Гугл Аналитикс
Так как интерфейс системы довольно непрост, то легче всего найти поисковиком:
Затем нужно выбрать отчет «Скорость сайта» —> Обзор. Там увидите данные по вашему сайту в разделе скорость ответа сервера.
Ответ сервера в Яндекс.Метрике
Чтобы увидеть ответ сервера от реальных посетителей в Яндекс.Метрике, надо пройти в отчет «Время загрузки страниц».
Нажимаете на Время загрузки страниц и попадаете на такой отчет.
Затем надо выбрать вид графика, выбрать период квартал или год, и кликнуть на интересующий нас отчет про ответ сервера.
Затем, надо кликнуть на «Адрес страницы», чтобы снять все лишние графики, затем кликнуть на «Итого и средние». Затем клик на «Ответ сервера», если в прошлый раз не кликнули на этот значок.
В итоге вы увидите такую картинку:
Вот теперь вы видите ответ сервера от реальных посетителей в разрезе времени, усредненный показатель всех посетителей на всех страницах вашего сайта. Эти данные не дают возможности найти узкое место, но дает статистику, какие ответы сервера получают ваши реальные посетители.
Все показатели скорости загрузки и некоторые советы по их улучшению хорошо даёт наш сервис:
Если кликнуть на поле с цифрой, то можно получить информацию о норме ответа сервера и почему это важно.
Не используйте десктоп программы-сканеры для замеров
Есть разные сервисы, вроде Netpeak Spider или Screaming Frog. Там есть графа ответ сервера. Постарайтесь не измерять этими программами ответ сервера.
Во-первых, замер идет с вашего компьютера, скорее всего из сети wi-fi. К тому же, на время скана вашего сайта этими программами создается нагрузка, которая может искажать данные про ответ сервера. В итоге, вы получите не скорость ответа сервера, а скорость отклика контента конкретно с вашего ПК.
Просто используйте эти отличные программы по их прямому SEO-назначению. 🙂
Как уменьшить время ответа сервера
Скорость сайта начинается с хостинга, а скорость ответа сервера начинается с оптимизированной и хорошо настроенной базы данных сайта (далее БД).
База данных: что проверять и что важно
В некоторых статьях можно найти информацию, что большой вес таблиц в БД означает, что их надо чистить. Это не так. Вес таблиц не имеет значения.
Если вы уже убедились, что скорость ответа сервера долгая, то вам надо пройтись по этому списку:
- Сначала лучше оптимизировать количество запросов к базе данных, вместо одно тяжелого запроса, лучше сделать два поменьше.
- Проверить индексы БД — поиск и join по таблице должен осуществляться по индексируемым полям.
- Оптимизировать саму БД, например с помощью MySQLTuner
- Объектное кеширование поможет кешировать ответы из БД на частые запросы. Например, на сайте есть товары, можно кешировать эти запросы, а обновлять кеш только при обновлении цены. Это даст снижение запросов и снижение нагрузки на базу данных.
- Если посещаемость высокая, то надо запастить железом. Высокая — это десятки миллионов хостов в сутки.
- Кеширующий CDN, типа w.tools хорошо снимет нагрузку на сервер. Нужно быть внимательными в настройке. Если не включить кеширование, то возможно замедление ответа сервера, потому как сетевые задержки из-за неправильной настройки сведут на нет все преимущества любого CDN-провайдера.
Проверка длительности серверного отклика — только начало работы над скоростью сайта. Важно проверять этот показатель на каждом типе страниц. В разделе, карточке товаров, категории.
После того, как вы сделали ответ сервера в норме, стоит перейти к следующим шагам по оптимизации и уменьшению скорости загрузки страницы. Конечно, речь о загрузке страницы до полной интерактивности.
Заключение и выводы
Тест на время ответа сервера — первостепенная задача по SEO-продвижению сайта и юзабилити, конверсий.
Этот показатель на каждой странице сайта не должен превышать 400 мс. Отлично, если он до 100 мс. Узнать ответ сервера можно через панель веб-мастер Яндекс или сторонние ресурсы, например наш пингатор. Для уменьшения ответа сервера надо:
- профилируйте запросы, чтобы понять где узкое место по нагрузке;
- оптимизируйте размеры запросов;
- проверяйте индексы БД;
- оптимизируйте БД с помощью MySQLTuner;
- настройте объектное кеширование;
- усильте железо на вашем сервере;
- используйте кеширующий CDN, будьте внимательны с его настройкой, иначе можете всё замедлить.
Если стоит задача сократить время ответа сервера в WordPress — обязательно применяйте плагины кэширования.
Источник
Оптимизация настроек 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
Итоги
По большому счёту, правильная настройка сервера требует постоянного мониторинга и отладки. Ни одна из выше установленных переменных не закреплена навечно. Запомните: настройки сервера нужно адаптировать согласно каждому уникальному случаю. В дальнейшем может понадобиться увеличить производительность сервера при помощи балансировки нагрузки и горизонтального масштабирования.
Источник