Джейсон Миллер и Мэйсон Фрид представили экспериментальную поддержку Declarative Shadow DOM в Chrome.

Declarative Shadow DOM позволяет описывать разметку web-компонентов декларативно в коде HTML-страницы без использования императивного API с помощью JavaScript. Это очень важная фича для развития экосистемы web-компонентов. Про неё уже был пост в канале, его можно найти тут.

Самое главное на что стоит обратить внимание при использовании Declarative Shadow DOM. Построение Shadow DOM производится на этапе парсинга страницы, за счёт этого компоненты на странице рендерятся быстрее по сравнению с традиционным императивным подходом. Элемент template c атрибутом shadowroot становится теневым корнем (shadow root) и автоматически прикрепляется к родительскому элементу. Для сериализации DOM дерева с Shadow DOM можно использовать новый метод getInnerHTML().

Экспериментальная поддержка Declarative Shadow DOM появилась в Chrome 85. Ожидается, что она будет включена по умолчанию в Chrome 88. Браузеры без поддержки Declarative Shadow DOM могут использовать полифилл.

#experimental #webcomponents

https://web.dev/declarative-shadow-dom/

Зейнеп Канкара в блоге V8 написала статью про Indicium — новый инструмент рантайм анализа V8 — "Indicium: V8 runtime tracer tool".

Чтобы понять, зачем нужен этот инструмент, нужно немного разобраться в кишках V8. Для представления JavaScript-объектов V8 использует специальную структуру — Map (не тот Map, который определён в ECMAScript). Благодаря этой структуре движок экономит оперативную память при работе с большим числом однотипных объектов. Map в свою очередь использует оптимизацию Inline Cache (IC) для быстрого доступа к свойствам объектов.

Внутри V8 уже есть всё необходимое для получения информации о Map и IC, и уже есть готовые инструменты для их анализа. Indicium представляет эту информацию в удобном виде, связывая между собой Map и IC. С помощью него можно проанализировать создание объектов и быстро выявить проблемные места в исходном коде.

Indicium — это ещё один полезный инструмент для анализа проблем производительности в Chromium и Node.js.

#performance #tool #v8

https://v8.dev/blog/system-analyzer

Вчера, когда писал пост про Indicium, в ссылках увидел очень интересную статью Матиаса Байненса и Бенедикта Мюрера про концепции, которые используются при создании всех современных JS-движков — "JavaScript engine fundamentals: Shapes and Inline Caches".

Современные движки (V8, SpiderMonkey, JavaScriptCore, Chakra) преобразуют абстрактное синтаксическое дерево программы в байткод, который исполняется интерпретатором. Во время исполнения программы собирается дополнительная информация, на основе которой оптимизирующий компилятор преобразует байткод в машинный код. В разных движках этот пайплайн компиляции/интерпретации уникален. В V8 есть один оптимизирующий компилятор (TurboFan), в SpiderMonkey два (Baseline, Ion Monkey), в JavaScriptCore три (Baseline, DFG, FTL).

При работе с объектами движки тоже похожи друг на друга. При создании объекта в памяти, они сохраняют структуру объекта в скрытый класс, который в разных движках называется по-разному (Map, Shape, Type, Structure). Благодаря использованию скрытых классов происходит экономия оперативной памяти и становится возможна оптимизация "Inline Cache" для быстрого доступа к свойствам объекта.

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

Интересная статья. Очень рекомендую почитать всем, кто интересуется внутренним устройством JS-движков.

#js #internals

https://mathiasbynens.be/notes/shapes-ics

Хочу сделать небольшое напоминание о том, что у проекта есть сайт. Вчера ночью не мог запостить статью в канал из-за того, что лежал телеграм. Тем не менее на сайте всё было размещено как положено. Поэтому если будут проблемы с телеграмом в следующий раз, можете проверить сайт, скорее всего пост там будет опубликован.

https://defront.ru/posts/2020/10-october/03-detached-window-memory-leaks/

