Эрик Лоуренс — работает над 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/

Вчера вышел Firefox 72. Крис Миллс рассказал, что было добавлено в этой версии — "Firefox 72 — our first song of 2020".

В инструментах разработчика появилась возможность ставить точки останова на сеттерах и геттерах. В Firefox Developer Edition console.trace() и console.error() теперь генерируют стек-трейсы с асинхронными событиями. Фичу дорабатывают и планируют добавить в основную версию браузера после решения проблем с производительностью. В инспекторе веб-сокетов добавлена поддержка форматирования сообщений в формате ASP.NET Core SignalR.

Добавлена возможность стилизации элементов Shadow DOM из основного документа с помощью дополнительного атрибута part и псевдоэлемента ::part(). Имплементирована спецификация Motion Path, которая позволяет задавать траекторию анимации с помощью offset-path. С этой версии можно использовать индивидуальные трансформации scale, rotate и translate, без использования transform: ( .class { scale: 2 } ).

Notification.requestPermission() и другие api, запрашивающее разрешение пользователей, теперь могут быть вызваны только после явного пользовательского действия. Это было сделано, чтобы не перегружать пользователей большим количеством нотификаций при посещении сайтов. Добавлен оператор nullish coalescing и новое событие форм formdata, с помощью которого можно модифицировать данные перед их отправкой на сервер.

Самые значимые пользовательские фичи: блокировка fingerprint-скриптов и поддержка "картинки-в-картинки" для видео в Firefox на Mac и Linux.

С этой версии Firefox переходит на четырёхнедельный релизный цикл.

#release #firefox

https://hacks.mozilla.org/2020/01/firefox-72-our-first-song-of-2020/

Прочитал статью Роберта Аркрайта про опыт перевода высоконагруженного проекта на React — "Scaling React Server-Side Rendering".

Роберт пишет про балансировку запросов. Рандомная балансировка — это неудачный подход, который с большей вероятностью приводит к неравномерному распределению нагрузки. Описана хорошая стратегия распределения нагрузки по сервисам с помощью cluster и fabio. Ещё в статье рассказывается про интересный подход с фоллбеком на клиентский рендеринг в случае аномальной нагрузки на сервис.

Очень хорошая статья, несмотря на то что она была написана в 2017 году и уже немного потеряла актуальность (там описан подход с кешированием рендеринга компонентов, который не работает с React 16). Рекомендую почитать всем, кто рендерит React на сервере.

P.S. Спасибо @oleg_log за наводку на статью.

#react #ssr #performance

https://arkwright.github.io/scaling-react-server-side-rendering.html

Гарри Робертс поделился своими мыслями о бюджете на производительность — "Performance Budgets, Pragmatically".

Гарри пишет, что не стоит рассматривать бюджет как цель — большинство организаций не готовы брать на себя вызовы по экстренной оптимизации проекта. В статье предлагается более прагматичный подход, который рассматривает бюджет как подушку безопасности. Сначала нужно посмотреть на метрики за последние две недели и выбрать наихудший показатель, который будет верхним порогом в бюджете. Затем каждые две недели делать анализ: если нет проблем, то снижать порог далее, если проблема появилась, то нужно заняться её исправлением.

Имхо, это очень разумный подход. Если выбранный бюджет по каким-то причинам окажется недостижим, то всегда можно его пересмотреть.

#performance #metrics

https://csswizardry.com/2020/01/performance-budgets-pragmatically/

Скорее всего вы видели, что кто-то использует понятие "URL", а кто-то "URI". В чём разница между этими понятиями рассказал Дэниэл Мисслер в статье "What’s the Difference Between a URI and a URL?".

Путаница возникает из-за того, что RFC 3986 написан неакадемично. В одном месте RFC говорится, что URI может быть классифицирован как локатор, имя, или локатор+имя, и что URL является подмножеством URI, которое помимо идентификации предоставляет средства для определения его местонахождения. В другом месте говорится, что URI предоставляет только идентификацию, доступ к ресурсу не гарантируется и не подразумевается наличием URI... Дэниэл предлагает использовать понятие URI как идентификатор ресурсов, а URL как идентификатор ресурсов, который также говорит о том, как к ним получить доступ (http, https, ftp и т.п.). Если ресурс задаётся доменным именем без протокола (или с протоколом), его следует называть URL, хотя он также является и URI.

В конце статьи есть фраза "What a mess" — отличное описание сложившейся ситуации.

#web #rfc

https://danielmiessler.com/study/difference-between-uri-url/

Дэн Абрамов написал пост про проблемы фанатичного рефакторинга кода — "Goodbye, Clean Code".

Как-то у Дэна был серьёзный разговор с боссом из-за того, что он переписал чужой "грязный" код. Сейчас он размышляет над той ситуацией и пишет про то, что у добавленных абстракций должна быть хорошая цель — повторение кода, это недостаточно веская причина для его переписывания.

"Одержимость чистым кодом и удаление повторения кода — это фаза, через которую прошли многие. Когда мы не чувствуем себя уверенными в своём коде, соблазнительно соотносить чувство своего достоинства и профессиональную гордость с чем-то измеримым: набором строгих правил линтинга, схемами именования, файловой структурой, отсутствием дублирования кода."

Сейчас в твиттере и реддите немного бомбит из-за того, что Дэн призывает писать плохой код, но, имхо, статья не про это.

#musings #programming

https://overreacted.io/goodbye-clean-code/

