Михай Парпарита из Quip написал пост о том, как нестрогое сравнение в JS привело к повышенному потреблению CPU — "The Case of the Missing Equals Sign".

Михай столкнулся с проблемой высокого потребления CPU в production-сборке macOS приложения Quip. Quip построен на базе web-технологий и работает вунтри WebView.

С помощью профилировщика XCode был найден проблемный код — метод toString() у функции. JavaScriptCore — JS-движок, использующийся WebView, — при вызове этого метода вырезает подстроку с текстом функции из исходного кода и возвращает её как результат. Это объяснило, почему проблема не воспроизводилась до конкатенации всех файл в большой бандл. Если функция определена в очень большом файле, то выполнение этого метода приводит к повышенному потреблению CPU. Метод toString в свою очередь вызывался неявно при нестрогом сравнении. Проблема была решена заменой нестрогого сравнения на строгое сравнение.

#js #debug

http://blog.persistent.info/2020/11/the-case-of-missing-equals-sign.html

Вчера в репозитории csswg-drafts появилось предложение об отказе от HTML и CSS в пользу JavaScript. Автор предложения серьёзно подошёл к делу и подробно объяснил мотивацию (то есть это не было троллингом). Таб Аткинс предложение прикрыл с формулировкой, что оно противоречит фундаментальным принципам платформы. По мотивам произошедших событий Хид Де Врайс — участвует в разработке стандартов — написал статью "Why it's good for users that HTML, CSS and JS are separate languages".

Хид пишет про то, что разделение логики, стилей и поведения с исторической точки зрения удачное решение. Благодаря такому разделению ответственности пользователи могут взаимодействовать с сайтами вне зависимости от типа устройств, на которых они работают. Благодаря гибкой стилизации пользователи с слабым зрением могут включить на странице контрастное отображение. Благодаря отделённому описанию поведения пользователи могут получить доступ к сайту с отключенным JavaScript.

Также в статье говорится о том, что иногда полезно абстрагировать какие-то концепции для упрощения разработки, и, возможно, закрытое предложение может в этом помочь. Но, с другой стороны, сохранение HTML, CSS и JavaScript как отдельных сущностей гораздо полезнее для обычных пользователей.

#web

https://hiddedevries.nl/en/blog/2020-11-25-why-its-good-for-users-that-html-css-and-js-are-separate-languages/

В блоге web.dev появилась статья про изменение семантики "same-site", и как это повлияет на передачу кук — "Schemeful Same-Site".

В будущем определение "same-site" будет включать в себя URL схему. То есть сайты https://example.com и http://example.com будут считаться разными, и передача кук между ними будет заблокирована для SameSite=Strict. Подробнее про SameSite можно почитать здесь.

Это изменение делается для улучшения приватности и безопасности. Какое-то время можно будет сохранить передачу кук между безопасным и небезопасным контекстом, но разработчики браузеров настоятельно рекомендуют полностью перевести сайт на HTTPS.

На данный момент отправка кук работает без изменений. Для тестирования поведения сайтов с учётом новой семантики в браузерах были добавлены экспериментальные флаги: schemeful-same-site (Chrome 86) и network.cookie.sameSite.schemeful (Firefox 79). Также в инструментах разработчика будут появляться предупреждения о проблемах с такими куками.

#security

https://web.dev/schemeful-samesite/

В блоге Polypane была опубликована статья про новое медиавыражение prefers-reduced-data — "Creating websites with prefers-reduced-data".

В мобильных браузерах на базе Chromium пользователи могут включить опцию для уменьшения потребления траффика. На клиенте проверить статус этой опции можно с помощью navigator.connection.saveData. Проблема в том, что она доступна только из JS. Новое медиавыражение prefers-reduced-data расширяет возможности адаптации страниц, делая доступным текущий статус опции на уровне стилей.

В статье есть примеры использования prefers-reduced-data. С его помощью можно сделать условную загрузку шрифтов, изменить или отключить фон страницы, загрузить изображения меньшего объёма, отключить автовоспроизведение видео и аудио, отключить автоматическую загрузку новых данных при прокрутке страницы.

На данный момент prefers-reduced-data доступен в Chromium-based браузерах под экспериментальным флагом.

#performance #css #js

https://polypane.app/blog/creating-websites-with-prefers-reduced-data/

