Web-worker — это механизм, который позволяет вынести выполнение кода из главного потока браузера. Он доступен в браузерах уже более 10 лет. Проблема в том, что загрузка дополнительного кода в воркерах застряла в 2009 году — там используется синхронная функция loadScripts(), которая загружает код в глобальную область видимости модуля. Джейсон Миллер из Google рассказал про новый подход, который позволяет устранить недостатки старого подхода работы с модульным кодом в веб-воркерах — "Threading the web with module workers".

Новый подход использует ESM ( import/export ), тем самым автоматически подхватывая все преимущества загрузчика новой модульной системы (параллельная загрузка кода, предварительная загрузка и парсинг кода с помощью хинта modulepreload ). Тип воркера необходимо указывать при его создании, передавая дополнительный аргумент {type: 'module'}:

const worker = new Worker('worker.js', {
  type: 'module'
});

На данный момент поддержка module workers есть только в Chrome 80. Идёт работа над поддержкой ESM в service workers.

#esm #webworkers

https://web.dev/module-workers/

В проектах со сложной структурой и большой командой для поддержки инфраструктуры может использоваться специальный процесс — фронтопс. Анна Селезнёва на прошедшем Web Standards Days рассказала, что скрывается за этим термином в докладе "Фронтопс? Серьёзно?"

Фронтопс (так же как и девопс) — это методология, которая позволяет связать в одно целое процесс написания кода и его доставку до пользователя (то есть всю инфраструктуру). В компаниях, которые в той или иной мере следуют этой методологии, для решения инфраструктурных задач, связанных с фронтендом, выделяют отдельную команду разработчиков или разработчика. Подобные команды есть в Яндекс.Маркете, PayPal, Apple. В докладе рассказывается про историю появления термина "фронтопс" и задачи, которые решаются в его рамках: сборка, линтинг, тесты, сбор ошибок, ci и т.п.

Доклад хороший — рекомендую посмотреть, особенно, если в вашем проекте есть пробелы в инфраструктуре, и вы хотите что-то с этим сделать.

#frontops #talk

https://www.youtube.com/watch?v=yWPAW59e1AU

Небольшие новости

Где-то месяц назад я ушёл из Яндекса, и теперь у меня кончились деньги и еда. Шучу. Но из Яндекса я, правда, ушёл. Как бы то ни было, это были три очень крутых года в Маркете, которые меня многому научили. Вторая новость — почти не новость. Через несколько месяцев планирую проапгрейдить Defront. Как говорят, "Stay tuned".

Хочу напомнить, что у канала есть чат для обсуждения новостей — @defrontchat. Присоединяйтесь! И подписывайтесь на мой твиттер https://twitter.com/myshov. Там я публикую и ретвичу интересные новости и апдейты, которые сюда не попадают.

Спасибо за то, что читаете канал и поддерживаете добрым словом.

Петер Хеденског рассказал, как на Wikipedia измеряется отзывчивость сайта — "Measuring Long Tasks and First Input Delay".

Для измерения отзывчивости в Wikipedia используют Long Tasks API и метрику First Input Delay (доступны только в Chrome). Long Tasks API позволяет найти задачи, выполнение которых занимает более 50 мс в основном потоке. В собираемых данных нет информации о том, какая именно задача забивала поток, поэтому в синтетическом окружении дополнительно собираются логи производительности, это помогает в поиске конкретных задач. First Input Delay показывает, сколько времени занимает отклик после первого взаимодействия со страницей. Эту метрику сложно измерить адекватно в синтетическом окружении, но её можно аппроксимировать с помощью max potential first input delay.

Статья хорошая. Рекомендую почитать, если интересно узнать, какие есть грабли при сборе метрик.

#performance #metrics #wikipedia

https://calendar.perfplanet.com/2019/measuring-long-tasks-and-first-input-delay/

Никогда такого не было и вот опять. Пару дней назад в твиттере выясняли, что лучше использовать const или let.

На этот раз этот всё началось с твита Дэна Абрамова, в котором он пошутил над участниками Reddit по поводу его недавней статьи, где он предлагал использовать let. В треде он упомянул старый твит, в котором разработчики стандарта признают, что добавление двух способов для декларации переменных в блочном скоупе было ошибкой. Также в тред пришёл Аллен Вирфс-Брок — участник TC39, работавший над ES2015. Он написал, что const и let — наследие ES4, которому не придали большого внимания при переносе в ES2015. Аллен пишет, что если бы он мог это исправить, то оставил бы только const, но переименовал бы его в let. Затем в тред пришёл Брендан Айк и написал, что добавление const было вынужденной мерой, так как в некоторых движках он уже был имплементирован.

