Гарри Робертс поделился своими мыслями о бюджете на производительность — "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

Большие сайты начинают использовать адаптивную загрузку. Что это такое, рассказала Милика Михайлия в статье — "Adaptive loading: improving web performance on slow devices".

Адаптивная загрузка — набор практик для адаптации загружаемых ресурсов, учитывая характеристики устройства. Сайт может узнать тип соединения, объём памяти, количество ядер CPU и, если ресурсов недостаточно, отключить автовоспроизведение видео, заменить 3d-вьюер статическим изображением и т.п. Подобный подход используется Twitter, eBay, Tinder и Facebook. Facebook делит устройства клиентов на пять категорий, каждой категории соответствует свой набор фич. Данные для классификации берутся из navigator.hardwareConcurrency, navigator.deviceMemory и UA-строк. Эти же данные используются в мониторингах сайта, облегчая поиск регрессий производительности.

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

#mobile #performance

https://web.dev/adaptive-loading-cds-2019/

Ахмад Шадид написал пост про скрытие элементов в html-документе — "Hiding Elements On The Web".

В статье разбираются все способы от display: none до clip-path: polygon(0 0, 0 0, 0 0, 0 0);. У некоторых подходов есть особенности, которые могут влиять на доступность. Например, opacity: 0 не убирает элемент из дерева доступности, поэтому его нужно комбинировать с visibility: hidden.  Ещё в статье есть рекомендация скрывать эмоджи с помощью aria-hidden, так как cкринридеры проговаривают эмоджи, запутывая текст, в котором они находятся.

В общем, статья хорошая, рекомендую почитать.

#css #a11y #html

https://ishadeed.com/article/hiding-web/#header

Александр Сурма рассказал про свой опыт использования WHATWG Streams для реактивного программирования — "Streams for reactive programming ".

WHATWG Streams — низкоуровневый примитив web-плафтормы, который решает проблему эффективной работы с I/O. Он лежит в основе Fetch API. В статье разбирается эксперимент использования стримов для создания observable-like библиотеки observables-with-streams (ows) и полноценного приложения на его основе. Эксперимент удался, но вскрыл проблему: в отличие от обычных observable подписчики в ows всегда выполняются асинхронно.

Не думаю, что появление ows заставит кого-то отказаться от Rx.js, но сам по себе эксперимент получился интересный. Рекомендую почитать статью, если хотите узнать побольше про использование WHATWG Streams и особенности реализации observable.

#async #streams #expeimental

https://dassur.ma/things/streams-for-reactive-programming/

На risingstars.js.org была опубликована подборка самых популярных JavaScript проектов за 2019 год. Этот топ в отличие от State of JS формируется на основе прироста количества звёзд за год.

Самые популярные проекты: 1) Vue.js, 2) VS Code, 3) React, 4) Vue Element Admin, 5) Svelte. До этого момента никогда не слышал про Vue Element Admin — довольно мощное решение для создания админок.

Самые популярные фреймворки: 1) Vue.js, 2) React, 3) Svelte, 4) Angular, 5) Omi. Omi — фреймворк для создания компонентов на базе Web Components с помощью Virtual DOM, может использоваться вместе с React, Vue.js, Angular.

Советую посмотреть подборку, в ней можно найти много интересных проектов.

#list #js

https://risingstars.js.org/2019/en/

Марк Джордан написал статью про то, как создать виртуализированный список с нуля — "Building a virtualized list from scratch".

Виртуализированные списки используют для оптимизации рендеринга, когда надо показать очень большое количество элементов. В таких списках рендерятся только те элементы, которые видны пользователю. В React-экосистеме уже есть готовые компоненты для создания таких списков, но у Марка возникла проблема при интеграции с другим фреймворком, поэтому ему пришлось написать свою реализацию.

Суть библиотеки такая: берём внешний контейнер, для которого, выставляем overflow: scroll и внутренний контейнер с высотой numItems * itemHeight. При скролле внутреннего контейнера высчитываем диапазон индексов тех элементов, которые надо отобразить (например, scrollTop / itemHeight для первого индекса). Рендерим эти элементы.

Мне нравятся статьи "Делаем N с нуля", обычно в них разбирается основная идея, которую можно использовать при создании собственной реализации с учётом особенностей проекта или чтобы лучше понять устройство используемой библиотеки. В общем, если будете делать что-то подобное (не обязательно в React), советую почитать статью.

#react #performance #diy

https://medium.com/ingeniouslysimple/building-a-virtualized-list-from-scratch-9225e8bec120