Увидел что Розенвассер активно работает над вики ТС и наткнулся на вот такое (советы по оптимизации скорости компиляции и editing experience)
https://github.com/microsoft/TypeScript/wiki/Performance

Марк Ноттингэм написал статью о текущем состоянии Early Hints — "Beyond Server Push: experimenting with the 103 Early Hints Status Code".

Обычно известно, какие ресурсы будут нужны на странице. Было бы полезно каким-то образом сообщить о них браузеру заранее, чтобы он мог начать загружать код, стили, шрифты, пока бэкенд выполняет свою работу. Для решения этой задачи предназначен Early Hints — стандарт, разработанный в 2018 году инженерами Fastly (RFC8297). По своей сути Early Hints это HTTP-ответ с кодом 103 и списком ресурсов, который браузер может начать загружать перед ответом бэкенда. В HTTP/2 есть похожий механизм Server Push, но по сравнению с Early Hints он гораздо сложнее в настройке и использовании.

Пока браузеры не поддерживают эту спеку, так как она сложна в реализации. Для оценки пользы её внедрения в Google Chrome начался сбор метрик с сайтов, отправляющих экспериментальный код 103 Early Hints. Марк призывает всех желающих поучаствовать в этом эксперименте.

#http #performance

https://www.fastly.com/blog/beyond-server-push-experimenting-with-the-103-early-hints-status-code

Андрей Печкуров — один из контрибьюторов Node.js — написал статью про оптимизацию Node.js-клиента Hazelcast — "Our Journey to a High-Performance Node.js Library".

В статье рассказывается про историю оптимизации Node.js-клиента для хранилища данных, от профилировки до конкретных оптимизаций в коде. Для профилировки они использовали библиотеку 0x. Оказалось, что в коде было много лишних аллокаций объекта Buffer. Потом нашли проблему в коде преобразования буфера в строку, решением стало использование обычного buf.toString(). Реализовали механизм батчинга сообщений клиента и много других мелких улучшений. После всех изменений количество обрабатываемых сообщений увеличилось в три раза.

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

#nodejs #performance

https://hazelcast.com/blog/our-journey-to-a-high-performance-node-js-library/

Реми Шарп поделился своими мыслями о влиянии JavaScript на доступность сайтов — "Please disable JavaScript to view this site".

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

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

Основная мысль статьи: JavaScript настолько стал неотъемлем от веба, что мы перестали задумываться о его влиянии на доступность и воспринимаем его наличие как нечто само собой разумеющееся.

#js #musings #a11y

https://remysharp.com/2020/11/30/please-disable-javanoscript-to-view-this-site

Артём Захарченко рассказал про свой подход использования моков при тестировании кода — "When should I (not) use mocks in testing?".

В статье есть примеры хорошего и плохого использования моков. Разбирается вопрос использования моков на разных уровнях тестирования: в юнит-тестах, в интеграционных тестах, в E2E-тестах.

Самое главная идея статьи — не используйте моки, если без них можно обойтись. Иногда они могут быть полезны, например, при работе со временем, датами, внешними сервисами. Но в то же время не следует ими злоупотреблять, так как они могут замаскировать проблемы, которые могут возникнуть в проде.

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

#testing

https://dev.to/kettanaito/when-should-i-not-use-mocks-in-testing-544e

Разработчики Blackbird рассказали, почему они перестали использовать Google Fonts и стали хостить шрифты на своём сервере — "Self-Hosting Google Fonts".

При использовании Google Fonts браузер сначала должен разрезолвить основной домен, установить SSL-соединение, а затем разрезолвить домен, на котором находятся статические ресурсы. Так как с Google Fonts грузится CSS, этот процесс блокирует рендеринг страницы. В статье говорится, что в худшем случае LCP (Largest Contentful Paint) из-за этого увеличивался на 1.3 секунды. Чтобы предотвратить блокировку рендеринга, шрифты можно перенести на свой сервер. В статье для этого рекомендуют использовать сервис Google Webfonts Helper Tool.

Полезная статья рекомендую почитать всем, кто интересуется производительностью.

#performance

https://tryblackbird.com/blog/self-hosting-google-fonts

Патрик Лаук опубликовал статью про использование медиафич для определения устройств ввода — "Interaction Media Features and Their Potential (for Incorrect Assumptions)".