В итоге Дэн написал статью "On let vs const", где сравнил преимущества и недостатки использования eslint-правила prefer-const. Вывод простой — используйте то, что вам больше нравится.

#history #es2015 #tc39

https://overreacted.io/on-let-vs-const/
https://twitter.com/littlecalculist/status/917875241891676160
https://twitter.com/awbjs/status/1208447372910444544

Safari 13 был выпущен в сентябре. Прошло больше двух месяцев, и в блоге WebKit появился пост про все новые фичи, которые стали доступны — "New WebKit Features in Safari 13".

Safari на iPadOS (кроме iPad Mini) теперь по умолчанию отправляет User Agent десктопного Safari. В режиме многозадачности, когда браузер занимает одну треть экрана, User Agent становится Safari для iOS.

Была добавлена поддержка нового API Pointer Events, который абстрагирует разные устройства ввода и предоставляет информацию о координатах указателя, нажатых кнопках, наклоне стилуса и силы его нажатия.

Добавили Visual Viewport API, благодаря которому можно получить координаты части страницы, которая видима пользователю в данный момент. С помощью этого API можно адаптировать отображаемый контент, например, когда открывается экранная клавиатура.

С версии Safari 13 скролл с инерцией применяется ко всем элементам с overflow: scroll. Ранее для этого использовалось свойство -webkit-overflow-scrolling: touch; — сейчас оно потеряло свою актуальность.

Благодаря новому WebDriver теперь можно использовать реальные устройства (iPad, iPhone) для автоматического тестирования сайтов.

Улучшили производительность движка. На 50% ускорили загрузку сайтов на watchOS. Добавили поддержку тёмного режима. Работали над улучшением механизма предотвращения трекинга пользователей. Добавили поддержку физических ключей безопасности FIDO2. Apple Pay теперь доступен во WebView. Улучшили поддержку медиа-источников — WebKit сейчас поддерживает прозрачность в видео с альфа-каналом. Улучшили инструменты разработчика.

#webkit #announcement

https://webkit.org/blog/9674/new-webkit-features-in-safari-13/

Есть очень быстрая библиотека для работы с картами — Leaflet (используют в Facebook, Github, 2ГИС). Она была разработана Владимиром Агафонкиным. Вова помешан на производительности; и вот месяц назад он рассказал доклад "Fast by default: algorithmic performance optimization".

В докладе он рассказывает про случаи из практики, где применение алгоритмов помогло сильно оптимизировать код. Разобрал конкретные паттерны в коде, которые должны вызывать подозрение. В конце доклада поделился такими мыслями:
— изучайте исходный код инструментов и библиотек;
— копайтесь в фреймворках;
— участвуйте в open source проектах;
— не бойтесь изобретать колесо;
— постоянно упрощайте свой код;
— оптимизируйте свой код, это научит вас писать быстрый код сразу.

В общем, доклад крутой. Рекомендую посмотреть.

#talk #performance #algorithm

https://www.youtube.com/watch?v=hh6SohUq1yQ&feature=youtu.be

Нашёл большое исследование произодительности сайтов от SEO-агентства Backlink — "We Analyzed 5.2 Million Desktop and Mobile Pages. Here’s What We Learned About Page Speed".

Исследование проводилось на основе данных HTTP Archive 2019 года. В нём есть несколько интересных выводов. Например, что использование CDN коррелирует c наихудшим индексом Page Speed как на десктопах, так и на мобильных устройствах. Наихудший результат показал Akamai. При исследовании таймингов TTFB (Time To First Byte) по регионам быстрее всех оказался Китай, за ним Япония и Китай. Россия, Франция, Великобритания и США показали средний TTFB. Наихудший результат у Австралии, Бразилии и Индии. Тем не менее в отчёте есть сомнительные моменты, например, при исследовании JS-фреймворков наряду с React, Vue и Angular в список попали Handlebars.js и Require.js.

Как бы то ни было, если занимаетесь производительностью, настоятельно рекомендую посмотреть отчёт. Было бы круто, если бы кто-нибудь ещё сделал подобное исследование, чтобы исключить неверную интерпретацию данных (идея для pr-отдела вашей компании).

#performance #web

https://backlinko.com/page-speed-stats

