From c785dcc6cf8247732e90bf7281bf8ccdfa3298e4 Mon Sep 17 00:00:00 2001 From: VolodinaO Date: Wed, 20 Mar 2019 02:25:45 +0400 Subject: [PATCH 1/3] Create index.html --- index.html | 317 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 317 insertions(+) create mode 100644 index.html diff --git a/index.html b/index.html new file mode 100644 index 0000000..a4dc877 --- /dev/null +++ b/index.html @@ -0,0 +1,317 @@ + + + + + Блог компании Pravo. + + + + +
+

+ Блог компании Pravo. +

+
+ +
+ +
+ + +
+

+ КАК МЫ ИЗМЕРЯЕМ СКОРОСТЬ ЗАГРУЗКИ И УЛУЧШАЕМ ЕЁ +

+
+ + +
+
+ Если ваш сайт медленно грузится, вы рискуете тем, что люди не оценят ни то, + какой он красивый, ни то, какой он удобный. Никому не понравится, когда все + тормозит. Мы регулярно добавляем в 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. На популярных хостингах кода нашли + библиотеки: +

    +
  1. VCDiff
    2. +
  2. google-diff-patch-match
    3. +
+

Для окончательного выбора библиотеки нам нужно сравнить: +
+ + + + + + + + + + + + + + + + +
БиблиотекаIE 9Opera 12
vcdiff85
google diff136376
+

+ После того как мы определились с библиотекой для диффа, нужно определиться с тем, + где и как хранить статику на клиенте. +

+ Формат файла с патчами для проекта выглядит так: +
+ + [
+ {
+ "k": "jane.css",
+ "p": [patch],
+ "s": 4554
+ },
+ {
+ "k": "jane.css",
+ "p": [patch],
+ "s": 4554
+ }
+ ] + +

+ То есть это обычный массив из объектов. Каждый объект — отдельный ресурс. У + каждого объекта есть три свойства. k — названия ключа в localStorage для этого + ресурса. p — патч для ресурса, который сгенерировал vcdiff. s — чексумма для + ресурса актуальной версии, чтобы потом можно было проверить правильность + наложения патча на клиенте. Чексумма вычисляется по алгоритму Флетчера. +

+ Алгоритм Бройдена — Флетчера — Гольдфарба — Шанно (BFGS)
+ — итерационный метод численной оптимизации, предназначенный для + нахождения локального максимума/минимума нелинейного функционала + без ограничений. +

+ + Почему именно алгоритм Флетчера, а не другие популярные алгоритмы вроде:
+

    +
  1. + CRC16/32 - алгоритм нахождения контрольной суммы, предназначенный для проверки + целостности данных +
    2. +
  2. + md5 - 128-битный алгоритм хеширования. Предназначен для создания «отпечатков» +
    3. +
  3. + или дайджестов сообщения произвольной длины и последующей проверки их подлинности. +
    4. +
+

+ Потому что он быстрый, компактный и легок в реализации. +

+ Итог +

+

+ Фактически мы экономим 80-90% трафика. Размер загружаемой статитки в байтах: +
+ + + + + + + + + + + + + + + + + + + + + +
РелизС патчемБез патча
7.7.20397174 549
7.7.2138353 995
7.7.224833 995
+
+

+ + + +
+ +
+ +
+
+

+ Комментарии (3): +

+
+ +
+
+ - + Mogaika + (mogaika@pravo.ru) + +
+ +

+ А можете привести сравнение, на сколько быстрее грузится lite версия? +

+ +
+
+ - + JIguse + (mrawesome@pravo.ru) +
+ +

+ Спасибо за статью, познавательно. Здорово, что Pravo.ru делится некоторыми + подробностями о внутренней работе сервисов. +

+ +
+
+ - + Brister + (brist89@pravo.ru) +
+ +

+

+ + (кол-во счастливых пользователей + кол-во удовлетворенных / 2) / (кол-во всех). + Получается значение от нуля до единицы, которое, видимо, лучше всего показывает, + хорошо или плохо работает почта. + +
+ +

наверное все-таки от 0.5 до 1 +