Джейсон Миллер и Бартек Новиерски из Google рассказали о том, как находить и предотвращать утечки памяти, вызванные откреплёнными окнами, — "Detached window memory leaks".

Откреплённое окно (detached window) — это такое окно, которое было закрыто, но которое всё ещё доступно из JavaScript-кода. Под это определение также попадает iframe (он ведёт себя как вложенное в документ окно), когда в коде сохраняется ссылка на contentWindow или contentDocument. Обычно ссылки на откреплённые окна сохраняются по ошибке, а утечки памяти, связанные с ними, сложно локализовать.

В статье рассказывается о том, как с помощью DevTools находить проблемный код. Предлагается пять вариантов предотвращения появления утечек: обычное удаление ссылки на окно, удаление ссылки при возникновении события pagehide (или установки свойства window.closed ), с помощью использования WeakRef, с помощью использования postMessage для коммуникации окон между собой, с помощью открытия окна с использованием опции noopener.

Большая и хорошая статья. Рекомендую почитать.

#js

https://web.dev/detached-window-memory-leaks/

Патрик Броссет — разработчик Edge — написал статью про малоизвестные особенности CSS-переменных — "3 things about CSS variables you might not know".

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

2. В var(--foo, fallback) вторым аргументом передаётся значение, которое будет использовано по умолчанию, если переменная будет неопределена. Также в var() можно вкладывать другие var'ы как фоллбеки: color: var(--foo, var(--bar, var(--baz))).

3. Значение CSS-переменных это обычный текст. Это означает, что в них может содержаться строка с запятыми. То есть такое определение вполне валидно --my-variable: one, two, three;. Более того такую строку можно использовать в фоллбеке: content: var(--foo, one, two, three);, в этом случае в var содержится не четыре, а два аргумента.

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

#css

https://patrickbrosset.com/articles/2020-09-21-3-things-about-css-variables-you-might-not-know/

Мэт Перри — автор библиотеки Framer Motion — рассказал о том, в каких случаях браузеры могут троттлить requestAnimationFrame — "Browsers may throttle requestAnimationFrame".

Метод requestAnimationFrame (rAF) — самый главный инструмент для создания плавных анимаций, контролируемых js-кодом. Мэт столкнулся с тем, что в Safari на iOS на двух одинаковых смартфонах, одна и та же анимация в одном случае работала в 30fps, а в другом 60fps. Проблема оказалась в том, что Safari включает троттлинг rAF в режиме сохранения энергии. Также Safari троттлит rAF в iframe'ах с контентом сторонних доменов.

Троттлинг rAF есть и в Firefox, но в нём он ограничивается из-за вопросов безопасности. Для отключения троттлинга сайт должен отправлять HTTP-заголовки: Cross-Origin-Opener-Policy: same-origin и Cross-Origin-Embedder-Policy: require-corp.

#rendering #js

https://mattperry.is/writing-code/browsers-may-throttle-requestanimationframe-to-30fps

Сегодня узнал про утилиту для управления версиями инструментов JavaScript-тулчейна — Volta.

Если объяснять человеческим языком, то Volta похожа на nvm. С помощью неё можно устанавливать и переключаться между разными версиями Node.js. В отличие от nvm она написана на Rust и работает очень быстро. Инициализация nvm при открытии терминала может занимать несколько секунд (на моём стареньком маке около четырёх секунд). Volta исключает необходимость её инициализации при запуске терминала.

Но если бы дело было только в скорости, то было бы не очень интересно. Ещё Volta позволяет пинить версии node/npm/yarn в package.json и автоматически переключаться на нужную версию при переходе в директорию с таким конфигом. То есть можно запушить package.json с запиненными версиями node и npm в git, и всем членам команды, кто использует volta, не надо беспокоится о ручном переключении версии ноды. Ещё одна фишка — установка утилит из npm, которые не надо переустанавливать при переключении версии ноды.