Наконец-то добрался поизучать итоги последнего исследования JavaScript-экосистемы — State of JS 2019. Данных очень много, поэтому перечислю, на мой взгляд, самое интересное.

В исследовании участвовало более 20 тысяч разработчиков. TypeScript третий год подряд остаётся самым популярным альтернативным языком web'а. Angular и Redux сдают позиции — в этом году большее число респондентов остались ими недовольны. У Jest самый высокий уровень лояльности — 96% остались им довольны. Наиболее используемые библиотеки — lodash, moment и jquery. По сравнению с прошлым годом большее количество опрошенных перешло с moment на современные аналоги — luxon/date-fns. GraphQL используют уже 38%, в прошлом году было 20%.

#js #survey

https://2019.stateofjs.com

Дэвид Калхоун написал статью про влияние на производительность разных подходов к бандлингу кода — "Bundling JavaScript for Performance: Best Practices".

Самый лучший вариант отделить вендорный код от кода приложения и доставлять бандлы до пользователей с помощью CDN-провайдеров. Подключение библиотек, которые хранятся на публичных CDN (cdnjs, jsdelivr и т.п.), нежелательно. В Safari использование публичных CDN приводит к лишнему запросу даже в том случае, когда в соседней вкладке другой сайт загружал ту же самую библиотеку с того же самого сервера. Это сделано для предотвращения отслеживания пользователей. В Chrome отключение общего кеша появилось с 77-ой версии, но пока за флагом.

Статья неплохая. Стоит почитать, если хотите узнать про подходы к бандлингу, их плюсы и минусы.

#performance #bundle

https://calendar.perfplanet.com/2019/bundling-javanoscript-for-performance-best-practices/

Эрик Лоуренс — работает над Edge — собрал хорошую подборку способов взаимодействия web-приложений с нативными приложениями — "Browser Architecture: Web-to-App Communication Overview".

— Application Protocols. Приложения могут зарегистрировать в системе протокол, при переходе по которому браузер будет их запускать.
— Native Messaging via Extensions. Браузерные расширения могут общаться с нативными приложениями с помощью nativeMessaging API.
— File downloads (Traditional). Приложения могут зарегистрировать себя в системе таким образом, чтобы они открывались при загрузке файлов.
— File downloads (DirectInvoke). Тоже самое, что и предыдущий пункт, но приложение открывает не загруженный файл, а ссылку на него. Поддерживается только в IE/Edge.
— Local Web Server. Приложение может запустить локальный web-сервер, с которым будет общаться web-приложение с помощью WebRTC, WebSocket, Fetch и т.п. Может быть небезопасно.
— Android Intents. Похоже на App Protocols — страница может запустить приложение для обработки конкретной задачи.
— Legacy Plugins/ActiveX. Пожалуйста, не используйте. Это один из самых больших источников уязвимостей в истории web'а.

Статья хорошая с большим количеством полезных ссылок. Очень рекомендую почитать, если решаете задачу взаимодействия web'а с нативными приложениями.

#web #integration

https://textslashplain.com/2019/08/28/browser-architecture-web-to-app-communication-overview/

Изменение контента страницы может влиять на fps или блокировать работу со страницей из-за большого объёма работы, которую надо выполнить браузеру. Например, изменение свойства left у одного элемента может вызвать проверку необходимости изменения положения для каждого элемента в DOM-дереве, что неэффективно. Именно для решения этой проблемы была разработана спецификация CSS Containment. Рейчел Эндрю недавно написала про неё статью — "Helping Browsers Optimize With The CSS Contain Property".

CSS Containment определяет одно свойство — contain, которое может содержать значения layout, paint, size, content и strict. Все эти значения подсказывают браузеру, что изменения внутри элемента, к которому применено свойство, не влияют на другие элементы, поэтому браузер может производить дополнительные оптимизации, сокращая время на рендеринг и лайаут контента. У всех этих значений есть нюансы использования. Например, одни значения влияют на отображение контента, другие создают блочный контекст форматирования и т.п. В статье рекомендуется использовать contain: content для web-приложений, построенных на базе компонентного подхода.

CSS Containment стал официальным стандартом месяц назад. Поддержка этой спеки есть в Chrome и Firefox.

#css #performance

https://www.smashingmagazine.com/2019/12/browsers-containment-css-contain-property/

В 2019 было много событий, которые на меня очень сильно повлияли — одним таким событием стало появление Defront. Мне очень дорог этот канал и все, кто его читает. Благодаря вам я выработал дисциплину и узнал очень много нового. Хочу пожелать вам в этом году удачи, усердия и достижения своих целей. У вас всё получится. Я в вас верю.