+ + +
+
+ + \ No newline at end of file From 39d9a4eda06e9bc49fa35172e6ef5531567bf3fb Mon Sep 17 00:00:00 2001 From: VolodinaO Date: Wed, 20 Mar 2019 02:31:32 +0400 Subject: [PATCH 2/3] Revert "Create index.html" This reverts commit c785dcc6cf8247732e90bf7281bf8ccdfa3298e4. --- index.html | 317 ----------------------------------------------------- 1 file changed, 317 deletions(-) delete mode 100644 index.html diff --git a/index.html b/index.html deleted file mode 100644 index a4dc877..0000000 --- a/index.html +++ /dev/null @@ -1,317 +0,0 @@ - - - - - Блог компании Pravo. - - - - -
-

- Блог компании Pravo. -

-
- -
- -
- - -
-

- КАК МЫ ИЗМЕРЯЕМ СКОРОСТЬ ЗАГРУЗКИ И УЛУЧШАЕМ ЕЁ -

-
- - -
-
- Если ваш сайт медленно грузится, вы рискуете тем, что люди не оценят ни то, - какой он красивый, ни то, какой он удобный. Никому не понравится, когда все - тормозит. Мы регулярно добавляем в 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. На популярных хостингах кода нашли - библиотеки: -

    -
  1. VCDiff
    2. -
  2. google-diff-patch-match
    3. -
-

Для окончательного выбора библиотеки нам нужно сравнить: -
- - - - - - - - - - - - - - - - -
БиблиотекаIE 9Opera 12
vcdiff85
google diff136376
-

- После того как мы определились с библиотекой для диффа, нужно определиться с тем, - где и как хранить статику на клиенте. -

- Формат файла с патчами для проекта выглядит так: -
- - [
- {
- "k": "jane.css",
- "p": [patch],
- "s": 4554
- },
- {
- "k": "jane.css",
- "p": [patch],
- "s": 4554
- }
- ] - -

- То есть это обычный массив из объектов. Каждый объект — отдельный ресурс. У - каждого объекта есть три свойства. k — названия ключа в localStorage для этого - ресурса. p — патч для ресурса, который сгенерировал vcdiff. s — чексумма для - ресурса актуальной версии, чтобы потом можно было проверить правильность - наложения патча на клиенте. Чексумма вычисляется по алгоритму Флетчера. -

- Алгоритм Бройдена — Флетчера — Гольдфарба — Шанно (BFGS)
- — итерационный метод численной оптимизации, предназначенный для - нахождения локального максимума/минимума нелинейного функционала - без ограничений. -

- - Почему именно алгоритм Флетчера, а не другие популярные алгоритмы вроде:
-

    -
  1. - CRC16/32 - алгоритм нахождения контрольной суммы, предназначенный для проверки - целостности данных -
    2. -
  2. - md5 - 128-битный алгоритм хеширования. Предназначен для создания «отпечатков» -
    3. -
  3. - или дайджестов сообщения произвольной длины и последующей проверки их подлинности. -
    4. -
-

- Потому что он быстрый, компактный и легок в реализации. -

- Итог -

-

- Фактически мы экономим 80-90% трафика. Размер загружаемой статитки в байтах: -
- - - - - - - - - - - - - - - - - - - - - -
РелизС патчемБез патча
7.7.20397174 549
7.7.2138353 995
7.7.224833 995
-
-

- - - -
- -
- -
-
-

- Комментарии (3): -

-
- -
-
- - - Mogaika - (mogaika@pravo.ru) - -
- -

- А можете привести сравнение, на сколько быстрее грузится lite версия? -

- -
-
- - - JIguse - (mrawesome@pravo.ru) -
- -

- Спасибо за статью, познавательно. Здорово, что Pravo.ru делится некоторыми - подробностями о внутренней работе сервисов. -

- -
-
- - - Brister - (brist89@pravo.ru) -
- -

-

- - (кол-во счастливых пользователей + кол-во удовлетворенных / 2) / (кол-во всех). - Получается значение от нуля до единицы, которое, видимо, лучше всего показывает, - хорошо или плохо работает почта. - -
- -

наверное все-таки от 0.5 до 1 -

- - -
-
- - \ No newline at end of file From f19f9481d452b4973e34e9571e1a3884e3ff284e Mon Sep 17 00:00:00 2001 From: VolodinaO Date: Wed, 20 Mar 2019 06:42:41 +0400 Subject: [PATCH 3/3] Create index.html --- index.html | 317 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 317 insertions(+) create mode 100644 index.html diff --git a/index.html b/index.html new file mode 100644 index 0000000..1117562 --- /dev/null +++ b/index.html @@ -0,0 +1,317 @@ + + + + + Блог компании Pravo. + + + + +
+

+ Блог компании Pravo. +

+
+ +
+ +
+ + +
+

+ КАК МЫ ИЗМЕРЯЕМ СКОРОСТЬ ЗАГРУЗКИ И УЛУЧШАЕМ ЕЁ +

+
+ + +
+
+ Если ваш сайт медленно грузится, вы рискуете тем, что люди не оценят ни то, + какой он красивый, ни то, какой он удобный. Никому не понравится, когда все + тормозит. Мы регулярно добавляем в 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. На популярных хостингах кода нашли + библиотеки: +

    +
  1. VCDiff
    2. +
  2. google-diff-patch-match
    3. +
+

Для окончательного выбора библиотеки нам нужно сравнить: +
+ + + + + + + + + + + + + + + + +
БиблиотекаIE 9Opera 12
vcdiff85
google diff136376
+

+ После того как мы определились с библиотекой для диффа, нужно определиться с тем, + где и как хранить статику на клиенте. +

+ Формат файла с патчами для проекта выглядит так: +
+ + [
+ {
+ "k": "jane.css",
+ "p": [patch],
+ "s": 4554
+ },
+ {
+ "k": "jane.css",
+ "p": [patch],
+ "s": 4554
+ }
+ ] + +

+ То есть это обычный массив из объектов. Каждый объект — отдельный ресурс. У + каждого объекта есть три свойства. k — названия ключа в localStorage для этого + ресурса. p — патч для ресурса, который сгенерировал vcdiff. s — чексумма для + ресурса актуальной версии, чтобы потом можно было проверить правильность + наложения патча на клиенте. Чексумма вычисляется по алгоритму Флетчера. +

+ Алгоритм Бройдена — Флетчера — Гольдфарба — Шанно (BFGS)
+ — итерационный метод численной оптимизации, предназначенный для + нахождения локального максимума/минимума нелинейного функционала + без ограничений. +

+ + Почему именно алгоритм Флетчера, а не другие популярные алгоритмы вроде:
+

    +
  1. + CRC16/32 - алгоритм нахождения контрольной суммы, предназначенный для проверки + целостности данных +
    2. +
  2. + md5 - 128-битный алгоритм хеширования. Предназначен для создания «отпечатков» +
    3. +
  3. + или дайджестов сообщения произвольной длины и последующей проверки их подлинности. +
    4. +
+

+ Потому что он быстрый, компактный и легок в реализации. +

+ Итог +

+

+ Фактически мы экономим 80-90% трафика. Размер загружаемой статитки в байтах: +
+ + + + + + + + + + + + + + + + + + + + + +
РелизС патчемБез патча
7.7.20397174 549
7.7.2138353 995
7.7.224833 995
+
+

+ + + +
+ +
+ +
+
+

+ Комментарии (3): +

+
+ +
+
+ - + Mogaika + (mogaika@pravo.ru) + +
+ +

+ А можете привести сравнение, на сколько быстрее грузится lite версия? +

+ +
+
+ - + JIguse + (mrawesome@pravo.ru) +
+ +

+ Спасибо за статью, познавательно. Здорово, что Pravo.ru делится некоторыми + подробностями о внутренней работе сервисов. +

+ +
+
+ - + Brister + (brist89@pravo.ru) +
+ +

+

+ + (кол-во счастливых пользователей + кол-во удовлетворенных / 2) / (кол-во всех). + Получается значение от нуля до единицы, которое, видимо, лучше всего показывает, + хорошо или плохо работает почта. + +
+ +

наверное все-таки от 0.5 до 1 +

+ + +
+
+ + \ No newline at end of file