Барри Поллард — автор книги “HTTP/2 in Action” и редактор web-альманаха — написал большую статью про плюсы и минусы использования шрифтов Google Fonts — "Should you self-host Google Fonts?"

При работе над web-альманахом Барри занимался оптимизацией сайта. Большая проблема была с Google Fonts (fonts.googleapis.com). При его использовании блокировался рендеринг страницы; в экспериментах с веб-альманахом задержка была 3 секунды. Для ускорения отображение контента, было решено перенести все шрифты на основной домен. Но не всё так просто. Google Fonts делает много всего полезного, для того чтобы уменьшить объём загружаемых шрифтов, например, отдаёт шрифты без хинтинга для браузеров на macOS, автоматически использует font subsetting и т.п. Поэтому при отказе от Google Fonts нужно понимать, какие потенциальные плюсы будут потеряны.

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

#fonts #performance #google

https://www.tunetheweb.com/blog/should-you-self-host-google-fonts/

Оказывается команда SpiderMonkey (JavaScript движок, используемый в Firefox) недавно завела блог, в котором публикует новости об изменениях в движке. В последней новостной рассылке есть много всего интересного:
- обновление Intl.DateTimeFormat.prototype.formatToParts до актуальной версии, соответствующей последним изменениям в спецификаци
- Project Visage — новый фронтенд (парсер и эмиттер байткода) для JavaScript, написанный на языке Rust
- улучшения парсера
- Project Stencil — новый формат данных, генерируемых парсером
- движок для регулярных выражений будет заменён на тот, что используется в V8
- упрощение байткода
- устаревшие toSource и uneval убраны из движка
- улучшения дебаггера
- улучшения производительности Array.prototype.reverse и BigInt
- в Nightly появился флаг, включающий поддержку JS BigInt <-> wasm I64 conversion
- продолжается работа над уже добавленными #WebAssembly пропозалами Reference types и bulk memory
- много улучшений Cranelift — кодогенератора, который в будущем будет использоваться для оптимизирующего компилятора WebAssembly
- ведётся работа на WebAssembly пропозалом multi-value
- ведётся работа над включением SharedArrayBuffer по умолчанию
- начата работа по добавлению WebAssembly пропозала exception handling

Дэвид Хеттелр в статье "Monitoring Node.js: Watch Your Event Loop Lag!" рассказывает, как мониторить лаги event loop и что можно с ними сделать.

Node.js работает в одном потоке, поэтому надо следить за тем, чтобы поток не забивался долгими задачами. Если возникла проблема, то можно воспользоваться профилировщиком для локализации проблемы. Но лучше всего подключить мониторинг event loop, который будет на постоянной основе отслеживать лаг и уведомлять в случае проблем. Для этого нужно использовать monitorEventLoopDelay из Performance Timing API. Для уменьшения лага можно поискать альтернативные решения (если проблема в библиотеке), использовать worker_threads или вынести ресурсоёмкий код в C++ модуль.

Рекомендую почитать статью, если работаете с Node.js и столкнулись с проблемой долгого ответа приложения.

#nodejs #performance

https://davidhettler.net/blog/event-loop-lag/

Эверт Пот провёл эксперимент по измерению скорости HTTP/1.1 и HTTP/2 в разных условиях — "Performance testing HTTP/1.1 vs HTTP/2 vs HTTP/2 + Server Push for REST APIs".

Основные выводы из статьи. Если очень критична скорость, то нужно продолжать компоновать множество запросов в один. Если вас интересует более элегантный дизайн API, то получение каждой сущности по уникальному URL вполне хорошее решение в условиях HTTP/2. Кэширование ответов в Firefox незначительно влияет на общий результат, в Chrome эксперимент с использованием кэша показал прирост скорости в 2.3 раза. Есть проблемы с HTTP/2 Push в Firefox — автор статьи пишет, что push в его экспериментах работал через раз.

В общем, эта статья — ещё один повод задуматься о переходе с HTTP/1.1 на HTTP/2, если вы этого ещё не сделали.

#http #benchmark #performance

https://evertpot.com/h2-parallelism/

Три дня назад команда Google Chrome объявила о том, что собирается заморозить текущий User Agent к сентябрю 2020 года.

User Agent (UA) — хороший источник информации о пользователях, что плохо для приватности. Его заморозка сделает невозможным пассивный сбор данных о пользователях третьими сторонами. Ещё UA-строки запутаны настолько, что нередко становятся источниками проблем совместимости сайтов, из-за чего браузеры вынуждены в некоторых случаях представляться другими браузерами.

UA будет унифицирован и заморожен, чтобы не сломать существующий код, который его использует. В качестве замены UA гуглеры предлагают новую фичу — User Agent Client Hints (UA-CH). Её использование будет гарантировать, что сервер получит только ту информацию, которая ему нужна (платформа, операционная система, браузер и т.п.). Это также уменьшит вероятность ошибок, которые ведут к проблемам с совместимостью. Работать UA-CH будет поверх HTTPS, что вынудит третьи стороны использовать активный сбор данных, который в свою очередь может быть проанализирован и заблокирован браузером. На данный момент не решён вопрос неизбежной задержки ответа при использовании UA-CH, что критично для сервисов, которые должны отвечать быстро, например, fonts.google.com.

Разработчики других браузеров также проявили интерес к заморозке UA: в Safari уже проводятся эксперименты, в Firefox хорошо относятся к инициативе с заморозкой, но пока наблюдают за обстановкой.

#web #security #google

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/-2JIRNMWJ7s/yHe4tQNLCgAJ