С наступающим Новым годом!

Недавно на канале был пост про подборку статей от Эрика Лоуренса. В ноябре он написал ещё один пост про то, как использовать обработчики схем для коммуникации между web-приложениями — "Web-to-WebApp Communication: Custom Scheme Handlers".

Это полезная фича, которая приносит удобство нативных приложений в web. С помощью неё можно настроить обработку схем на страницах таким образом, чтобы вместо нативных приложений открывались их web-аналоги. Например, gmail может открываться автоматически при клике на ссылках со схемой mailto:. Это фича работает благодаря API registerProtocolHandler. Для обработки доступны предопределённые схемы ( mailto, magnet, tel, sip, sms и т.п.) и кастомные схемы вида web+{one-or-more-lowercaseASCII}.

На данный момент registerProtocolHandler поддерживается в Firefox и Chrome.

#web #integration

https://textslashplain.com/2019/11/21/web-to-webapp-communication-custom-scheme-handlers/

Лоит Бэллад из Cloudflare написал статью про то, как они тестируют разрабатываемые протоколы — "How to develop a practical transport protocol".

На данный момент Cloudflare участвует в разработке QUIC и HTTP/3. Отладка сетевого стека — нетривиальная задача, особенно, если речь идёт об отладке на реальных мобильных устройствах. В самом простом случае разрабатывать протокол можно на одном компьютере, используя сеть из docker-контейнеров. Но такой подход не может выявить проблемы, которые могут возникнуть в реальном мире. Поэтому для полноценного тестирования создаются специальные "лаборатории" — выделенные машины, соединённые между собой в сеть. Для эмуляции edge, 3g, lte используется netem (на Linux) и ipfw + dummynet (на FreeBSD). Меня немного позабавило, что ребята взламывают девайсы на iOS, для того, чтобы понять, как будут работать новые протоколы на реальном железе от Apple.

В общем, статья интересная. Рекомендую почитать, если хотите узнать, как разрабатываются протоколы.

#http #debug #net

https://calendar.perfplanet.com/2019/how-to-develop-a-practical-transport-protocol/

Попалась на глаза статья Марси Саттон про использование кнопок и ссылок в современных web-интерфейсах — "Links vs. Buttons in Modern Web Applications".

Можно с лёгкостью найти сайты, в которых кнопки в разметке страницы представлены как ссылки и наоборот. Например, на github есть три кнопки: "Create new file", "Upload files", "Find file". В коде странице "Create new file" испльзует тег <button>, "Upload files", "Find file" используют тег <a>. Из-за это пользователи сталкиваются со странностями в интерфейсе: "Почему я могу открыть поиск файла в новой вкладке с помощью контекстного меню, а страницу создания файла открыть не могу?" Марси призывает использовать каждый элемент там, где он подходит больше всего: ссылки для перехода со страницы на страницу, или для переключения страниц в SPA-приложении; кнопки для открытия модальных окон и проигрывания медиа-контента.

Очень рекомендую почитать статью — именно такие мелочи, про которые пишет Марси, формируют хороший пользовательский опыт.

#a11y #ux

https://marcysutton.com/links-vs-buttons-in-modern-web-applications

В конце октября в код Hermes (JavaScript-движок от Facebook, который используется в React Native на Android) был влит код с оптимизацией конкатенации строк.

Простая реализация конкатенации может привести к квадратичной сложности из-за копирования строк, поэтому в современных движках (например, в v8) для конкатенации строк используется дерево-подобная структура — rope. У этого подхода есть накладные расходы — для одного символа может выделяться один объект. В Hermes используется другой подход. Для конкатенации используется специальный буфер, куда добавляются все строки. Новая оптимизация ускорила pdfjs в три раза.

Если есть возможность можно помочь движку с конкатенацией, переписав код. Кристофер Чедоу пару лет назад написал пост про особенности реализации конкатенации строк — "Efficient String Encoding for Concatenation". Там он предлагает заменить конкатенацию строк join'ом массива строк. Потенциально это может ускорить код, который очень активно работает со строками.

#performance #js #internals

https://blog.vjeux.com/2018/javanoscript/efficient-string-encoding-for-concatenation.html
https://github.com/facebook/hermes/commit/fc2674b1ed207fb5967f75d1159e5f0b8c46fa8d

