+ Если ваш сайт медленно грузится, вы рискуете тем, что люди не оценят ни то, + какой он красивый, ни то, какой он удобный. Никому не понравится, когда все + тормозит. Мы регулярно добавляем в Doc.One новую функциональность, + иногда — исправляем ошибки, а это значит, у нас постоянно появляются новый код + и новая логика. Всё это напрямую влияет на скорость работы интерфейса. +
++ Что мы измеряем +
++ Этапы первой загрузки: +
+ +-
+
- подготовка; +
- загрузка статики (HTTP-запрос и парсинг); +
- исполнение модулей; +
- инициализация базовых объектов; +
- отрисовка. +
Этапы отрисовки любой страницы:
+-
+
- подготовка к запросу на сервер; +
- запрос данных с сервера; +
- шаблонизация; +
- обновление DOM. +
+++ — «Ок, теперь у нас есть метрики, мы можем отправить их на сервер» - говорим мы + — «Что же дальше?» - вопрошаете вы + — «А давай построим график!» - отвечаем мы + — «А что будем считать?» - уточняете вы ++
+
+
+
+ + Как вы знаете, медиана – это серединное, а не среднее значение в выборке. + Если у нас имеются числа 1, 2, 2, 3, 8, 10, 20, то медиана – 3, а среднее – 6,5. + В общем случае медиана отлично показывает, сколько грузится средний пользователь. +
++ В случае ускорения или замедления медиана, конечно, изменится. Но она не может + рассказать, сколько пользователей ускорилось, а сколько замедлилось. +
++ APDEX – метрика, которая сразу говорит: хорошо или плохо. Метрика + работает очень просто. Мы выбираем временной интервал [0; t], такой, что если + время показа страницы попало в него, то пользователь счастлив. Берем еще один + интервал, (t; 4t] (в четыре раза больше первого), и считаем, что если страница + показана за это время, то пользователь в целом удовлетворен скоростью работы, + но уже не настолько счастлив. И применяем формулу: +
++ (кол-во счастливых пользователей + кол-во удовлетворенных / 2) / (кол-во всех). + Получается значение от нуля до единицы, которое, видимо, лучше всего показывает, + хорошо или плохо работает почта. +
++ Как мы измеряем +
++ Сейчас модуль обновления сам логирует все свои стадии, и можно легко понять + причину замедления: медленнее стал отвечать сервер либо слишком долго + выполняется JavaScript. Выглядит это примерно так: +
+
+ this.timings['look-ma-im-start'] = Date.now();
+ this.timings['look-ma-finish'] = Date.now();
+
+ + C помощью Date.now() мы получаем текущее время. Все тайминги собираются и при + отправке рассчитываются. На этапах разница между “end” и “start” не считается, + а все вычисления производятся в конце: +
+
+ var totalTime = this.timings['look-ma-finish'] - this.timings['look-ma-im-start'];
+
+ + И на сервер прилетают подобные записи: +
+
+ serverResponse=50&domUpdate=60
+
+ + Как мы ускоряем +
++ Чтобы снизить время загрузки почты при выходе новых версий, + мы уже делаем следующее: +
+-
+
- включаем gzip; +
- выставляем заголовки кэширования; +
- фризим CSS, JS, шаблоны и картинки; +
- используем CDN; +
+ Мы подумали: «А что если хранить где-то старую версию файлов, а при выходе новой + передавать только diff между ней и той, которая сохранена у пользователя?» + В браузере же останется просто наложить патч на клиенте. +
++ На самое деле эта идея не нова. Уже существуют стандарты для HTTP — например, + RFC 3229 «Delta encoding in HTTP» и «Google SDHC», — но по разным причинам они + не получили должного распространения в браузерах и на серверах. +
++ Мы же решили сделать свой аналог на JS. Чтобы реализовать этот метод обновления, + начали искать реализации diff на JS. На популярных хостингах кода нашли + библиотеки: +
++++ - VCDiff + - google-diff-patch-match ++
+ Для окончательного выбора библиотеки нам нужно сравнить: +
++ Библиотека | IE 9 | Opera 12 + ---------- | ---- | -------- + vcdiff | 8 | 5 + google diff | 1363 | 76 ++
+ После того как мы определились с библиотекой для диффа, нужно определиться с тем, + где и как хранить статику на клиенте. +
++ Формат файла с патчами для проекта выглядит так: +
+
+ [
+ {
+ "k": "jane.css",
+ "p": [patch],
+ "s": 4554
+ },
+ {
+ "k": "jane.css",
+ "p": [patch],
+ "s": 4554
+ }
+ ]
+
+ + То есть это обычный массив из объектов. Каждый объект — отдельный ресурс. У + каждого объекта есть три свойства. k — названия ключа в localStorage для этого + ресурса. p — патч для ресурса, который сгенерировал vcdiff. s — чексумма для + ресурса актуальной версии, чтобы потом можно было проверить правильность + наложения патча на клиенте. Чексумма вычисляется по алгоритму Флетчера. +
++ Алгоритм Бройдена — Флетчера — Гольдфарба — Шанно (BFGS) + — итерационный метод численной оптимизации, предназначенный для + нахождения локального максимума/минимума нелинейного функционала + без ограничений. +
+ + ++ - Mogaika (mogaika@pravo.ru) + А можете привести сравнение, на сколько быстрее грузится lite версия? ++
+ - JIguse (mrawesome@pravo.ru) + Спасибо за статью, познавательно. Здорово, что Pravo.ru делится некоторыми + подробностями о внутренней работе сервисов. ++
+ - Brister (brist89@pravo.ru) + (кол-во счастливых пользователей + кол-во удовлетворенных / 2) / (кол-во всех). + Получается значение от нуля до единицы, которое, видимо, лучше всего показывает, + хорошо или плохо работает почта. + наверное все-таки от 0.5 до 1 ++
+ - alexeimois (test@pravo.ru) ++