Увидел сегодня в канале веб-стандартов ссылку на статью Эди Османи о разработке сайтов для фичефонов — "Loading web pages fast on a $20 feature phone".

Фичефон (Feature Phone) — это общее название дешёвых телефонов. Они отличаются от смартфонов традиционным форм-фактором (цифровая клавиатура + D-pad), отсутствием тачскрина, одноядерным CPU 1GHz, 256-512Mb RAM, маленьким дисплеем (чаще всего QVGA — 320x240). Фичефоны очень популярны в развивающихся странах, где могут быть дорогие интернет-тарифы.

Большие международные проекты и проекты, нацеленные на развивающиеся рынки, должны учитывать эти особенности и максимально адаптировать сайт под ограниченные ресурсы устройства. В статье Эди предлагает использовать бюджет в 30kb на весь загружаемый JavaScript, так как парсинг и исполнение кода на слабых девайсах может легко занять более двух секунд. Ещё есть совет проверять HTTP-заголовок Save-Data, для определения включения "лёгкого" режима в Chrome под Android.

Все идеи из статьи можно использовать не только для адаптации под слабые устройства, но и для создания очень быстрых сайтов для обычных смартфонов.

#mobile #performance

https://dev.to/addyosmani/loading-web-pages-fast-on-a-20-feature-phone-8h6
https://habr.com/p/482470/ (перевод на русский язык)

Есть компания Ekioh, которая разрабатывает системный софт для встраиваемых устройств на базе веб-технологий. В 2006 году они сделали высокопроизводительный SVG-рендерер для разработки UI на приставках кабельного и спутникового телевидения, уместив его в 6Mb. Потом форкнули WebKit, сократив потребление памяти до 25Mb. В 2018 году Ekioh зарелизили Flow — проприетарный браузер для встраиваемых систем с очень производительным многопоточным рендерингом.

Недавно вышло интервью с Пирсом Вомбеллом — фаундером Ekioh, в котором он рассказал про новый браузер. Основная задача Flow — создание интерфесов для тв-приставок с использованием современных web-технологий. Приставки очень ограничены в ресурсах — с появлением 4k-телевизоров эта проблема встала особенно остро, поэтому они решили сделать кастомный html-движок, который впоследствии превратился в браузер. На данный момент он уже поддерживает gmail, с другими сложными сайтами ещё есть проблемы. Flow не предназначен для сёрфинга в привычном смысле, но он может использоваться разработчиками приставок для доступа к web-ресурсам. UA string браузера:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_0) EkiohFlow/5.7.4.30559 Flow/5.7.4 (like Gecko Firefox/53.0 rv:53.0)

На данный момент Flow доступен только для производителей приставок, но возможен релиз для всех после решения проблем с юзабилити. Поддерживаемые системы — macOS, Linux и Android.

#embedded #tv #browser

https://www.quirksmode.org/blog/archives/2020/01/new_browser_on.html

Валерий Карпов написал пост про альтернативное использование JSX-синтаксиса — "An Overview of JSX With 3 Non-React Examples".