Volta всё ещё находится в стадии активной разработки, поэтому есть кое-какие шероховатости. Например, есть проблемы с вызовом одной JS-утилиты из другой. Разработчики в issue пишут о том, что эта проблема уже в процессе решения. Над проектом работают разработчики из LinkedIn.

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

#js #nodejs #tool

https://volta.sh/

Сегодня вышел Chrome 86. Пит Лепаж и Джеселин Ин рассказали про новинки релиза.

File System Access API доступен по умолчанию. С помощью него можно получить доступ к файловой системе пользователя для упрощения работы с локальными файлами.

В рамках origin trials стал доступен Web HID, благодаря которому web-приложения могут взаимодействовать с оборудованием пользователя. Также в рамках origin trials стал доступен Multi-screen Window Placement API. Благодаря этому API возможно получить информацию о всех экранах пользователя и программно управлять размещением окон.

В CSS появилась поддержка псевдокласса :focus-visible, которое позволяет применять для фокуса эвристики, которые использует браузер. Добавлена поддержка псевдоэлемента ::marker для стилизации маркера списка.

Начался процесс удаления поддержки ftp (будет отключён в Chrome 88). Удалена поддержка API WebComponents v0 во WebView.

Много изменений в Chrome DevTools. Добавлена новая панель "Media" для упрощения дебага видеоплейеров. Теперь, как и в Firefox, можно сделать скриншот любого узла DOM-дерева с помощью контекстного меню на панели "Elements". Проблемы с third-party cookie на вкладке "Issues" скрываются по умолчанию. Теперь возможно эмулировать недоступность локально установленных шрифтов. Добавлена эмуляции неактивности пользователей (Idle Detection API) и эмуляция опции экономии траффика (медиа-запрос prefers-reduced-data ). Lighthouse обновлён до версии 6.2.

#chrome #release

https://developers.google.com/web/updates/2020/10/nic86
https://developers.google.com/web/updates/2020/08/devtools

В Chrome 86 HTTP-кэш становится изолированным. Что это означает рассказал Еиджи Китамура в статье "Gaining security and privacy by partitioning the cache".

Ранее, если происходила загрузка ресурса, и он оказывался закэшированным другим сайтом, браузер доставал этот ресурс из кэша. Такое поведение браузера влечёт за собой проблемы с приватностью. Например, можно засечь время получения ресурса с какого-либо сайта и по скорости определить, посещал ли пользователь этот сайт. Таким же методом можно проверить, искал ли пользователь определённую фразу в поисковике.

Chrome 86 начал использовать для имени ключа кэша "Network Isolation Key", который состоит из имени сайта и сайта текущего фрейма (если фрейма нет, то будет использоваться имя сайта второй раз). У изолированного кэша есть небольшой недостаток — он может повлиять на метрики производительности сайта.

На данный момент изоляция кэша включена в Chrome и Safari. В Firefox она тоже поддерживается, но выключена по умолчанию (её можно включить с помощью флага privacy.firstparty.isolate в about:config ).

#chrome #cache

https://developers.google.com/web/updates/2020/10/http-cache-partitioning

Збигнев Банах написал статью про HSTS — "Why Websites Need HTTP Strict Transport Security (HSTS)".

Как правило, пользователи при переходе на сайт вводят его имя в адресную строку без протокола. Браузеры по умолчанию переходят на сайт по незащищённому протоколу HTTP. Для того чтобы браузер всегда использовал HTTPS-протокол, сервер на первый запрос должен отправить ответ с редиректом на HTTPS-версию сайта и с помощью заголовка Strict-Transport-Security передать дополнительную информацию о том, что сайт должен работать только HTTPS и закэшировать этот ответ. Время жизни кэша обычно устанавливают на год или два. В следующий раз при посещении сайта пользователь сразу попадёт на HTTPS-версию без редиректа.