Сегодня вспомнил такое выражение: "Make It Work Make It Right Make It Fast". Насколько я помню, видел (или услышал) её в контексте разработки алгоритмов. Сегодня стало интересно, откуда она появилась.

Автор этой фразы Кент Бек; в другой формулировке она существует как часть философии Unix. Интерпретировать её можно по-разному, но в общем виде её можно понять так:
1. Сначала сделайте задачу с наименьшим количеством движущихся частей (Make It).
2. Потом следует обработать все крайние случаи и потенциальные ошибки (Make It Right).
3. И только потом можно заниматься оптимизацией (Make It Fast). Если для задач, с которыми не приходилось работать, сразу пытаться писать оптимизированный код, то такая преждевременная оптимизация усложнит систему и превратит её в то, что невозможно будет понять.

Как мне близок последний пункт. Помню, решал последнюю задачу из курса по алгоритмам от Стенфорда на Coursera (очень рекомендую пройти). Там надо было с помощью перебора решить NP-complete задачу. Использовал для решения задач C (потому что быстро, конечно). Ну и в итоге запутался в своём коде... Курс закончил, но было бы гораздо проще, если бы использовал python (javanoscript система проверки заданий не принимала).

#programming #musings #performance

https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast

Прочитал статью Мэтта Голдуотера про историю появления npm, yarn и pnpm — "An abbreviated history of JavaScript package managers". В статье рассказывается, почему у нас сейчас есть три конкурирующих менеджера, их плюсы и минусы.

Npm был стандартом де-факто, до появления yarn, в котором были исправлены проблемы со скоростью установки пакетов, была добавлена возможность offline-установки и предсказуемые сборки благодаря yarn.lock. Появление конкурента повлияло на развитие npm и уже в пятой версии в нём появились практически все возможности, которые на то время предоставлял yarn.

Летом 2017 года Золтан Кохан представил первую версию pnpm. В этом пакетном менеджере была решена проблема потребления дискового пространства и проблема прямого доступа к зависимостям зависимостей. Первый пункт стал киллер-фичей нового менеджера, что в свою очередь побудило разработчиков yarn реализовать своё решение для сокращения объёма хранящихся зависимостей — Yarn Plug'n'Play (Yarn PnP), который будет включён по умолчанию во второй версии yarn. Разработчики npm пошли дальше и представили новый пакетный менеджер — tink, в котором установка пакетов (то есть использование команд npm install some-package ) становится не нужна благодаря использованию особого механизма резолвинга зависимостей, который при необходимости автоматически устанавливает пакеты в общее хранилище.

Статья очень хорошая. Рекомендую почитать, если вам интересно узнать про текущее состояние пакетных менеджеров и планы их развития.

#package #history #js #npm

https://medium.com/javanoscript-in-plain-english/an-abbreviated-history-of-javanoscript-package-managers-f9797be7cf0e

Нашёл хорошую статью, объясняющую разные способы комбинирования стримов в RxJS — "Comprehensive Guide to Higher-Order RxJS Mapping Operators: switchMap, mergeMap, concatMap (and exhaustMap)".

Самое полезное, что стоит выделить (под стримом здесь понимается создаваемый в операторе внутренний Observable):

- concatMap для обработки стримов по очереди;
- mergeMap для обработки стримов параллельно;
- switchMap если нужно отменять стримы, созданные ранее;
- exhaustMap для игнорирования создания новых стримов, если текущий стрим ещё не был завершён;

В общем, рекомендую почитать, если хотите углубить своё понимание RxJS. В примерах используется Angular, но только как декорации.

#rxjs #angular

https://blog.angular-university.io/rxjs-higher-order-mapping/

Филип Уолтон из Google поделился техникой сокращения объёма скачиваемых страниц — "Smaller HTML Payloads with Service Workers".

Филип предлагает разделять страницу на составные части (в его примере — шапка, контент, подвал) и склеивать их в исходную страницу на уровне сервис-воркера. Благодаря такому подходу клиент будет загружать шапку и подвал только один раз. При этом можно не дожидаться загрузки контента, а начинать стримить склеиваемую страницу прямо из сервис-воркера, что ещё сильнее сказывается на сокращении First Contentful Paint (в блоге Филипа FCP уменьшился на 52%). Чтобы не ломать SEO, нужно создать полноценную страницу, которая будет раздаваться обычным web-сервером.

Очень рекомендую почитать статью. Описанную технику можно использовать для ускорения не только статических сайтов, но и SPA.

#performance #serviceworker

https://philipwalton.com/articles/smaller-html-payloads-with-service-workers/