От автора: оптимизация скорости сайтов — это ремесло, а каждому ремеслу нужны инструменты. Наиболее используемыми инструментами, направленными на повышение производительности, являются GTmetrix, YSlow и Pingdom Tools.
GTmetrix — довольно продвинутый инструмент, который предлагает много возможностей на свободном уровне, но также предлагает премиальные уровни. Если вы зарегистрируетесь, вы можете сравнить несколько веб-сайтов, несколько версий одного и того же веб-сайта, протестированных в разных условиях и сохранить тесты для последующего просмотра.
YSlow по-прежнему актуальна, хотя лучшими ее были дни, когда Firebug правил среди инспекторов браузеров. Он предлагает приложение Chrome и другие реализации, такие как надстройки для Safari и Opera, букмарклет, расширение для PhantomJS и т. д.
Для продвинутых пользователей интеграция PhantomJS означает, что можно, например, автоматизировать тестирование многих веб-сайтов — сотен или тысяч — и экспортировать результаты в базу данных.
Матрица правил YSlow в течение ряда лет была измерительной палочкой для работы сайта.
Pingdom Tools — это сервис SaaS, который предлагает мониторинг и отчетность об эффективности веб-сайта, и в последние годы он укрепил свои позиции на рынке. Он также предлагает проверку работоспособности DNS и тестирование скорости веб-сайта на своем свободном уровне, что сопоставимо с GTMetrix и YSlow.
Для целей этой статьи мы приобрели подходящее доменное имя — ttfb.review — и установили Drupal с некоторым демо-содержимым на нем. Мы также установили WordPress на wp.ttfb.review и демонстрационные установки Yii и Symfony в своих соответствующих поддоменах.
Мы использовали начальную установку WordPress по умолчанию. Для Drupal мы использовали расширения Devel и Realistic Dummy Content для генерации демонстрационного контента. Для Symfony мы использовали демонстрационное приложение Symfony, а для Yii мы использовали базовый шаблон приложения.
Таким образом, мы сможем сравнить эти установки бок о бок и укажем на то, что заслуживает внимания.
Имейте в виду, что это установки уровня развития, используемые только для демонстрационных целей. Они не оптимизированы для работы в производстве, поэтому наши результаты, вероятно, будут подпунктами.
GTmetrix
После входа в систему (регистрация бесплатна) мы протестировали все четыре наших демонстрационных веб-сайта и сравнили результаты бок о бок:
Мы видим, что наша установка Drupal загружалась быстрее всего, а установка Yii заняла целых десять секунд для загрузки. Однако было бы нецелесообразно использовать это для любого сравнения технологий, так как это не готовые к производству веб-сайты, а те системы, которые требуют больше знаний и работы по настройке, как ожидается, придут в режим отладки (или разработки). Другая вещь, которую следует иметь в виду, состоит в том, что для получения каких-либо убедительных результатов рекомендуется повторять тесты пару раз. Система виртуализации нашего сервера тестирования — OpenVZ, для которой распределение ресурсов может быть непоследовательным.
Мы можем видеть соответствующие показатели:
общее количество запросов
общий размер страницы
общее время загрузки
Можно сказать, что это основные показатели, на которые мы должны обратить внимание, наиболее важным из которых является время загрузки. Все другие показатели, которые мы видим, являются полезными рекомендациями, которые дают нам подсказку о том, как улучшить время загрузки.
Шон Андерсон из агентства Hobo SEO из Великобритании опубликовал статью о соотношении между скоростью веб-сайта и конверсиями / рейтингом Google — с некоторыми интересными результатами.
Вещь, о которой нужно помнить — это то самое время. Все остальные показатели — простые рекомендации.
Это сравнение можно увидеть онлайн на GTmetrix, чтобы читатели могли анализировать его по отдельности.
Первый набор результатов находится на вкладке PageSpeed, где мы видим, что единственное, что этот алгоритм жалуется на нашу установку Yii (самый медленный в нашем тесте) — это минимизация JS (или, скорее, ее отсутствие). Drupal является лучшим, хотя в нем есть большинство красных флагов. Если принять во внимание размер страницы, Symfony сделает все возможное, при этом вес страницы составляет всего 507 КБ.
Из этого примера видно, что простые тесты не говорят нам всего. Если перейти на вкладку YSlow, мы увидим более реалистичные оценки:
Но по-прежнему трудно приписать разницу времени загрузки для любого из этих элементов. Вот почему у нас есть вкладка «Водопад»: она показывает нам, где задержка. Сравнение водопада, из-за отсутствия экранной недвижимости, может сравнивать только два результата бок о бок, поэтому мы сравним установки Drupal и Yii (лучшее и худшее время загрузки) на этой странице результатов.
Это, наконец, дает нам некоторое представление о том, что ни один из предыдущих инструментов не дал нам. Целые девять секунд, потраченные Yii, расходуются на первый (основной) запрос HTML-кода веб-сайта, а не на статические ресурсы. Если мы навешиваем длинную фиолетовую линию на диаграмме Yii, у нас будет спецификация GTmetrix для нас точной анатомии этого девятисекундного ответа:
Здесь мы можем обнаружить, где лежит проблема — в фазе «Ожидание», на этапе генерации страницы или использовать более привычный термин TTFB, Time To First Byte. Это означает, что проблема лежит исключительно на нашей стороне Nginx или PHP. То, что мы можем сделать по этому поводу, многообразно и имеет много общего с тем, с чем мы имеем дело. Нам нужно будет проверить, где находится проблема на нашем сервере.
Это может быть ресурсоемкое приложение, неэффективные запросы к базе данных, ограничения на ОЗУ сервера и т. д. Инструмент, который может пригодиться здесь для мониторинга серверных процессов — это Monit, а также инструменты и процедуры для конкретных приложений для диагностики и улучшения времени загрузки. Двумя вещами, которые почти всегда улучшают TTFB, являются: больше ресурсов сервера и кеширование решений, таких как Varnish. Если статические ресурсы были основным виновником, нам нужно будет уделять больше внимания предупреждениям на вкладках PageSpeed и YSlow, gzipping, minification и, возможно, развертывать наш сайт на CDN, например Cloudflare.
Одной из причин разницы между Drupal и Yii может быть тот факт, что Drupal поставляется с «включенными батареями», более готовыми к выпуску, в то время как Yii готов к широкому развитию.
Мы видим, что установка Drupal по умолчанию включает в себя некоторые решения для кеширования:
После того, как немного поработал с Drupal, и играя со своими встроенными модулями и параметрами конфигурации, такими как BigPipe и кешированием, мы могли бы уменьшить время загрузки еще на полсекунды:
На GTmetrix мы можем сравнить наши тесты с главной страницы:
Мы также можем просто добавить разные суффиксы URL-адреса, чтобы видеть их бок о бок:
Для вкладки «Видео» мы должны включить параметр видеозаписи в наших дополнительных опциях:
(Кстати, мы видим, что в последующих тестах разогрев кэша Drupal сократил время загрузки нашего сайта еще на 200 миллисекунд.)
Теперь у нас есть видео, доступное на вкладке Видео результатов:
Таким образом, мы можем иногда визуально узнавать о проблемах с загрузкой или узких местах. Система также предлагает создать диафильм для загрузки страницы.
В отдельных тестах есть также вкладка Timings, которая разделяет фазы загрузки и дает нам время и объяснение каждой фазы, например, Time To First Byte, о которой мы упоминали ранее:
(Это ttfb.review о загрузке Drupal с одной секундой).
Вкладка «История» в отчетах одной страницы предназначена для отслеживаемых страниц или нескольких тестов с течением времени, где мы можем видеть наш прогресс:
Для сравнения у нас есть вкладка «Графики»:
Есть больше настроек, которые можно найти на боковой панели:
Повторяя тесты, в ходе написания этой статьи мы увидели, что время загрузки для приложения Yii уменьшилось до 1,2 секунды, а Symfony — до 1,6 секунды.
С помощью Symfony на вкладке «История» показано, что TTFB остается прежним, а улучшение в 400 миллисекунд, скорее всего, связано с различием в загрузке статических ресурсов:
Но следующие две диаграммы показывают, что нечего требовать кредита для улучшения скорости, за исключением случайной лучшей пропускной способности сети:
С Yii улучшение является более радикальным по всем трем показателям: TTFB, onload и полностью загруженному времени:
Здесь улучшения являются случайными и из-за перегрузки сервера или изменения пропускной способности сети, но по мере внесения изменений на нашем веб-сайте и улучшения в этих разных показателях мы сможем отслеживать наши успехи на вкладке «История».
У GTmetrix есть еще много вариантов, и это выходит за рамки одной статьи. Например, даже по бесплатному плану мы можем протестировать мобильные или настольные браузеры, и мы можем имитировать скорость сети посетителя — ADSL, 3G и т. д.
Мы также можем протестировать веб-сайт из разных мест на земном шаре:
Это может пригодиться, когда мы ожидаем посетителей из более чем одного региона или когда мы измеряем влияние внедрения CDN в наш стек. Задержка в сети может сделать пару секунд разницы в времени загрузки из одного места на земном шаре в другое.
YSlow
YSlow, с его набором правил, пришел из работы разработчиков Yahoo Exceptional Performance. Он стал важным инструментом для веб-производительности, прежде всего, как дополнение Firebug, но это было устаревшим с помощью Firefox Quantum.
Он по-прежнему доступен как букмарклет, расширение Safari , средство командной строки или приложение Chrome:
Мы можем выбрать набор правил для применения, установить строгость критериев и затем получить результаты в классе, с оценками по пунктам, от A до F, с пояснениями и ссылками для каждого элемента / измерения.
На вкладке «Оценка» мы можем отфильтровать наши результаты. Например, с нашим приложением Yii, отфильтровывая результаты только на те, которые относятся к Серверу, мы видим следующее:
Это дает нам краткий обзор того, что мы можем улучшить, регулируя настройки сервера — gzipping содержимого, настройку заголовков Expires, развертывание веб-сайта на CDN и т. д.
Каждая из рекомендаций / оценок YSlow дает нам краткое объяснение и ссылку, чтобы больше узнать о теме.
Вкладка «Компоненты» дает нам обзор всех ресурсов или URL-адресов, загруженных во время загрузки страницы, включая саму страницу, JS, CSS, изображения, их размеры, сжатые размеры, файлы cookie, отправленные заголовки.
Например, в случае нашего демонстрационного приложения Yii мы можем видеть на вкладке «Компоненты», что мы не сжимаем наш JS должным образом (размер такой же, как несжатый), и не устанавливаем заголовки Expires, которые должны выполняться в производственное приложение:
Вкладка «Статистика» содержит большой обзор всех элементов, составляющих страницу, процент от общего веса страницы и общий обзор их с загруженным кешем браузера. Это то, с чем мы можем манипулировать с заголовком Expires. У GTmetrix есть статья о заголовке Expires. Этот показатель производительности влияет на повторных посетителей — тех, кто из-за нашей инструкции Expires, отправляемой в браузер нашего посетителя, имеет статические ресурсы, хранящиеся в кеше браузера, для повторных посещений за определенное количество времени.
На веб-сайте YSlow есть более подробное руководство по каждому из 23 критериев, которые он использует для оценки тестируемых веб-сайтов, с дальнейшими советами по оптимизации.
Инструменты Pingdom
Pingdom предлагает широкий набор инструментов, как для проверки работоспособности DNS, так и для полностраничного тестирования.
Пройдя тест и получив краткий обзор, как показано выше, далее на странице отчета мы представили рекомендации по улучшению нашего времени загрузки:
Мы можем видеть здесь рекомендации, касающиеся заголовков Expires, о которых мы упоминали выше, между прочим.
Ниже мы можем проверить наши HTTP-ответы и есть ли у нас проблемные перенаправления или неверные ответы (в случае, если некоторые из ресурсов не загружались):
В случае с другим веб-сайтом, который мы тестировали — действительно ресурсоемким веб-сайтом с множеством статических ресурсов, результаты выглядели следующим образом:
Вернемся к нашей тестовой установке Drupal на http://ttfb.review, Pingdom дает нам — дальше по странице результатов — разбивка содержимого по типу, массе и проценту:
В случае упомянутого ресурсного ресурса, который мы тестировали (мы не оставили URL видимым, потому что это довольно плохой пример веб-сайта, который работает в производстве), мы можем видеть проблематичные части: массивное видео, Карты Google, виджет чата внешним поставщиком:
Назад с нашего сайта Drupal, Pingdom позволяет нам анализировать всю загрузку страницы, запрашивать по запросу, позволяя нам видеть, какие запросы / ответы составляют большую часть нашего времени загрузки:
Затем, по цветам, мы можем далее разбивать фазы каждого отдельного запроса / ответа и находить узкие места, либо избавляясь от самых дорогих ресурсов, либо gzipping их, уменьшая JS и CSS, или развертывая их на CDN.
Мы также можем комбинировать их там, где это возможно, для уменьшения количества запросов или реализации протокола HTTP / 2, что позволяет использовать более асинхронную, неблокирующую загрузку ресурсов.
Под этой диаграммой водопада Pingdom имеет цветовую легенду, объясняя каждую.
В случае с нашим веб-сайтом Drupal, поскольку мы настроили параметры DNS домена с нуля, когда мы начали писать эту статью, мы установили TTL записи A — Time To Live или время кэширования записи домена — до 1 минуты, пытаясь ускорить развертывание нашего домена. Чтобы уменьшить пинг, часть DNS первого запроса, мы увеличили бы время TTL, как только домен будет настроен максимально. Таким образом, настройка домена будет кэширована, и нет необходимости в тщательном поиске DNS домена.
Каждый из этих запросов имеет кнопку выпадающего меню справа, и, щелкая по нему, мы получаем представление о заголовках каждого запроса и ответа:
Здесь мы можем отлаживать, кэшируется ли запрос на сервере, кэшируется ли содержимое и т. д.
Например, с веб-сайта, развернутого в Cloudflare, из заголовков ресурсов видно, что cf-cache был HIT — это означает, что ресурс кэшируется, мы видим, что он настроен на gzipped, установлены заголовки истечения, а также заголовки управления кешем:
На веб-сайте, размещенном в Cloudflare, мы можем видеть на нашей диаграмме водопада Pingdom, загрузка ресурсов более параллельна, асинхронна и не блокируется. Этого также можно добиться, настроив наш сервер на использование протокола HTTP / 2:
(Нет ожиданий завершения одного цикла запроса / ответа для следующего запуска).
Некоторое улучшение здесь может быть достигнуто за счет предварительной загрузки ресурсов.
С Pingdom, как и с GTmetrix, мы можем выбрать место для тестирования. Мы попытались проверить нашу демонстрационную установку Yii, http://yii.ttfb.review, из Швеции (предыдущие тесты GTmetrix были сделаны из Ванкувера, Канада), и разница очевидна. На наш сайт теперь загружено 445 миллисекунд:
В этом случае мы также видим, что задержка DNS берет, возможно, больше, чем нужно. Мы должны уменьшить параметр TTL DNS, а синие части на статических ресурсах — это фаза «Подключиться», поэтому мы можем предположить, что HTTP / 2 с его усовершенствованиями keepalive сможет использовать одно соединение, чтобы вытолкнуть все эти ресурсы без накладных расходов на создание нового TCP-соединения для каждого ресурса:
Простейшим путем здесь, вероятно, будет CDN.
Задержка DNS еще более заметна, когда мы тестируем из Калифорнии:
Мы можем с уверенностью предположить, что решение проблемы DNS и эффективное использование статических ресурсов сократит время загрузки на треть.
Pingdom предлагает решения для мониторинга премиум-класса, аналогичные GTmetrix. Он может контролировать время безотказной работы, отправлять предупреждения, отслеживать среднее время загрузки и т. д.
Файлы HAR
Как GTmetrix, так и Pingdom дают нам возможность экспортировать файлы HAR. Файлы формата HAR — или HTTP Archive — это архивные файлы в формате JSON для регистрации взаимодействия веб-браузера с сайтом. Мы прикрепляем файл HAR из нашего теста GTmetrix тестовой установки WordPress (кстати, у него много проблем для отладки).
Этот файл является стандартным форматом для отладки отклика веб-сайта.
Затем этот файл можно импортировать в Har Analyzer Google:
Затем это может быть дополнительно проанализировано, разделено и т. д.
Другие инструменты
Другие инструменты, которые заслуживают упоминания — это Page Load Time for Chrome, которое работает как опрятный виджет браузера с краткими статистическими данными загрузки:
Затем есть Dotcom Tools web speed test:
Он предлагает 24 места для тестирования, а затем подробные графики водопада для каждого из них.
Существует также PageSpeedGrader:
Google PageSpeed Insights — еще один инструмент, который мы можем использовать для получения информации и рекомендаций по возможным улучшениям и лучшим практикам, как для мобильных, так и для настольных посетителей:
Заключение
В этой статье мы установили некоторые демонстрационные веб-установки и попытались показать, как мы можем отлаживать различные элементы, составляющие время загрузки страницы. Существуют и другие инструменты, которые могут выявить узкие места, которые дают нам представление о серверных процессах, таких как New Relic, DataDog и другие связанные с сервером инструменты, такие как Monit — расширенные инструменты, но немного более инвазивные в отношении инфраструктуры сервера.
Автор: Tonino Jankov
Источник: https://www.sitepoint.com/
Редакция: Команда webformyself.