Но есть небольшая проблема. Теоретически злоумышленник может перехватить первый запрос и заблокировать работу HSTS. Чтобы этого избежать, браузеры проверяют список сайтов, которые должны работать только по HTTPS (HSTS preload list). В этот список можно добавить свой сайт, но для этого нужно выполнить все условия, например, чтобы все поддомены работали по HTTPS.

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

#http #security

https://www.netsparker.com/blog/web-security/http-strict-transport-security-hsts/

Серджио Виллар в блоге Igalia написал пост о том, как они исправляли в WebKit проблемы с flexbox — “Closing the gap (in flexbox)”.

В WebKit накопилось большое количество проблем, связанных с flexbox. Много тестов из Web Platform Test не проходило. Ребят из Igalia наняли решить самые важные проблемы с флексами: исправить работу с min-width:auto и min-height:auto, исправить поведение flexbox-элементов внутри таблиц и наоборот, исправить проблемы с обработкой высоты, заданной в процентах, для контейнеров с неограниченными размерами. Среди самых важных изменений было добавление поддержки свойства gap. В статье разбираются наиболее интересные примеры неправильного поведения flexbox’ов в WebKit.

В статью стоит заглянуть, если хотите узнать подробнее о нюансах работы с flexbox.

#css #internals

https://blogs.igalia.com/svillar/2020/10/01/closing-the-gap-in-flexbox/

Вчера зарелизился Webpack 5 с огромным количеством изменений.

TLDR

В новой версии была улучшена скорость сборки. Была улучшена поддержка долгосрочного кэширования бандлов. Улучшен tree shaking. Реализован новый подход для работы с ассетами. Добавлена новая фича Module Federation. Удалены полифиллы для Node.js-модулей. Код сборки может генерироваться в стандарте ES2015.

Подробнее

Улучшена скорость сборки благодаря кэшированию на диске служебных данных между разными сборками (Persistent Caching).

Было проделано много работы для улучшения tree-shaking. В новой версии Webpack использует статический анализ для построения графа зависимостей, благодаря чему удаляется больше неиспользуемого кода. Также Webpack благодаря статическому анализу определяет модули без сайд-эффектов и не включает их в бандл, если они не используются. Был улучшен tree-shaking CommonJS-модулей.

Было упрощено использование ассетов. Теперь не нужно устанавливать дополнительные загрузчики, например, file-loader, url-loader, raw-loader. Сергей Мелюков в феврале публиковал статью про ассеты в Webpack 5, рекомендую почитать.

С пятой версии стала доступна ещё одна новая фича — Module Federation. Благодаря ей приложение может прозрачно заимствовать код из других приложений. Это позволяет делать интересные вещи, например, разделить одно большое SPA на несколько небольших. Это SPA с точки зрения пользователя будет работать как одно целое, но может разрабатываться и деплоиться разными командами независимо друг от друга.

Улучшена совместимость с Web-платформой: добавлена поддержка Top Level Await, JSON Modules, WASM Modules, import.meta.

Четвёртая версия Webpack могла генерировать код сборки только в стандарте в ES5. С пятой версии код сборки может генерироваться в стандарте ES2015.

Были удалены полифиллы для Node.js ( node.Buffer, node.console, node.process, crypto и т.п.) Когда появился Webpack, npm чаще всего использовали для распространения Node.js-модулей, поэтому в то время имело смысл поставлять со сборщиком полифиллы. Сейчас ситуация изменилась — в npm есть много кода, который можно использовать и в Node.js, и в браузерах. Также очень много внимания сегодня уделяют размеру генерируемого кода, а полифиллы Node.js могут добавлять очень много кода. Но не все рады удалению полифиллов. Синдре Сорхусу — автору многих библиотек в экосистеме Node.js — это решение не понравилось. Он пишет про то, что не будет исправлять проблемы, связанные с Webpack 5.

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

#webpack #release #bundle

https://webpack.js.org/blog/2020-10-10-webpack-5-release/

