Тестирование производительности — Speed Index и время до первого байта

Тестирование производительности - Speed Index и время до первого байта

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

Меня особенно интересовали время до первого байта (TTFB) и Speed Index, определенный для сайта WebPageTest. В диаграммах водопада, которые сопровождают эти тесты, также было указано кое-что интересное, касающееся HTTP.

Еще раз, что такое время до первого байта (TTFB) и Speed Index?

Напоминаю, что время до первого байта (TTFB) является показателем того, сколько времени требуется от первоначального запроса веб-страницы до того момента, когда будет возвращен первый байт данных. Оно включает время, необходимое для отправки HTTP-запроса, выполнения поиска DNS и создания рукопожатия HTTP между клиентом и сервером. Оно также включает время, необходимое серверу для обработки запроса и отправки первого байта ответа клиенту, отсюда и название — время до первого байта.

Speed Index — это метрика, специфичная для WebPageTest. Она показывает среднее время до отображения видимых частей страницы. Speed Index предназначен для измерения общего опыта и восприятия данной страницы.

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

Поскольку Speed Index доступен только через WebPageTest, и они предлагают результаты для TTFB, вот откуда берутся все эти показатели. WebPageTest запускает три теста для каждого тестируемого места. Цифры в скобках относятся ко второму и третьему прогонам, и, как правило, они должны быть лучше, чем для первого запуска, благодаря кэшированию DNS.

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

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

Вот результаты, которые я получил при первом тесте, сразу после перехода на Siteground. Сайт получил общую оценку F за TTFB.

Вы заметили, что все цифры стали хуже, что не имеет смысла. Учитывая лучшие характеристики нового сервера, мое обновление до PHP 7, использование HTTP / 2 и лучшие результаты для времени ответа сервера, которое я определил на прошлой неделе, я, естественно, предположил, что TTFB и Speed Index также улучшатся, но не тут то было.

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

Диаграммы водопада приходят на помощь

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

Как только я увидел водопад, я заметил кое-что странное. HTML для страницы (синеватая серая полоса в двух верхних строках) загружается дважды. Это заняло минуту или две, но я понял, что это связано с тем, что URL-адрес страницы перенаправляется с http на https. Если вы посмотрите налево, вы увидите, что рядом с первой строкой нет значка блокировки, но значок есть для второй и третьей строк и т. д. С одним единственным исключением.

Я перезапустил тест, используя https, чтобы устранить перенаправление, и вот результирующая диаграмма водопада.

Вы можете видеть, что начальный запрос исчез, и все происходит примерно на 400 мс быстрее, чем раньше. Вот результаты TTFB и Speed Index для тестирования непосредственно https.

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

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

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

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

Заключение

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

Случайно я также увидел, как перенаправление может замедлить работу сайта. В моем случае перенаправления с http на https составило 400 мс или почти половину секунды для. Представьте, сколько времени может быть потеряно путем перенаправления цепочки, когда URL-1 указывает на URL-2, тот на URL-3 и так далее.

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

Автор: Steven Bradley

Источник: //vanseodesign.com/

Редакция: Команда webformyself.

Метки:

Похожие статьи:

Комментарии Вконтакте: