From c4f8ade4f879358c1d689ffefb3ac2cc28e138b3 Mon Sep 17 00:00:00 2001 From: Sergey Gogolev Date: Thu, 24 Sep 2015 15:54:21 +0500 Subject: [PATCH] =?UTF-8?q?=D0=94=D0=BE=D0=B1=D0=B0=D0=B2=D0=BB=D0=B5?= =?UTF-8?q?=D0=BD=D0=B0=20=D0=B7=D0=B0=D0=B4=D0=B0=D1=87=D0=B0=20=D0=BA=20?= =?UTF-8?q?=D0=BF=D0=B5=D1=80=D0=B2=D0=BE=D0=B9=20=D0=BB=D0=B5=D0=BA=D1=86?= =?UTF-8?q?=D0=B8=D0=B8:=20HTML,=20I=20=D1=87=D0=B0=D1=81=D1=82=D1=8C?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 188 ++++++++++++++++++++++++++++++++++++++++++++++++++++- index.html | 3 + 2 files changed, 190 insertions(+), 1 deletion(-) create mode 100644 index.html diff --git a/README.md b/README.md index 92d331a..3ce887e 100644 --- a/README.md +++ b/README.md @@ -1 +1,187 @@ -# verstka-tasks-1 +# Задача к лекции «HTML, I часть» + +У нас есть интересный текст из блога Яндекса с комментариями. +Предлагается превратить его в HTML документ в файле index.html. + +Постарайтесь использовать как можно больше различных элементов. + +В тексте упоминается алгоритм Флетчера. +Будет плюсом, если вы его тоже добавите в документ c помощью **текстовой разметки**: + + +```text +Блог компании Яндекс. + +ЯНДЕКС.ПОЧТА: КАК МЫ ИЗМЕРЯЕМ СКОРОСТЬ ЗАГРУЗКИ И УЛУЧШАЕМ ЕЁ + +Если ваш сайт медленно грузится, вы рискуете тем, что люди не оценят ни то, +какой он красивый, ни то, какой он удобный. Никому не понравится, когда все +тормозит. Мы регулярно добавляем в Яндекс.Почту новую функциональность, +иногда — исправляем ошибки, а это значит, у нас постоянно появляются новый код +и новая логика. Всё это напрямую влияет на скорость работы интерфейса. + +Что мы измеряем + +Этапы первой загрузки: +* подготовка; +* загрузка статики (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) +— итерационный метод численной оптимизации, предназначенный для +нахождения локального максимума/минимума нелинейного функционала +без ограничений. + +Почему именно алгоритм Флетчера, а не другие популярные алгоритмы вроде: +CRC16/32 - алгоритм нахождения контрольной суммы, предназначенный для проверки +целостности данных +md5 - 128-битный алгоритм хеширования. Предназначен для создания «отпечатков» +или дайджестов сообщения произвольной длины и последующей проверки +их подлинности. + +Потому что он быстрый, компактный и легок в реализации. + +Итог + +Фактически мы экономим 80-90% трафика. Размер загружаемой статитки в байтах: + +Релиз | С патчем | Без патча +7.7.20 | 397 | 174 549 +7.7.21 | 383 | 53 995 +7.7.22 | 483 | 3 995 + +Автор: @doochik +С++ разработик +Электронная почта: (doochik@yandex-team.ru) +Компания: Яндекс + +Комментарии (3): + +- Mogaika (mogaika@yandex-team.ru) 30 ноября 2014 в 17:05 + + А можете привести сравнение, на сколько быстрее грузится lite версия? + +- JIguse (mrawesome@yandex.ru) 29 ноября 2014 в 21:30 + + Спасибо за статью, познавательно. Здорово, что Яндекс делится некоторыми + подробностями о внутренней работе сервисов. + +- Brister (brist89@yandex-team.ru) 24 ноября 2014 в 13:13 + + (кол-во счастливых пользователей + кол-во удовлетворенных / 2) / (кол-во всех). + Получается значение от нуля до единицы, которое, видимо, лучше всего показывает, + хорошо или плохо работает почта. + + наверное все-таки от 0.5 до 1 + +- alexeimois (test@yandex.ru) 22 ноября 2014 в 17:35 + + Мы измеряем скорость загрузки с помощью Яндекс.Метрики: + help.yandex.ru/metrika/reports/monitoring_timing.xml + +© Яндекс, help@yandex.ru, Хохрякова, 10 +``` diff --git a/index.html b/index.html new file mode 100644 index 0000000..2d780b6 --- /dev/null +++ b/index.html @@ -0,0 +1,3 @@ + + +