Маниш Горегаокар — разработчик Servo — написал статью про сложности имплементации свойства font-size — "Font-size: An Unexpectedly Complex CSS Property".

Маниш разрабатывал Stylo — CSS-движок, написанный на Rust, который стал частью Firefox. Одной из его задач было добавление поддержки свойства font-size.

Проблема в том, что на размер шрифта влияют очень много факторов. Размер может быть задан разными юнитами и ключевыми словами. На него влияет выбранное семейство шрифтов, например, font-size: medium в рубленных шрифтах это 16 пикселей, а в моноширинных шрифтах — 13 пикселей. Также Firefox (из коробки) и Chrome (с помощью расширения) позволяют задавать размер шрифта в зависимости от текущего языка текста. Есть свои нюансы для задания размеров шрифта в MathML и при его использовании c аннотациями ruby.

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

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

#css #internals #firefox #specification

https://manishearth.github.io/blog/2017/08/10/font-size-an-unexpectedly-complex-css-property/

Традиционный пост о том, что было опубликовано за последние две недели в Defront Plus:

— Что произошло с immutable.js, и какие есть альтернативы
— Результаты UX-исследований открытия ссылок в новом табе или окне
— Ошибки в CSS, которые делаются на автопилоте
— Понимание байткода V8
— Опыт уменьшения размера бандла Next.js-приложения
— Использование async_hooks в Node.js
— Как Goibibo улучшил бизнес-метрики web-приложения c помощью PWA
— Tota11y — поиск проблем с a11y
— Вам, возможно, не нужен date-fns
— Не доверяйте дефолтным таймаутам

Канал существует благодаря вашей поддержке. Становитесь патроном канала на Patreon, чтобы получить доступ к дополнительным постам в Defront Plus.

Спасибо всем, кто читает и поддерживает Defront! Рад видеть, что канал приносит вам пользу.

https://www.patreon.com/myshov

Сегодня вышла седьмая версия npm. Майлз Боринс рассказал про новые фичи релиза — "Presenting v7.0.0 of the npm CLI ".

В npm v7 была добавлена поддержка воркспейсов (workspaces). С их помощью добавляется возможность удобного управления вложенными пакетами из корневого пакета.

В новой версии peerDependencies будут устанавливаться автоматически. В npm v6 установщику не предоставлялась информация о peerDependencies, поэтому их надо было устанавливать самостоятельно.

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

Ломающие изменения: автоматическая установка peerDependencies; теперь нельзя зареквайрить внутренние модули npm; npx был переписан, в новой версии он работает поверх npm exec, что повлекло за собой разные изменения; изменился вывод команды npm audit.

Седьмая версия будет поставляться с Node.js v15 (выходит на следующей неделе) или её можно установить самостоятельно ( npm i -g npm@7 ).

#npm #release #nodejs

https://github.blog/2020-10-13-presenting-v7-0-0-of-the-npm-cli/

Барри Поллард — автор книги "HTTP/2 in Action" и один из авторов "Web Almanac" — проанализировал данные Lighthouse из HTTP Archive и поделился своими находками — "What do Lighthouse Scores look like across the web?".

Всего лишь 10% сайтов были оценены больше 80 в категории производительности. Медианное значение оценки — 31. Это означает, что большинство сайтов неоптимизировано, и, скорее всего, работают медленно. Наиболее низкая оценка метрик приходится на Largest Contentful Paint (LCP) и Time to Interactive (TTI) — всего лишь 21% сайтов получили хорошую оценку по этим метрикам.

Лучше всего сайты показывают себя в категориях Accessibility и SEO. Хорошие оценки Accessibility объясняются набором типов проверок в Lighthouse. Нужно понимать, что в категории Accessibility оценка не говорит о том, что сайт доступен (можно написать недоступную страницу с оценкой 100), оценка говорит о том, что сайт следует основным советам для улучшения доступности.

Интересное исследование. Рекомендую почитать, чтобы получить больше понимания об оценках в Lighthouse.