В разделе Interaction Media Features CSS-спеки Media Queries Level 4 определяются несколько медиафич, с помощью которых можно проверить поддержку hover, тача, стилуса и соответствующим образом адаптировать интерфейс.

Медифичи pointer и hover предоставляют информацию о возможностях ввода того устройства, которое браузер считает основным. Медиафичи any-pointer и any-hover представляют обобщённую информацию о всех подключенных устройств ввода. Последние две медиафичи наиболее полезны, так как к девайсу, на котором отображается сайт, может быть подключено несколько устройств ввода. Например, к iPad могут быть одновременно подключены Apple Pencil, bluetooth-клавиатура и мышь.

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

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

#css #mobile

https://css-tricks.com/interaction-media-features-and-their-potential-for-incorrect-assumptions/

История JavaScript в инфографике

Завтра JavaScript исполняется 25, и JetBrains опубликовали сайт с временной шкалой, на которой отражены основные вехи в развитии языка.

https://www.jetbrains.com/lp/javanoscript-25/

upd: есть ещё русскоязычная версия

В блоге Catchjs была опубликована статья про анализ производительности миллиона сайтов — "We rendered a million web pages to find out what makes the web slow".

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

Для меня самым интересным показался анализ JS-библиотек. Список библиотек, которые встречаются чаще всего: на первом месте стоит jQuery, на втором — Google Analytics, на третьем — Google Ads. Список библиотек, которые больше всего влияют на TTI: jQuery, Froogaloop, WooCommerce, Swiper, Visual Composer prettyPhoto. Список библиотек, которые больше всего влияют на время полной загрузки страницы: Baidu Statistics, Amazon Publisher Services, jQuery, VK Open API, Zopim.

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

#performance #research

https://catchjs.com/Blog/PerformanceInTheWild

В понятия "переменная" и "кастомное свойство" часто вкладывают один и тот же смысл, но на самом деле между ними есть разница. Шима Видас рассказал, чем они отличаются в статье "CSS custom properties are not variables".

В спецификации CSS эти два термина определяются так (моя интерпретация): "кастомное свойство" — это определение некоторого именованного значения, которое будет использоваться в будущем --primary-color: #fff, "переменная" — это механизм для получения по имени определённого ранее значения var(--primary-color). Такое отличие полезно, потому что благодаря ему мы можем говорить про "переменные с фоллбеком" var(--primary-color, #eee). У кастомных свойств, как и у любых других свойств, невозможно задать фоллбек. Также мы можем "определить кастомное свойство на элементе". Переменные в CSS не определяются, но используются в других свойствах.

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

#css

https://webplatform.news/issues/2020-12-04

Мэтт Хоббс рассказал о нюансах использования CSS-свойства font-display с учётом производительности и UX — "A font-display setting for slow connections".

Свойство font-display определяет стратегию рендеринга web-шрифта и его фоллбэка: auto, block, swap, fallback, optional. С точки зрения скорости отображения контента наиболее интересны последние три значения. При использовании swap браузер рендерит фоллбэк-шрифт сразу же и ждёт бесконечное количество времени, пока не загрузится шрифт, после загрузки происходит замена шрифта. Значение fallback похоже на swap, но браузер ждёт три секунды для замены шрифта. Самое агрессивное свойство optional, если в течение 100мс браузер не загрузит шрифт, то будет отображаться фоллбэк без подмены. Загруженный шрифт будет взят из кэша при переходе на новую страницу.

Мэтт пишет, что на сайте правительства Великобритании, над которым он работал, используется font-display: fallback, чтобы пользователи не сталкивались с внезапным сдвигом контента.

Очень интересная статья. Рекомендую почитать всем, кто использует web-шрифты.

#performance #ux #fonts

https://calendar.perfplanet.com/2020/a-font-display-setting-for-slow-connections/

Месяц назад проходила конференция для разработчиков виртуальных машин, на которой Вячеслав Егоров рассказал про историю развития языка программирования Dart — "10 Years of Dart".

