Время ответа сервера - один из важнейших параметров сайта и, к сожалению, часто игнорируемый владельцами сайта.
От времени ответа сервера зависит скорость вашего сайта, готовность проекта к масштабированию, безопасность, расходы на сервера и позиции в поисковой системе.
В этой статье мы подробно разберем, что такое время ответа сервера, распространенные причины плохих показателей, прогнозирование возникновения проблем, а также влияние времени ответа сервера на безопасность и как избежать проблем с TTFB.
Что такое время ответа сервера?
Когда вы в своем браузере открываете какую-то страницу сайта, то браузер отправляет на сервер запрос определенной страницы. Сервер обрабатывает запрос, выполняет программный код страницы, собирает информацию из базы данных, формирует html-документ и отправляет его обратно браузеру. Время за которое происходят эти процессы называют временем ответа сервера или в англоязычном варианте Time To First Bite (TTFB).
Если вы хорошо понимаете как работают сайты и для вас понятно определение выше, то вы смело можете перейти к следующему разделу ↓. В противном случае, я предлагаю немного углубиться в теорию и постараться детально понять как это работает и почему.
Что такое html-документ?
HTML - HyperText Markup Language — язык гипертекстовой разметки.
HTML-документ - это текстовый файл в формате html, который содержит контент страницы сайта размеченный (сверстанный) специальными тегами html, которые определяют типы контента.
Например, в html есть тег абзаца “p” (сокращение от английского paragraph). И на скриншоте ниже вы можете видеть как выглядит этот текст в html с использованием тега “p”.
HTML-документ также содержит ссылки на файлы, которые необходимы для корректного отображения страницы. К ним относятся изображения, шрифты, css (каскадные таблицы стилей - для дизайнерского оформления сайта), JavaScript (язык программирования, который выполняется браузером - для визуальных эффектов и сложного взаимодействия с интерфейсом).
Браузер, когда получает html-документ, выполняет рендеринг (рисует страницу) и скачивает все файлы, необходимые для этого.
Работа сайта на чистом html
Сайт может работать на чистом html. И, иногда, это может быть оправдано, но такой проект столкнется с некоторыми серьезными сложностями.
В основном, это касается многостраничных сайтов. Ведь в этом случае, для каждой страницы должен быть отдельный html-файл. Вы можете это представить на примере многостраничного документа Word, у которого для каждой страницы существует отдельный файл. На страницах сайта могут быть повторяющиеся элементы, например шапка и подвал сайта, также и в Word мы можем использовать колонтитулы. Если в колонтитуле указан номер телефона и в какой-то момент он изменится, то придется его изменять в каждом файле отдельно. Если нам нужна нумерация страниц, то у нас также возникнут проблемы, поскольку разные файлы не знают друг про друга и не могут автоматически пронумероваться и вам придется это делать вручную.
Все тоже самое, только в больших масштабах происходит и с сайтом на html. На многостраничных сайтах проблемы с редактированием шаблонных частей и необходимостью построить общую логику могут оказаться не решаемыми. Но для одностраничных или малостраничных сайтов реализацию на html можно рассматривать и сейчас.Особенно, если важна высокая скорость, ведь сайт на чистом html работает максимально быстро и время ответа сервера может составлять 1-2 миллисекунды.
Работа сайта на базе движка
Когда сайт работает на базе движка, html-файлы физически не лежат на сервере, они формируются движком по запросу.
Суть работы движка в том, что у него есть шаблоны страниц (дизайн), сверстанные на html, есть база данных, которая содержит контент и есть серверный программный код (например php), который выбирает правильный шаблон для определенного типа страниц, подставляет в него правильный контент из базы данных и формирует html-документ. Время выполнения этих процессов и составляют время ответа сервера.
Работу сайта на базе движка мы можем себе представить как единый многостраничный файл Word, в котором есть единый колонтитул для всех страниц и изменив его в одном месте, изменения отобразятся на всех страницах. А также у нас появляется возможность простраивать общую логику, например нумерация страниц или ведение единого нумерованного списка на многих страницах.
Этот принцип является основой сайтостроения и большинство сайтов работают именно с использованием того или иного движка.
Что может являтся причиной плохого времени ответа сервера?
Давайте представим себе работу сайта на примере работы библиотеки и попробуем понять, что может влиять на скорость работы.
Сама библиотека - это наша база данных. Роль библиотекаря играет процессор сервера. А программный код это инструкция по поиску нужных книг.
Начнем с самой библиотеки, то есть с базы данных. Библиотека может быть структурирована по нескольким параметрам. Например, по названию в алфавитном порядке, по имени автора, по дате издания или по дате создания произведения, по издательству, по типу переплета и т.п.
Наш библиотекарь - процессор имеет два ключевых параметра:
- Частота процессора Отвечает за скорость работы нашего библиотекаря
- Количество ядер (вычислительных потоков) Это количество наших библиотекарей, а значит количество задач, которые могут параллельно выполняться.
Библиотекарь у нас не умеет сам думать. Для него ничего не очевидно и для того, чтобы он мог выполнять задачи, ему нужна четкая последовательная инструкция - программный код.
Одна из простейших задач для библиотекаря - показать конкретную книгу. Например, мы можем попросить дать нам “Гамлета” Шекспира. Такая задача будет выполнена быстро.
Примером более сложной задачи будет просьба дать нам 10 последних произведений Шекспира. В этом случае, библиотекарю нужно проверить даты публикации всех произведений , понять какие из них будут последними и принести их. Это процесс можно сократить, если у нас изначально будет список всех произведений в порядке даты публикации. В базе данных это называют индексами. Если есть индексы, то библиотекарь точно знает где лежат нужные произведения и ему остается только принести их.
Задача может усложнится, если мы добавим условий. Например, нам нужны книги только в мягком переплете. Это значит, что библиотекарь нужно принести не 10 последних произведений, а 10 последних из тех, которые доступны в мягком переплете.
А еще некоторые книги могут быть на руках.И в этом случае, будет логично не приносить квитанцию о выдаче книги, а принести следующие книги по списку.
Чем больше условий мы добавляем, тем сложнее становится инструкция для библиотекаря, инструкци начинают состоять из ряда команд выполняемых последовательно и это превращается в то, что мы называем “медленные запросы к базе данных”.
Можно ли избежать медленных запросов? Нет, полностью избежать таких запросов на сайтах со сложной логикой не получится, но можно влиять на то, насколько запрос медленный.
Вы можете попробовать сформулировать сложную логическую задачу в одном предложении. Чем больше вы будете об этом думать и пытаться, тем лучше у вас это получится. Если вы можете сформулировать такую задачу, значит ее можно выразить в виде алгоритма. Но далеко не всегда авторы систем уделяют необходимое количество времени на это. Особенно это касается коробочных CMS и различных плагинов и модулей к ним. Как правило, такие системы бесплатны или дешевы, что не мотивирует авторов тратить время на поиск элегантных и эффективных решений. Не редко можно встретить код, который говорит библиотекарю принести 10 последних книг Шекспира по одной. И вместо того, чтобы принести сразу 10, мы будем ждать выполнения 10 операций.
Бывают задачи такой сложности, что ее целиком даже осознать не возможно и в этих случаях логику делять на логические цепочки и потом настраивают взаимодействие между цепочками. В этом случае, на эффективность кода уже могут влиять ментальные способности программиста и количество логических цепочек, которые он может удерживать в голове. Другими словами, не каждый программист в принципе способен написать хороший код для сложных функций.
Чем больше в нашей библиотеке книг, тем больше времени будет уходить на поиск необходимых. По этой причине, во многих интернет-магазинах все работает быстро, пока товаров не слишком много. Но проходя некоторый рубеж, медленный код начинает проявлять себя все больше и больше. Потому, при выборе движка, очень важно понимать, сколько в вашем интернет-магазине будет товаров.
Предположим, что мы справились с задачей, наш библиотекарь работает быстро и у нас обширная коллекция книг. Это приведет к тому, что наша библиотека будет становиться популярней и будет приходить больше людей. А что произойдет если к нашему библиотекарю одновременно обратится десять человек? Им придется стать в очередь. И последний человек в очереди получит свои книги спустя десятикратный промежуток времени от обычного. Мы можем нанять больше библиотекарей (добавить вычислительных потоков). Но в какой-то момент постоянные расходы на сервер могут стать проблемой и все равно придется заниматься оптимизацией кода и базы данных. Хотя процессорные ресурсы нужны и без них никак, но компенсировать ими проблемы в коде, может быть крайне нерентабельно.
Мы не случайно решили провести аналогию с работой библиотеки, поскольку страницы сайтов, которые выводят списки чего-либо, обычно, являются наиболее сложными и наиболее медленными страницами на сайте. Речь может идти о списке статей в блоге или списке товаров на странице категории товаров или список объявлений на доске объявлений. Суть практически не меняется от назначения сайта. У нас есть большой список объектов, есть инструменты фильтрации, сортировки, поиска и разбиения на страницы и все это работает вместе. И это действительно очень похоже на работу библиотеки или архива.
Давайте подведем итог.
Что влияет на время ответа сервера?
- Качество базы данных
- Качество программного кода
- Количество серверных ресурсов
- Количество товаров или других аналогичных сущностей
- Посещаемость сайта
Каким должно быть время ответа сервера?
В любой сфере за скорость приходится платить. И скорость сайтов не является исключением. Потому, скорость должна быть такой, какую вы можете себе позволить. Но если говорить о технически оптимальных параметрах, то время ответа сервера для простых страниц без сложной программной логики (статья, страница товара) должно составлять 10-50 миллисекунд, а для сложных страниц (категории товаров) - 100-300 миллисекунд.
Стоит помнить, что время ответа сервера - это не стабильная величина. Ее можно сравнить со скоростью грузовика. Вчера ваш грузовик мог ехать очень быстро, поскольку ехал без груза. Сегодня с грузом он уже не может достичь вчерашней скорости. А завтра вы можете дать ему такой груз, который он не сможет сдвинуть с места. Хотя, грузовик не стал хуже, просто изменились условия.
Также происходит и со временем ответа сервера. Если ваш сайт развивается, то он неизбежно будет сталкиваться с проблемами со скоростью. И оптимизация скорости - это процесс, который будет постоянно сопровождать развивающийся сайт.
Можно сказать, что оптимизация TTFB - это бесконечный процесс и нет оптимизированных сайтов. На любом сайте, всегда есть что ускорить. Разница только в том, что поначалу вы боретесь за сотни миллисекунд, а со временем за каждую миллисекунду. Для высоконагруженного проекта, экономия 10 миллисекунд - это очень важно и быстро окупается, даже если эти 10 миллисекунд стоили несколько тысяч долларов.
Потому, для каждого проекта, приемлемая величина TTFB определяется индивидуально, учитывая техническую базу, сложность программного кода, мощность сервера, посещаемость, бюджет и план развития.
Важно регулярно следить за временем ответа сервера и стараться решать проблемы до того, как они обостряться. На время ответа сервера часто не обращают внимания, если сайт в принципе быстрый. Например, страница категории товара загружается полностью за 1,5 секунды. Это не плохой результат. Но если из 1,5 секунд, одна секунда уходит на время ответа сервера, то это довольно плохой показатель и если проект предполагает значительное наращивание посещаемости, то эта проблема может очень быстро обостриться и стать критической.
Зачем ускорять сайт?
Вы наверняка читали о влиянии скорости на конверсии и позиции сайта. Этой информации много в сети и мы не станем повторяться. Мы опишем факторы, о которых очень редко говорят .
Экономия на серверах
Владельцы высоконагруженных сайтов несут большие расходы на сервера. Оптимизация времени ответа сервера пропорционально снижает нагрузку на сервер. Таким образом, оптимизация скорости сайта может привести к значительному сокращению расходов сразу после оптимизации.
Безопасность
Суть DDoS-атак заключается в том, чтобы создать большую волну обращений к серверу. Обращения становятся в очередь и сайт замедляется, пока не перестанет отвечать вообще. Время ответа сервера имеет решающее влияние на то, будет ли атака успешной. Если время ответа сервера составляет 1 секунду, то достаточно 10 обращений в секунду, чтобы замедлить ответ сервера до 10 секунд. Но если TTFB составляет 50 мс, то понадобится уже 200 обращений в секунду, чтобы так замедлить сайт. Если у сайта проблемы со скоростью, то даже активность поискового робота Google на сайте может сделать ресурс недоступным для посетителей.
Как избежать проблем с TTFB?
Мы уже говорили о том, что любой развивающийся сайт будет сталкиваться с замедлением и необходимостью оптимизации времени ответа сервера. Но оптимизацию можно делать до того, как проблема проявится.
Для этого необходим план развития, который даст примерную картину изменения параметров нагрузки. Например, запланировано в течении года увеличить количество товаров до 500 тысяч и посещаемость до 200 тысяч в сутки.
Можно смоделировать такие параметры нагрузки и сделать тестирование сайта в схожих условиях. Это поможет выяснить время ответа сервера в таких условиях, а также покажет “узкие” места, с которыми нужно работать для оптимизации.
В этой статье мы описали наиболее важные способы влияния на время ответа сервера, но это далеко не исчерпывающий список. Есть множество возможностей тонкой настройки сервера и системы сайта, которые необходимо использовать.
Поскольку мы много лет специализируемся на ускорении сайта, помимо стандартных инструментов, у нас также имеется арсенал инструментов и методик собственного производства, которые позволяют быстро проводить диагностику и эффективно оптимизировать время ответа сервера.
Мы будем рады предоставить вам более подробную информацию о наших услугах и ответить на все ваши вопросы. Свяжитесь с нами по указанным контактным данным, чтобы обсудить детали и начать процесс оптимизации TTFB для вашего сайта. Мы уверены, что сотрудничество с WEB ROOM поможет вам значительно улучшить время ответа сервера вашего сайта и обеспечить более высокую эффективность вашего онлайн-ресурса.