#performance #a11y #research

https://www.tunetheweb.com/blog/what-do-lighthouse-scores-look-like-across-the-web/

Дэниэл Апплкуист — член W3C Technical Architecture Group — призывает сообщество присоединиться к разработке стандартов — "Why Get Involved in Web Standards?"

Дэниэл пишет о том, что он работает над улучшением прозрачности разработки web-стандартов и вовлечением в процесс большего числа разработчиков. Если вы думали над тем, чтобы присоединиться к разработке стандартов, но не знали с чего начать, то вам поможет Web Platform Contribution Guide. В нём рассказывается о процессе разработки стандартов и о том, как можно помочь. Также можно присоединиться к TPAC брейкаутам — докладам на тему разработки разных web-стандартов. Обычно брейкауты проводятся среди членов рабочих групп W3C, но в этом году в них может поучаствовать любой разработчик.

Если у вас есть какие-либо вопросы, то Дэниэл готов на них ответить. Все подробности можно найти в конце статьи.

#announcement #spec

https://dev.to/torgo/why-get-involved-in-web-standards-1p4h

Томас Штейнер в блоге web.dev написал статью про текстовые фрагменты — "Boldly link where no one has linked before: Text Fragments".

В url страницы после символа # можно подставить идентификатор элемента, к которому браузер должен подкрутить страницу. Эта фича появилась очень давно, но у неё есть недостаток — на странице должен существовать элемент с необходимым идентификатором.

С помощью текстового фрагмента (text fragment) можно задать любой текст, который нужно "подсветить" на странице. Текстовый фрагмент задаётся в url страницы с помощью конструкций #:~:text=textStart или #:~:text=textStart,textEnd. Также можно указать необходимый контекст с помощью префиксов и суффиксов #:~:text=somePrefix-,text,-someSuffix.

Текстовый фрагмент — экспериментальная фича, её поддержка есть только в браузерах на базе Chromium. На данный момент участники W3C скептически относятся к изменению формата url, но Google уже начал использовать текстовые фрагменты в production-коде поисковых сниппетов.

#spec #experimental #chromium

https://web.dev/text-fragments/

Ник Джансма из Akamai написал большую статью про метрику CLS — "Cumulative Layout Shift in Practice".

Метрика CLS (Cumulative Layout Shift) показывает, насколько контент страницы стабилен. Большой показатель CLS обычно говорит о том, что у страницы плохой пользовательский опыт. Например, когда сдвигается текст из-за загрузки изображения или рекламных виджетов.

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

— CLS на мобильных устройствах выше, потому что контент на мобильных сайтах располагается вертикально, поэтому при анализе проблем CLS рекомендуется разделять статистику для десктопов и мобильных;
— момент времени, когда останавливается сбор метрики CLS, для разных инструментов разный;
— в инструментах разработчика есть баги при измерении сдвига контента внутри iframe'ов, также есть несоответствия в инструментах для сбора синтетической статистики и статистики с устройств реальных пользователей;
— в некоторых случаях страницы с высоким CLS могут предоставлять хороший пользовательский опыт;
— CLS не учитывает элементы, которые ничего не рендерят.

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

#performance #metrics

https://nicj.net/cumulative-layout-shift-in-practice/

Стэфани Стимак из Microsoft поделилась своими мыслями про производительность сайтов с точки зрения деревенского жителя — "Location, Privilege and Performant Websites".

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

Основная мысль статьи — критически важные сайты должны тестировать свою производительность на слабых устройствах с ограниченным доступом в сеть. В некоторых случаях можно поддерживать отдельную версию сервиса, адаптированную для работы в загруженной мобильной сети. После разрушений урагана Ирма NPR запустил текстовую версию сайта без изображений, JS и CSS специально для того, чтобы люди могли быстро получать информацию о последних новостях.

#performance #musings

https://blog.stephaniestimac.com/posts/10-30-2019-performance/