Dart начал разрабатываться инженерами Google в 2011 году. Первая версия не была статически типизируемой в обычном смысле, в ней была поддержка опциональных типов, и все оптимизации выполнялись на уровне JIT-компилятора (то есть во время выполнения кода). В 2015 году с появлением Flutter текущая имплементация языка не могла обеспечить хорошую производительность на iOS, потому что Apple запрещает использовать JIT-компиляцию в обычных программах. Команда Dart попыталась реализовать AOT-компиляцию (то есть до этапа выполнения кода) на базе существующего JIT-компилятора, но столкнулась с проблемами. Для решения этих проблем Dart должен был стать полноценным статически типизируемым языком. Над второй мажорной версией разработчики работали три года — Dart 2.0 зарелизился в 2018 году.

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

#dart #history #internals #talk

https://www.youtube.com/watch?v=e-58C8aGBM4

Пролетели две недели с момента последней публикации про канал для патронов. За это время в Defront Plus было опубликовано много интересных постов:

— Почему в TypeScript следует использовать union-типы вместо enum
— Малоизвестные JavaScript-проекты в 2020 году
— Обход проблемы с DST при работе с нативными датами в JS
— Мифические "быстрые" web-страницы
— Опыт миграции на Next.js ста фронтенд-проектов
— Адаптация кода под разные окружения с помощью Babel-трансформаций
— Преимущества использования Electron.js
— Управление внешними зависимостями
— Производительность попапов с превью страниц Wikipedia
— Улучшение производительности фронтенда новой платформы BBC

Становитесь патроном канала на Patreon, чтобы получить доступ к дополнительным постам в Defront Plus. На данный момент Patreon мой единственный источник дохода; все донаты идут на покупку еды, оплату аренды квартиры и т.п.

Спасибо всем, кто читает и поддерживает Defront!

https://www.patreon.com/myshov

Майкл Бутнер и Кенджи Багу из команды разработки Google Chrome рассказали про новый пропозал, который поможет улучшить скорость загрузки сайтов за счёт префетчинга ресурсов с учётом приватности — "Continuing our journey to bring instant experiences to the whole web".

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

Предложение описывает подход, с помощью которого можно обеспечить предзагрузку ресурсов, не раскрывая информацию о пользователе. Предполагается, что этот механизм будет работать с помощью HTTP-туннелей с внешним прокси (CONNECT proxy). То есть между браузером и сайтом будет находится прокси, который не позволит утечь пользовательским данным.

Ребята из Google провели успешный эксперимент в Chrome для Android, который показал, что использование префетча с помощью CONNECT proxy ускорило первоначальное отображение сайтов на 40%.

Команда разработчиков призывает всех желающих поучаствовать в обсуждении и разработке полноценной спецификации использования CONNECT proxy с префетчем.

#performance #proposal #chromium

https://blog.chromium.org/2020/12/continuing-our-journey-to-bring-instant.html

Прямая трансляция Chrome Dev Summit стартует сегодня в 20:30 (GMT+3). Первый день с 13 докладами посвящён перфомансу, Core Web Vitals и приватности.

Трансляция https://youtu.be/NkIi7h8NnS4
Программа https://developer.chrome.com/devsummit/schedule/

HTTP Archive второй год подряд публикует отчёт о текущем состоянии веба — "Web Almanac 2020".

Альманах поделён на 22 главы, которые посвящены текущему состоянию дел в вебе: контенту (CSS, JavaScript, шрифты), пользовательскому опыту (доступность, производительность, SEO, приватность, безопасность, мобильный web), инструментам публикации (CMS, ecommerce, Jamstack) и распространению контента (сжатие, кеширование, Resource Hints, HTTP/2). Над проектом работали 116 специалистов, среди которых есть Рик Вискоми, Лия Веру, Тим Кадлек, Гарри Робертс и другие. Общий объём статей около 500 страниц.

В альманахе есть много информации и разных инсайтов, например, в самом большом HTML-атрибуте alt содержится 15 миллионов символов. На август 2020 года по HTTP/2 было передано 64% запросов. Средний объём страниц вместе со всем содержимым (CSS, JS, изображения) — 1.9Мб.

#report #web

https://almanac.httparchive.org/en/2020/

Прямая трансляция второго дня Chrome Dev Summit стартует сегодня в 20:30 (GMT+3). В программе 13 докладов про DevTools, CSS Houdini, WebAssembly, PWA, Workbox, SEO и будущее веба.

Трансляция https://youtu.be/ggVsEl7xl9g
Программа https://developer.chrome.com/devsummit/schedule/