Babel по умолчание транспилирует JSX в вызовы метода React.createElement, но его можно настроить так, чтобы на выходе был вызов любой другой функции. Это можно сделать в .babelrc (будет применяться для всего транспилируемого кода) или с помощью прагмы /** @jsx otherFunction */ (будет применяться только для того файла, где эта прагма находится. В статье рассказывается, как можно описать бинарное дерево, определение роутов для Express и схемы для Mongoose, используя JSX и прагму.

Идеи интересные. Но лично мне не очень нравится подход с транспиляцией JSX-кода для Node.js.

#jsx #experimental

http://thecodebarbarian.com/overview-of-jsx-with-non-react-examples.html

Вчера вышел релиз Yarn 2. Маэл Нильсон рассказал про все возможности новой версии — "Introducing Yarn 2!".

Первая версия переходит в режим поддержки и переезжает в yarnpkg/legacy, новая версия будет жить в репозитории yarnpkg/berry. Для облегчения процесса миграции разработчики подготовили Migration Guide.

Была реализована идея Zero-Installs, которая включает в себя много функций, для того чтобы все зависимости были доступны вне зависимости от внешних факторов. По сути теперь возможно без проблем закоммитить кэш yarn в git (гораздо эффективнее чем версионирование node_modules) и все зависимости будут доступны сразу после клонирования репозитория.

Очень много изменений в воркспейсах. Упрощена установка зависимостей. Добавлена команда yarn workspaces foreach, которая выполняет команду для всех воркспейсов. Для упрощения релизов пакетов монорепы добавлен новый релизный воркфлоу с помощью команды yarn version (пока в экспериментальном режиме). Появилась очень интересная фича — workspace constraints — правила на языке Пролог, которые позволяют синхронизировать зависимости воркспейсов.

Yarn 2 поставляется вместе с простым интерпретатором командной строки (подобно sh), благодаря этому установочные скрипты будут работать независимо от операционной системы. Lockfile теперь использует yaml. Импорт зависимостей, не указанных в package.json, теперь запрещён. Улучшили вывод в консоль. Добавили команду yarn dlx для загрузки и выполнения пакетов. Добавили поддержку протоколов patch: и portal:.

Из внутренних изменений — Yarn перешёл на модульную архитектуру, кодовая база была переписана с Flow на TypeScript.

#yarn #release #tool

https://dev.to/arcanis/introducing-yarn-2-4eh1

Internet Explorer работал на движке Trident. После перехода Edge на Chromium Trident можно считать историей. Кристиан Шэфер написал большую статью про самые интересные возможности, которые были доступны в этом движке — "Today, the Trident Era Ends".

Из самого интересного. Был реализован стандарт VML для работы с векторной графикой, который позже был смёржен c PGML в другой стандарт — SVG. Была возможность вставлять JavaScript-код прямо в css, например, с помощью этой фичи можно было эмулировать псевдоэлементы before и after, до того момента как они появились в IE8. Были доступны фильтры и бесшовные переходы между страницами.

В конце статьи Кристиан размышляет о том, почему многие фичи не были стандартизированы. Меня немного удивило, что он не упомянул отсутствие в Microsoft общего видения развития web-платформы. Microsoft тогда была совсем другой компанией, которая преследовала другие цели. На hackernews есть комментарий по этому поводу:

For others who weren't aware, "embrace, extend, extinguish" was an explicit strategy discussed internally at Microsoft for gaining control of the internet. Though I think there are real innovations discussed in the article, the portrayal of Microsoft being an altruistic actor trying to get others to adopt their tech is downright dishonest with what we know about their internal discussions of their motivations and strategy at the time.

В общем, что было, то было, но объективности в статье немного не хватает.

#ie #history

https://news.ycombinator.com/item?id=22147405
https://schepp.dev/posts/today-the-trident-era-ends/

Прочитал статью Андрея Мелихова про погоню за производительностью в JavaScript-приложениях — "Микрооптимизации производительности и JavaScript".

Андрей в статье на хороших примерах показывает, почему разработчики js-движков призывают писать идиоматичный код. Причина в том, что работающие сегодня оптимизации завтра могут стать деоптимизациями из-за обновления движка или api платформы. Если преимущество в несколько миллисекунд, действительно, важно для проекта, то только тогда стоит задуматься об оптимизациях или о переписывании узкого горла на более низкоуровневом языке.

Добавлю ещё своих мыслей. В те годы, когда в Node.js были популярны микрооптимизации, появился шуточный термин "CrankShaftScript" (CrankShaft движок v8, который использовался в Node.js до версии 8.3). Этим термином называли js-код, который был написан так, чтобы JIT генерировал быстрый машинный код. Когда v8 перешёл на Turbofan, эти оптимизации стали бесполезны, так как новый JIT-компилятор научился генерировать эффективный машинный код из идиоматичного js-кода.

Хочу закончить пост фразой из статьи: "Иначе говоря, не нужно оптимизировать там, где ещё нет проблемы."

#js #performance #musings

https://medium.com/devschacht/optimizations-and-javascript-f8e060d3eae3
https://stackoverflow.com/questions/44764777/what-is-crankshaftscript-in-node-js

Продолжаем тему преждевременных оптимизаций. Пару дней назад Никита Прокопов поделился своими мыслями по поводу известного высказывания "Premature optimization is the root of all evil".

Основная идея статьи в том, что много разработчиков воспринимают эти слова буквально, оставляя вопросы производительности на самый последний момент. Может показаться, что это контрастирует с прошлым постом в канале, но нет. В посте Андрея речь идёт про микрооптимизации, в посте Никиты — про архитектуру приложения. Если архитектура приложения с самого начала была неудачна, то скорее всего не получится без серьёзной доработки или переписывания кода ускорить готовое приложение.

Снова хочу закончить пост цитатой из статьи.

Then, if you are really serious about your final program’s performance, every decision must be made with performance in mind. [...] These sort of decisions are easy to make early on, but impossible to change later.

#programming #performance #musings

https://tonsky.me/blog/performance-first/