[Перевод] Погружаясь в производительность
Привет, меня зовут Стив Соудерс и я работаю в Google в команде, которая «делает интернет быстрее». Это невероятно круто. В команде более 50 человек и наша задача сделать весь интернет в целом быстрее, не только сервисы Google. Кроме этого, я помогаю Airbnb, Twitter, Facebook, только что отправил подробное описание системы улучшения производительности в Pinterest. Мы хотим сделать так, чтобы глобальная сеть стала быстрее. Я в основном пишу код, создаю разные утилиты и анализирую, что происходит на веб-страницах и в браузерах, и многое другое. И сегодня я расскажу о многом из того, что я уже сделал.
Данный пост сделан по мотивам выступления Стива Соудерса.[embedded content]Множество подробных материалов есть у меня на сайте. Здесь же я предлагаю вместе окунуться в атмосферу повышения производительности.
Полезные инструменты:
МетрикиНачнём с разговора о метриках. В контексте производительности это значит, что на самом деле мы подразумеваем скорость. Я хочу, чтобы интернет-страницы, интернет-браузеры работали быстрее. Итак, как же нам это измерить. Ведь если мы не будем отслеживать изменения, то не сможем реально понять, что мы делаем, и будем просто творить что-то вслепую. Другая вещь, которую я постоянно повторяю: всегда нужно фиксировать показатели при плохом положении дел. Обязательно делайте это, прежде чем начнёте что-то исправлять и измерять, потому что всё, что вы будете делать, должно улучшать результат. Люди обычно так зацикливаются на самом продукте, стараются исправить что-то и в конечном итоге забывают отслеживать показатели. И с этой точки зрения они теряют очень значительную часть всей оптимизации. Также многие боятся показывать своему боссу плохие показатели. Рекомендую тогда показывать их без динамики. Просто зафиксируйте минимум, сделайте одно или два улучшения, а затем покажите, насколько круто стало и какую отличную работу вы проделали, а потом можете уже у начальства и премию попросить.Когда дело доходит до производительности, то мы обычно измеряем скорость: как быстро происходят те или иные процессы, и обычно мы сосредоточены на окне… Есть один способ получить эти измерения от реальных пользователей. Называется он RUM — real user monitoring, что как раз и означает «мониторинг пользователя». Реальные люди, реальные метрики. Мы просто помещаем Javascript на вашу страничку и отслеживаем время загрузки у пользователя.
Примерно так уже около года работает инструмент Google Analytics. Сначала такие измерения были включены только у тех, кто поставил нужную галочку, а после 6 месяцев тестирования включили эту функцию всем. Все, у кого на сайте сейчас стоит Аналитика Google, можете открыть настройки, зайти в блок «Поведение» и увидеть информацию о скорости загрузки сайта. По умолчанию отображается последний месяц, но можно посмотреть и среднее значение. Мне, например, интересно время ответа сервера, потому что я сейчас часто ругаюсь со своим хостинг-провайдером из-за этого параметра. Также тут можно посмотреть различные графики, пики за последний месяц, время ответа HTML-документа. С помощью Google Analytics можно мониторить очень многое. Вы можете даже ничего не выбирать и не строить никакие специальные диаграммы, а просто смотреть на базовые значения и анализировать.
Также здесь можно посмотреть распределение по странам (все любят рассматривать карты мира с данными). Сразу видно, в каких странах наш сайт грузится медленно, а в каких быстро. Можно посмотреть, как много точек выхода было проанализировано. Многое, конечно, зависит от того, в какой стране находится сервер, а в какой — пользователь. Но иногда скорость слишком маленькая, по непонятным причинам.
Теперь вы знаете о таком представлении данных, он уже давно доступен в вашей панели в Аналитике. Также в Google Analytics можно отследить различное время загрузки. Например, вам хочется узнать, как долго грузится картинка на вашем сайте. Вы можете добавить изображение и сделать так, чтобы GA отслеживал его время загрузки.
Конечно, Google Analytics — это не панацея, а лишь один из вариантов, есть и другие инструменты. Например, mPulse от компании Lognormal, которая была приобретена Soasta. Или Insight от компании Torbit. Люди вовлекаются в анализ данных и улучшение производительности. И RUM-продуктов сейчас множество. Есть те, которые встраиваются в браузер, есть какие-то сторонние программы. У меня на сайте можно найти код системы Episodes, которую я пару лет назад делал для Relic. Она с открытым кодом, так что можете скачать и посмотреть.
Оптимизация Если я хочу сделать сайт быстрее, то я буду стараться уменьшить в два раза время загрузки самого сайта. Так что сначала измерьте общее время загрузки, а потом время соединения с сервером. И если с сервером всё в порядке, то начинайте работу с самим сайтом — оптимизируйте базу данных, проверьте Javascript или CSS. Ведь что-то же тормозит работу сайта.В качестве инструментов, помогающих в оптимизации времени загрузки, я могу порекомендовать:
Кстати, есть одна тонкость. В Safari мы не увидим общего времени загрузки или времени отклика сервера. А ведь последнее — это один из важнейших параметров. Чаще всего, время отклика сервера составляет 10% от общего времени. Если же у вас он получается заметно больше, то на этом стоит сфокусироваться.Я очень люблю статистику от реальных пользователей. Если у меня есть множество посетителей, то я могу проверить различные параметры и выяснить, почему в том или ином месте у того или иного пользователя мой сайт грузится дольше. Я люблю реальные данные, потому что это поведение настоящих людей, тут можно видеть информацию об их оборудовании, о подключении, географическое положение и многое другое.
Ещё один момент. Что если страница не грузится после клика по ссылке? Допустим, у пользователя медленный интернет, когда для загрузки страницы требуется 60 секунд. На самом деле, уже через 20 секунд обычно люди уходят с этой страницы. В любом случае, худшее время загрузки лучше никогда не брать в расчёт. Я для себя устанавливаю время в 10 или 20 секунд, всё, что больше — отсекается. Правда, тут стоит смотреть на общую статистику, ведь если у большинства пользователей загрузка проходит за 40 секунд, то глупо отсекать их лимитом в 20. В общем, есть такой подход, но бездумно применять его не стоит.
Синтетические тесты Альтернатива тестированию на реальных пользователях — синтетические тесты. Например, вы находитесь в лаборатории, где применяется инструмент для загрузки страниц каждую минуту, или используется сервис типа Keynote или Compuware. На самом деле, один из лучших синтетических инструментов на сегодняшний день — это WebPagetest. Он, конечно, не делает всё, что нужно, но если мне надо дать человеку совет, с чего начинать, то я посоветую начать с этого сервиса. Это проект с открытым исходным кодом.Вы можете прямо сейчас сами проверить свой сайт. Там всё довольно просто. Показывается время загрузки, количество запросов сколько весит страничка, сколько времени занимает загрузка тех или иных элементов, особенно хороша таблица со всеми источниками и временем по каждому и т.п. Много информации, которая может пригодиться. Это лишь синтетический тест, но очень удобный.
Полезные инструменты:
Оптимизация Ещё одна вещь, о которой я хочу поговорить. Откроем сайт www.airbnb.com в Internet Explorer. Что мы здесь увидим? Сайт имеет около 5 скриптов и три набора стилей в заголовки документа. Скорее всего, эти скрипты будут применены вне зависимости от того, на какой страницы мы находимся. А что вы обычно делаете, когда есть заголовок с некоторыми из таких скриптов, ссылок, наборов стилей и тегов? Просто «сбрасываете» их, верно? Итак, если мы сделаем это, то некоторые процессы будут стартовать немного быстрее. И это важно. В любом случае, у нас длинная страничка, два набора стилей, скрипт, пара картинок, ещё скрипт, ещё пара картинок и так далее. Происходит своего рода блокировка, от которой надо избавиться, и всё будет работать быстрее.Взглянем на тот же сайт, но уже в Chrome. Большая картинка грузится довольно быстро. Последовательность загрузки тут отличается. HTML-документ, скрипт, стиль, стиль, скрипт, скрипт, скрипт, скрипт, изображение. Совсем другая загрузка. И ведь в документе никак не указан порядок загрузки. Это всё «инициатива» Chrome. C 2008 года мы работаем над тем, чтобы сайты загружались быстрее, благодаря так называемой «спекулятивной загрузке». Раньше всё происходило так: когда вы начинаете скачивать скрипт, ничто другое в этот момент происходить не может. Если есть три скрипта подряд, тогда первый загрузится, выполнится, затем второй, выполнится и так далее. Это всё очень долго, увы. Как это реализовано в вышеуказанных браузерах: я начинаю скачивать первый скрипт и могу продолжать парсить документ, потому что скрипт может сделать что-то, что изменит состояние DOM. Но что, если я сделаю опережающий парсинг, очень лёгкий, который ищет только несколько определённых тегов, например, IMG, ссылку, IFRAME. И если я вижу их, то просто выкидываю эти запросы.
И теперь во множестве современных браузеров представлен опережающий спекулятивный парсинг, так что мы можем загружать несколько вещей параллельно. Посмотрите на все эти скрипты, скачивающиеся параллельно, и таблицы стилей, и прочие файлы. Это всё происходит благодаря спекулятивному, опережающему парсингу. Эта технология позволила в среднем на 30% ускорить загрузку сайтов.
Для пользователя очень важно взаимодействие со страницей. Без этой страницы человек смотрит просто на забавную маленькую форму. В IE у него номер запроса 6, а в Chrome 18. Вот как Chrome работает: он не предзагружает никакие картинки до первого события отрисовки. А вывод на экран заблокирован, когда скачиваются скрипты и таблицы стилей. Скрипты и CSS предзагружены, в Chrome уже есть ресурсы, которые блокируют отрисовку, которая в свою очередь блокирует старт загрузки изображений. Итак, это изображение, в соответствии с кодом, заблокировано. Что мы действительно должны сделать, и я уже говорил с разработчиками Chrome, так это сделать систему умнее. Это новый код, поэтому мы учимся, пока делаем. В целом, это довольно интересно, даёт 3% прироста в скорости. Мы должны рассматривать действительно большие картинки, специальные фоны, и может быть сделать для них больше разрешений и загружать их пораньше.
Я написал один полезный инструмент, Cuzillion. У него великий слоган «Потому что есть зиллионы страниц, которые надо проверить». Допустим, мне нужно сделать просто тестовую страничку, потому что устал делать на PHP кучу тестовых страниц. Этот скрипт за пару секунд загружается, ещё пара секунд уходит на загрузку картинки. Элементы загружаются в шахматном порядке. Конечно, можно было бы сделать и параллельно, но, по логике вещей, надо всё же так. Общее время загрузки страницы составит, скажем, 4 секунды.
Если мы поместим изображение выше сценария, то получим решение проблемы и сделаем загрузку быстрее. Но мы не можем поставить изображение в начало, зато можно перемещать скрипты вниз. Также здесь можно создать скрипты на JavaScript. Но если вы пойдёте таким путём и напишите всё на JS, то можно будет поставить его над скриптом. И теперь, если мы создадим страницу, то загрузка будет параллельной и общее время составит, например, 2 секунды вместо 4-х. Допустим, на странице есть изображение, которое задаёт тон всей странице. Что можно с ним сделать? Поместить его динамически в самый верх, до всех скриптов, и они смогут ставить картинку как значение IMG, актуальное для данной страницы.
Полезные ссылки:
Также хочу рассказать про HAR. Это формат HPR файла, JSON формат. Сегодня это промышленный стандарт. Основная идея HAR-файла — это захват всей информации с диаграммы и предоставление возможности пересоздать диаграмму из файла. Сохранённые в файлы диаграммы можно отправить по почте, опубликовать, и все желающие смогут просмотреть их. Те, кто будет делать системы анализа производительности, тоже могут взять HAR-файл и провести анализ на его основе. То есть HAR — это очень полезный инструмент, на который я хотел бы обратить ваше внимание, т.к. с его помощью можно записать то, что происходит на сайтах, включая скорость протекания различных процессов.
Полезные ссылки:
А вот другой проект, HTTP Archive http://httparchive.org/. Он был запущен около двух лет назад. Это часть Интернет-архива с archive.org, мы запускаем его каждые две недели. Сейчас тут около 300 000 ссылок. Мы взяли Топ-300000 адресов в мире и анализируем их, получаем статистику. У нас даже есть мобильная версия, однако она не пользуется особой популярностью. У нас только два iPhone, а другие телефоны сильно медленнее компьютеров, так что можно смотреть только 5000 ссылок. Тут можно посмотреть статистику, диаграммы и все ресурсы страниц. Два года назад мы просмотрели только 10 000 страниц. Надеюсь, для ваших задач это будет полезным.
Кстати, очень кратко затрону тему мобильных телефонов. Тут всё очень просто: на телефоне сайт очень медленный. Сколько времени нужно для загрузки? Не было никакого способа узнать это. И тогда я сделал LoadTimer.
Давайте представим, что вы запустили Loadtimer.org своём телефоне. Вы можете выбрать различные адреса и нажать Start. Мне понадобился час, чтобы сделать эту штуку. Это просто iFrame, он загружает в себя ваш адрес, замеряет время и показывает вам. Тут ничего сложного и этот «браузер» может загрузить любую страницу, можете хоть сейчас проверить у себя на телефоне. Пока что это, пожалуй, всё, что можно сделать интересного в мобильном веб-сегменте.
Полезные ссылки:
На этом всё. Спасибо.
