Проверка времени ответа сайта | IT Knowledge Base
Заметки системного инженера
Узнать скорость отклика сайта можно из cmd Linux с помощью CURL.
cURL — свободная , кроссплатформенная служебная программа командной строки, позволяющая взаимодействовать с множеством различных серверов по множеству различных протоколов с синтаксисом URL.
Общее время ответа сайта
Используйте следующую команду, чтобы узнать скорость ответа
сайта, в секундах.
$ curl -s -w %{time_total}\\n -o /dev/null https://www.disnetern.ru
Пример выполненной команды:
0,579341
Описание возможных опций:
Опции | Описание |
---|---|
-s | Тихий режим. Не показывать индикатора выполнения или сообщений об ошибках |
-w | Определяет, что отображается на стандартный вывод после завершенной и успешной операции |
-o | Перенаправляет вывод в ‘/dev/null’ |
time_total | Суммарное время, которое заняла операция, в секундах |
Более подробный отчет об отклике сайта
Эта команда возвращает lookup
, connect
, pretransfer
, starttransfer,
время в секундах, а так же суммарное время
операции.
$ curl -s -w '\nLookup time:\t%{time_namelookup}\nConnect time:\t%{time_connect}\nPreXfer time:\t%{time_pretransfer}\nStartXfer time:\t%{time_starttransfer}\n\nTotal time:\t%{time_total}\n' -o /dev/null https://www.disnetern.ru
Пример выполнения команды:
Lookup time: 0,060429 Connect time: 0,086693 PreXfer time: 0,160163 StartXfer time: 0,325986 Total time: 0,326014
Описание возможных опций:
Опции | Описание |
---|---|
Lookup time (time_namelookup) | Время, в секундах, затраченное на преобразование доменного имени в IP адрес |
Connect time (time_connect) | Время, в секундах, затраченное на подключение к удаленному серверу по TCP |
PreXfer time (time_pretransfer) | Время, в секундах, затраченное на подготовку к обмену данными. Оно включает в себя время на ‘обмен рукопожатиями’ участников конкретного протокола. |
StartXfer time (time_starttransfer) | Время, в секундах, затраченное на все действия, вплоть до начала передачи первого байта данных. |
Полный отчет по времени отклика сайта
Следующая команда добавляет данные о времени, затраченном на appconnect
и redirect
. Эти опции работают только в последних версиях CURL.
$ curl -s -w '\nLookup time:\t%{time_namelookup}\nConnect time:\t%{time_connect}\nAppCon time:\t%{time_appconnect}\nRedirect time:\t%{time_redirect}\nPreXfer time:\t%{time_pretransfer}\nStartXfer time:\t%{time_starttransfer}\n\nTotal time:\t%{time_total}\n' -o /dev/null https://www.disnetern.ru
Пример выполненной команды:
Lookup time: 0,060691 Connect time: 0,088901 AppCon time: 0,159063 Redirect time: 0,000000 PreXfer time: 0,159244 StartXfer time: 0,588659 Total time: 1,588659
Описание возможных опций:
Опции | Описание |
---|---|
AppCon time (time_appconnect) | Время, в секундах, с начала замера, до завершения соединения/рукопожатия по протоколу SSL/SSH и пр. с удаленным хостом |
Redirect time (time_redirect) | Время, в секундах, затраченное на редиректы, включая name lookup, connect, pretransfer и transfer. ‘time_redirect’ показывает суммарное время всех редиректов. |
Время Отклика: 3 уровня:
- 0.1 сек. — это время, за которое пользователь ощутит что система реагирует мгновенно, а это означает что никакой обратной связи, за исключением отображения результата, не требуется;
- 1.0 сек. — это время, в течении которого поток мыслей пользователя остается непрерывным, даже если он и заметит задержку. Как правило, никакой обратной связи не требуется во время задержки более 0.1 но менее 1.0 секунды, однако пользователь теряет ощущение непосредственной работы с данными;
- 10 сек. — это практически предел удерживания внимания пользователя на диалоге. Во время более длительных задержек, у пользователя возникнет желание заняться другими вещами, пока загрузка страницы не закончится.
Author: striker on 08.03.2018
Categories: Debian, FreeBSD, Linux
Tags: apache, curl, nginx, time, tuning
Other posts
Настройка NFS-сервера на Debian «» Сжатие gzip и кэширование в Nginx и Apache© IT Knowledge Base | powered by the WikiWP theme and WordPress. |
Проверка времени ответа сервера — что это, каким должно быть, как улучшить
На что влияет время ответа сервера?
Время ответа сервера влияет на скорость загрузки сайта на устройстве пользователя и на стабильность индексации сайта поисковыми системами.Медленный сайт пользователи будут чаще закрывать, не дождавшись загрузки. Оба этих фактора учитываются поисковыми системами при ранжировании сайта, поэтому для эффективного продвижения сайта нужно следить, чтобы этот показатель не поднимался выше определенного значения.
Как узнать время ответа сервера?
Проверить время ответа сервера вы можете с помощью специального сервиса от Яндекса или с помощью виджета, расположенного ниже.
Виджет предоставлен сайтом calcus.ru
От чего зависит время ответа сервера
Скорость ответа сайта зависит от того, насколько быстро сервер обработает запрос и вернет результат. Основная причина слишком медленной реакции сайта — это перегрузка. Сервер не справляется с тем количеством запросов, которое к нему поступает. Чтобы уменьшить время ответа, нужно либо улучшить конфигурацию сервера, либо оптимизировать скрипты и запросы к базе данных. После такой оптимизации сервер будет тратить меньше времени на один запрос и будет успевать обрабатывать большее количество запросов за единицу времени.
Не существует универсального способа сократить время ответа сервера. В каждом случае должен быть индивидуальный подход к оптимизации нагрузки.
Нормальное время ответа — это сколько?
Чем меньше, тем лучше.
- До 300 миллисекунд — очень хороший результат, можно спать спокойно.
- От 300 до 700 миллисекунд — тоже неплохо, волноваться повода нет.
- Если время ответа вашего сайта приближается к секунде, или ещё выше — повод принимать меры.
Помните, что скорость ответа влияет не только на восприятие сайта людьми (согласитесь, неприятно, когда при серфинге по сайту наблюдаются задержки при открытии страниц), но и на восприятие сайта поисковыми системами. Давно не секрет, что данный фактор оказывает влияние на ранжирование.
Коды ответов HTTP
Код состояния HTTP — это число, состоящее из трех цифр. Первая цифра означает группу, к которой принадлежит код.
Существуют следующие группы:
- 1xx — Информационные коды
- 2xx — Успешные коды
- 3xx — Коды перенаправлений
- 4xx — Коды ошибок клиента
- 5xx — Коды ошибок сервера
Проверка 304 Not Modified
Правильно настроенный сервер должен обрабатывать заголовок If-Modified-Since. Этот заголовок содержит дату и спрашивает, была ли изменена страница после этой даты. Если страница не была изменена, сервер должен вернуть ответ 304 Not Modified. При этом ответ содержит только заголовки и не содержит тело страницы. Это значительно экономит время и трафик при обходе вашего сайта поисковыми роботами.
Помимо этого, для корректной работы этой схемы сайт должен на каждый GET-запрос возвращать заголовок Last-Modified, содержащий дату последнего изменения страницы. Браузеры и поисковые роботы сохраняют эту дату и при следующем запросе используют именно её для заголовка If-Modified-Since — как бы спрашивая, изменилась ли страница с тех пор, нужно ли её скачивать заново.
Была ли наша статья полезной?
Спасибо за отзыв!
Как проверить время отклика веб-сайта
За последние несколько лет наш цифровой ландшафт превратился из легкого и спокойного темпа в тот, который быстрее, чем покупатели врываются в универмаги в Черную пятницу.
И нет никаких признаков того, что в ближайшее время скорость веб-сайта будет снижаться.
Интернет-пользователи ожидают не только более быстрой загрузки страниц веб-сайта, но и связи в сети укрепляются по всей территории Соединенных Штатов. Фактически, в течение следующих нескольких лет доступ в Интернет 5G приведет к одному из самых больших изменений, которые наш цифровой мир видел за многие годы.
Если вы не сосредоточены на поддержании и улучшении времени отклика веб-сайта, то всему вашему предприятию суждено вернуться в тень интернет-клозета.
На данный момент вы, вероятно, знакомы с растущими ожиданиями конечных пользователей и Google. По состоянию на 2018 год обе организации увеличили ожидаемое время отклика веб-сайта с 2,11 секунды до менее 1,3 секунды. Это касается как мобильных, так и десктопных сайтов.
К сожалению, очень мало веб-сайтов могут приблизиться к этому показателю. Не потому, что они не могут реально достичь такого быстрого времени отклика веб-сайта, а потому, что они не могут распознать и настроить различные элементы на странице и в бэкэнде, ответственные за замедление работы всего сайта.
Чтобы внести ясность в эту часто запутанную тему, важно не только понять, какие элементы могут увеличить или уменьшить время отклика вашего веб-сайта, но и как проверить время отклика. Хотя для выполнения этой задачи предлагается множество онлайн-инструментов, лишь немногие из них предлагают точность и уровень понимания, необходимые для того, чтобы по-настоящему овладеть искусством цифровой скорости.
Прежде чем углубиться в пошаговое руководство по проверке времени отклика, давайте немного отвлечемся и рассмотрим, что инструмент времени отклика веб-сайта может предоставить с точки зрения важных показателей.
Что такое время отклика веб-сайта? Краткое пояснение
Итак, что мы имеем в виду, когда говорим о времени отклика? По сути, этот термин является и его определением. Для подробного объяснения посетите нашу статью Wiki о времени отклика.
Время отклика веб-сайта — это время, необходимое вашему веб-серверу для подключения и отправки пакетов данных в браузер конечного пользователя. Кажется достаточно простым, не так ли? Что ж, как и во многих других вещах в жизни, самые простые понятия часто оказываются самыми сложными.
Распространенное заблуждение относительно времени отклика веб-сайта, особенно когда речь идет о тестировании этой метрики, состоит в том, что она определяет только количество времени, которое требуется серверу для отправки «ответа» или «подтверждения» браузеру (или, в данном случае , инструмент тестирования).
Если бы это было так легко и просто, но на самом деле это вся длительность от первого байта данных до последнего.
Как инструменты тестирования времени отклика приносят пользу вашему сайту
Конкретные преимущества платформы тестирования времени отклика зависят от уровня информации, которую она предлагает. Например, тесты ping просто информируют вас о том, доступен ли ваш сайт/сервер и сколько времени потребовалось серверу, чтобы вернуть запрос ping.
Хотя базовые пинг-тесты являются важным инструментом в арсенале вашего веб-сайта, это не должна быть единственная метрика. Поскольку за определение времени отклика веб-сайта отвечает множество факторов, очень важно использовать инструмент, способный предоставить вам:
- Блок-схемы/отчеты, описывающие поток данных от сервера к браузеру конечного пользователя
- Сколько времени потребовалось браузерам конечных пользователей, чтобы начать анализ полученных файлов
- Сколько времени потребовалось для получения и рендеринга первого встроенного изображения
- Настройка DNS и продолжительность соединения (подчеркивает эффективность передачи пакетов данных)
- Общий размер пакетов данных
Тестирование времени отклика веб-сайта | Пошаговое руководство
Поскольку существуют буквально десятки инструментов для тестирования времени отклика веб-сайта, мы собираемся предоставить довольно обобщенное руководство, основанное на тесте веб-сервера HTTP/HTTPS от Dotcom-Tools. Эта продвинутая платформа тестирования предлагает глубокие аналитические данные о времени отклика сервера, скорости рендеринга веб-сайта, TTL (общем времени загрузки) и работоспособности элементов на странице.
Хотя вы можете найти другой инструмент, который вам подойдет, используйте этот лист пошаговых инструкций не только для того, чтобы понять, что искать, но и как найти точное и функциональное решение для тестирования.
Шаг 1. Введите URL-адрес веб-сайта и характеристики сервера
Введите URL-адрес своего веб-сайта в поле поиска. Отсюда выберите соответствующий тип сервера: HTTP или HTTPS, а затем тип запроса в раскрывающемся меню. Типы запросов включают GET или POST. В общем, вы должны использовать настройку по умолчанию GET.
Шаг второй — необязательные параметры
Вы можете включить информацию для входа в систему, чтобы проверить время отклика при входе в систему, параметры GET или POST, которые вы хотите просмотреть, а также имя и значение заголовка, которые вы хотите проверить.
Шаг третий — проверьте информацию и выполните тест времени отклика
После того, как вы ввели все необходимые и дополнительные данные, убедитесь, что эта информация верна, и нажмите «НАЧАТЬ ТЕСТ», чтобы запустить различные протоколы тестирования.
Шаг четвертый. Анализ результатов
По завершении вы получите подробный анализ нескольких ключевых показателей эффективности, также известных как KPI. К ним относятся:
- Время отклика и работоспособность веб-сервера
- Время отклика элемента на странице и качество загрузки
- Скорость загрузки веб-сайта (длительность)
- Общее время загрузки всего веб-сайта/веб-страницы
Время отклика веб-сайта
Пользователи действительно заботятся о скорости в дизайне взаимодействия. В 19В 97 году я написал колонку под названием «Жажда скорости», в которой указал, как сильно пользователи ненавидят медленно загружаемые веб-страницы. В то время большие изображения были основной причиной задержек времени отклика, и наше руководство рекомендовало вам сохранять изображения маленькими.
Сегодня у большинства людей (в некоторых странах) есть широкополосный доступ, поэтому вы можете подумать, что время загрузки больше не является проблемой удобства использования. И да, фактическая загрузка изображений редко является проблемой для современных пользователей (хотя изображения все еще могут вызывать задержки на мобильных устройствах).
Тем не менее, время отклика актуально как никогда. Это потому, что отзывчивость — это основное правило дизайна пользовательского интерфейса, которое диктуется человеческими потребностями, а не отдельными технологиями. Например, в ходе исследования юзабилити клиента, которое мы только что завершили, пользователи жаловались, что »
Скорость имеет значение
Оперативность важна по двум причинам:
- Человеческие ограничения , особенно в области памяти и внимания (как подробнее обсуждалось на нашем семинаре «Человеческий разум и удобство использования»). Мы просто не работаем так же хорошо, если нам приходится ждать и страдать от неизбежного распада информации, хранящейся в кратковременной памяти.
- Человеческие стремления . Нам нравится чувствовать себя хозяевами своей судьбы, а не подчиняться прихотям компьютера. Кроме того, когда компании заставляют нас ждать вместо того, чтобы предоставить оперативное обслуживание, они кажутся либо высокомерными, либо некомпетентными.
Быстрый пользовательский интерфейс лучше гламурного по той простой причине, что люди больше взаимодействуют с сайтом, когда они могут свободно перемещаться и сосредоточиться на содержании, а не на бесконечном ожидании.
В ходе недавнего исследования мы спросили пользователей, что они думают о различных веб-сайтах, которыми пользовались в прошлом. Таким образом, их ответы были основаны не на непосредственном использовании (как в обычных исследованиях юзабилити), а на каком бы то ни было
Действительно, мы получаем данные о скорости веб-сайта почти каждый раз, когда проводим исследование. Когда сайты сокращают время отклика всего на 0,1 секунды, в результате повышается коэффициент конверсии. Сегодня или в 1990-х? Тот же эффект.
Ограничения времени отклика
3 ограничения времени отклика сегодня такие же, как когда я писал о них в 1993 году (на основе 40-летнего исследования пионеров человеческого фактора):
- 0,1 секунды дает ощущение мгновенный ответ — то есть результат выглядит так, как будто он был вызван пользователем, а не компьютером. Этот уровень отклика необходим для поддержки ощущения прямого манипулирования (прямое манипулирование является одним из ключевых методов графического интерфейса для повышения вовлеченности и контроля пользователя — подробнее об этом см. в нашем курсе «Принципы пользовательского интерфейса, который должен знать каждый дизайнер»).
- 1 секунда сохраняет поток мыслей пользователя бесшовным . Пользователи могут ощущать задержку и, таким образом, знать, что компьютер генерирует результат, но они по-прежнему чувствуют, что контролируют общее впечатление и что они двигаются свободно, а не ждут на компьютере. Такая степень отзывчивости необходима для хорошей навигации.
- 10 секунд удерживает внимание пользователя . От 1 до 10 секунд пользователи определенно чувствуют себя во власти компьютера и хотят, чтобы он был быстрее, но они справляются. Через 10 секунд они начинают думать о других вещах, из-за чего им становится все труднее вернуть мозг в нужное русло, как только компьютер, наконец, отреагирует.
10-секундная задержка часто заставляет пользователей немедленно покинуть сайт . И даже если они остаются, им сложнее понять, что происходит, что снижает вероятность того, что они преуспеют в каких-либо сложных задачах.
Даже задержки в несколько секунд достаточно, чтобы создать неприятный пользовательский опыт. Пользователи больше не контролируют ситуацию, и их сознательно раздражает необходимость ждать компьютера. Таким образом, с повторяющимися короткими задержками пользователи сдаются, если они не очень привержены выполнению задачи. Результат? Вы можете легко потерять половину своих продаж (для тех менее преданных клиентов) просто потому, что ваш сайт на несколько секунд медленнее для каждой страницы.
Необычные виджеты, медленный отклик
Вместо больших изображений сегодняшние грешники с большим временем отклика, как правило, чрезмерно сложная обработка данных на сервере или чрезмерно причудливые виджеты на странице (или слишком много причудливых виджетов).
Вот пример из недавнего исследования по отслеживанию взгляда, которое мы провели, чтобы создать новый материал для нашего учебного курса по дизайну веб-страниц UX. На следующих графиках взгляда показано поведение двух разных пользователей на одной и той же странице, которая содержала виджет слайд-шоу в верхнем желтом поле, требующее 8 секунд для загрузки :
Графики взгляда двух разных пользователей: синие точки указывают, куда смотрели пользователи (одна фиксация на точку).Участник теста в верхней части графика взгляда несколько раз фиксировался на большом пустом цветном блоке перед загрузкой контента, а затем провел оставшееся время, просматривая остальную часть страницы. Этот пользователь ни разу не посмотрел на большое рекламное место после того, как оно было отображено.
Второй пользователь (нижний график взгляда) отводил взгляд от экрана в течение 8 секунд, пока загружался рекламный контент. Таким образом, в первый раз, когда он посмотрел на страницу, он увидел ее, как и предполагалось, в комплекте со всем промо.
Слайд-шоу занимает 23% страницы , не считая нижнего колонтитула, который здесь не показан.