Джейсон Григсби — автор книги Progressive Web Apps (A List Apart) — попробовал заказать еду на сайте, но с первой попытки у него это не получилось. Он разобрался в причинах и написал про результаты своего небольшого исследования статью "An HTML attribute potentially worth $4.4M to Chipotle".

На сайте было сломано автодополнение данных кредитных карт. Данные карты были сохранены в браузер правильно, но при их вводе в форму с помощью автодополнения что-то шло не так. Причина оказалась в Angular-модуле ui-mask, он неправильно отсекал год истечения срока действия карты. Автор попробовал использовать вместо кастомной маски стандартные HTML5 средства валидации формы pattern="\d\d" и maxlength="2". Проблема с автодополнением года была решена.

Проводились исследования, которые показывают, что автодополнение ускоряет заполнение форм на 30%. Скорость заполнения форм в свою очередь влияет на конверсию в заказ. Джейсон провёл грубые расчёты, которые показали, что сайт Chipotle теряет более 4 миллионов долларов в год из-за проблем с автодополнением.

Рекомендации из статьи: если у вас e-commerce сайт, убедитесь, что автодополнение данных кредитных карт работает, добавьте кейс проверки автодополнения в тест-план, используйте корректные поля ввода в формах.

#ux #forms

https://cloudfour.com/thinks/an-html-attribute-potentially-worth-4-4m-to-chipotle/

🎂 Сегодня исполняется 25 лет Консорциуму Всемирной Паутины (W3C)!

https://www.w3.org/blog/2019/10/happy-25th-anniversary-world-wide-web-consortium/

Несколько дней назад Cloudflare анонсировал экспериментальную поддержку HTTP/3 на своих серверах — "HTTP/3: the past, the present, and the future".

Чтобы ответить на вопрос, какую проблему решает новая версия протокола, надо для начала разобраться с HTTP/2. Основная польза от HTTP/2 — мультиплексирование запросов в рамках одного TCP-соединения. То есть если запрашивать классическую web-страницу по HTTP/2, то js/css-файлы, изображения и другие ресурсы будут передаваться параллельно друг другу, не создавая соединение на каждый запрос.

Загвоздка заключается в том, что HTTP/2 работает поверх TCP. Для TCP нет разницы, передаются ли по нему данные с помощью HTTP/1.1 или HTTP/2. Если во время параллельной передачи данных с помощью HTTP/2, какие-то байты, например из изображения, будут потеряны, возникнет пустой промежуток в потоке, который должен быть восстановлен. TCP работает так, что все успешно доставленные байты после обнаружения потери (даже если они не относились к изображению) не могут быть доставлены в приложение. То есть они будут ждать, пока данные будут восстановлены. Эта проблема известна под названием “head-of-line blocking”. HTTP/3 решает эту проблему, используя новый транспортный протокол QUIC. Также QUIC уменьшает количество запросов, необходимых для установки соединения.

На данный момент поддержка HTTP/3 есть в Google Chrome Canary за флагом и в экспериментальной версии curl. Разработчики Firefox обещают поддержку в ближайшем будущем. Есть реализация HTTP/3 клиента и сервера от cloudflare — quiche.

Теперь остаётся только ждать, когда стабилизируется стандарт, чтобы началось его массовое внедрение. Для меня самая крутая фича из нового протокола, которую планируют добавить в будущем, "connection migration" — бесшовная и прозрачная миграция между сетями. Благодаря ему можно будет забыть про паузы во время трансляции видео при переключении с Wi-Fi на LTE, а носимые девайсы станут по-настоящему always connected.

#http #performance #announcement

https://blog.cloudflare.com/http3-the-past-present-and-future/

Пару дней назад Рик Вискоми в блоге web.dev написал пост про то, как измерять и исправлять нестабильность раскладки элементов на странице — "Fixing layout instability".

С версии Chrome 77 появилась возможность измерять смещение отображаемого контента во время его загрузки с помощью нового Layout Instability API. Это не критичная, но важная для UX метрика, с помощью которой можно измерить "приятность" загрузки данных.

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

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

#ux #performance

https://web.dev/fixing-layout-instability

Прочитал статью про атаку, про которую как-то не приходилось слышать раньше — "Slow Loris attack using JavaScript on a PHP Server".

Атака названа в честь медленных (толстых) лори — зверьков, которые ведут неторопливый ночной образ жизни. Особенность атаки заключается в том, что инициатор может открыть очень большое количество tcp-соединений, отправляя запросы на сервер с промежутком в несколько секунд. Огромное количество соединений из-за программных ограничений приводит к крешу сервера.

Современные web-серверы из коробки идут с защитой от этой атаки, но она актуальна для кастомных серверов. Один из вариатов защиты от атаки, описанный в статье, использование reverse-proxy на nginx, с ограничением числа одновременных соединений от одного ip-адреса.

#security #http #tcp

https://www.freecodecamp.org/news/slow-loris-attack-using-javanoscript-on-php-server/

Недавно в блоге Gitlab появилась небольшая статья о том, почему было принято решение о переходе на ECharts для построения графиков — "Why we chose ECharts for data visualizations".

В Gitlab есть раздел с мониторингами приложения. Ранее для построения графиков в этом разделе использовался D3. От него решили отказаться, так как D3 был сложен в изучении и в конечном счёте не использовался на полную. От него лишь требовалась возможность отображения данных в виде графиков, поэтому ребята решили перейти на более специализированное решение. Выбирали между многими библиотеками, включая ECharts, Britecharts и Plotly. В итоге остановились на ECharts, потому что библиотека оказалась гибкой и достаточно производительной.

ECharts стартовал как open source проект Baidu, поэтому документация в основном написана на китайском языке. Не смотря на эту особенность экосистема вокруг проекта развивается, и проект используют не только в Китае, но и в других странах.

#experience #charts

https://about.gitlab.com/2019/09/30/why-we-chose-echarts/

Алексис Бинжесснер — инженер из команды Firefox — опубликовала пост про особенности рендеринга теста — "Text Rendering Hates You".

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

Статья довольно интересная с кучей технических деталей. Её стоит почитать, чтобы по-настоящему оценить, какую большую работу надо проделать для хорошего рендеринга текста.

#internals #rendering

https://gankra.github.io/blah/text-hates-you/#emoji-broke-color-and-style

Начиная с версии 7.9 в V8 изменяется работа с регулярными выражениями. Патрик Тиер и Ана Пешко написали пост с объяснением всех деталей — "Improving V8 regular expressions".

По умолчанию V8 компилирует регулярные выражения в нативный код при их первом запуске. Это влечёт за собой нагрузку на память. Около полугода назад как часть работы над "JIT-less V8" был добавлен интерпретатор для регулярных выражений. С версии 7.9 по умолчанию регулярные выражения будут исполняться с его помощью. Компиляция будет происходить только после того как одно и то же регулярное выражение будет выполняться несколько раз (hot-path). Новая стратегия позволяет уменьшить потребление оперативной памяти на 4-7%. Интерпретатор регулярных выражений был оптимизирован, теперь он в 2 раза быстрее. Это позволило не сильно просадить метрики по скорости относительно скомпилированных регулярок.

В статье много технических деталей того, как это всё работает. Читать сложно, но интересно.

#v8 #regexp #performance

https://v8.dev/blog/regexp-tier-up

В блоге Акселя Раушмайера недавно была опубликована новая статья — "Evaluating JavaScript code via import()".

Код, который использует модульную систему JS, не может быть выполнен с помощью eval(). Для того чтобы обойти это ограничение, можно использовать динамический импорт import() с закодированным кодом модуля в виде data URI.

Выглядит это так:

const js = `console.log('Hello everyone!');`;
const encodedJs = encodeURIComponent(js);
const dataUri = 'data:text/javanoscript;charset=utf-8,'
  + encodedJs;
import(dataUri);

При желании можно получить доступ ко всем экспортируемым объектам. Также можно вставлять data URI прямо в статический импорт, и он будет работать.

Маловероятно, что вы будете использовать этот трюк. Тем не менее статья интересная, почитать стоит.

#esm #trick

https://2ality.com/2019/10/eval-via-import.html

CSS является блокирующим ресурсом. Это означает, что браузер должен скачать и распарсить CSS прежде чем показать страницу. Если размер CSS большой, то он может очень сильно влиять на воспринимаемую скорость загрузки сайта. В блоге webdev есть статья с объяснением того, как решить эту проблему — "Extract critical CSS".

Критический CSS — это тот CSS, который необходим для отображения части страницы, которая видна до прокрутки страницы (above-the-fold content). Для того чтобы страница отобразилась как можно раньше, критический CSS инлайнят в тег <head>. Есть несколько библиотек, которые можно для этого использовать — Critical, CriticalCSS и Penthouse. В конце статьи есть ссылка на туториал "Extract and inline critical CSS with Critical", где подробно разбирается работа с Critical.

Если у вас есть сайт, при загрузке которого некоторое время отображается простой белый экран, советую заглянуть в статью. Вполне возможно, что проблема кроется в большом объёме CSS.

#performance #css

https://web.dev/extract-critical-css

Нравится нам это или нет, но порноиндустрия одна из причин, которая послужила развитию веба. Девид Волш расспросил разработчика из PornHub про особенности работы над самым большим сайтом для взрослых — "Interview with a Pornhub Web Developer".

Основной набор технологий на бэкенде — Nginx, PHP, MySQL, Memcached, Redis. Для более специфичных задач используются Varnish, ElasticSearch, NodeJS, Go, Vertica. На фронте используют Vanilla JS, потихоньку избавляясь от jQuery, начинают экспериментировать со Vue. Для измерения производительности клиентского кода используют внешнюю RUM-систему, локально развёрнутые инстансы WebpageTest и кастомную систему, встроенную в видеоплейер. Над видеоплейером работает выделенная команда разработчиков.

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

#performance #interview

https://davidwalsh.name/pornhub-interview

Полина Гуртовая и Рита Клубочкина опубликовали в блоге Злых Марсиан большую статью про использование изображений в вебе — "Images done right: Web graphics, good to the last byte".

В начале статьи рассказывается про то, как CSS-пиксели матчатся на экраны устройств, и почему физический размер пикселей отличается у мониторов и смартфонов. Есть разделы, посвящённые SVG и самым популярным форматам растровых изображений. Для меня самое полезное — сравнение результатов работы разных инструментов для разных форматов. Например, для сжатия PNG лучше всего подходит ImageOptim, а JPEG лучше всего жмут Squoosh и Imagemin. Есть бенчмарки с WebP, которые показывают его эффективность по сравнению с PNG и JPEG. Для анимациий не рекомендуют использовать GIF, вместо него рекомендуется использовать mp4 или webm. В самом начале статьи есть cheat-sheet, который может помочь с выбором наиболее подходящего формата.

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

#graphic #optimization

https://evilmartians.com/chronicles/images-done-right-web-graphics-good-to-the-last-byte-optimization-techniques

Филлип Уолтон недавно опубликовал статью про проблему каскадной инвалидации кэша — «Cascading Cache Invalidation».

Нежелательная инвалидация может возникнуть тогда, когда сборщик генерирует имена файлов с хэшами, которые напрямую импортируются в других файлах. Предположим, что во время сборки из всех файлов, находящихся в node_modules, создаётся файл vendor.<hash>.js. Если этот файл импортируется в других модулях, то из-за постоянно меняющегося хэша, будут изменяться хэши у всех зависимых модулей. Соответственно, браузер будет заново загружать тот код, который фактически не менялся.

Для решения этой проблемы Филлип предлагает использовать import maps (на данный момент поддержка есть только в Chrome за флагом), сервис воркеры или AMD-загрузчик (в статье разбирается пример SystemJS с Rollup.js).

Webpack не подвержен этой проблеме, но с ним есть другие особенности, которые могут приводить к неочевидным ошибкам.

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

#performance #bundle

https://philipwalton.com/articles/cascading-cache-invalidation/

Николас Гаутей опубликовал статью про использование WebPageTest с SPA-приложениями — "Recipes for Performance Testing Single Page Applications in WebPageTest".

При прогоне тестов на производительность у SPA-приложений недостаточно замерять обычную загрузку страницы, так как страница динамически меняет своё состояние в зависимости от пользовательского ввода. Ситуация усугубляется ещё тем, что при использовании React и Redux, нельзя просто менять элементы ввода с помощью innerText на уровне DOM API, так как при таком изменении текста не будет меняться состояние стора.

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

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

#performance #testing

https://css-tricks.com/recipes-for-performance-testing-single-page-applications-in-webpagetest/

Нашёл в твиттере ссылку на интересную статью Франсуа Шолле — "Notes to Myself on Software Engineering".

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

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

В статье очень много хороших мыслей, рекомендую почитать.

#list #softwaredesign #career

https://medium.com/s/story/notes-to-myself-on-software-engineering-c890f16f4e4d

Марк Ноттингэм — участвует в разработке протоколов HTTP и QUIC — написал пост про возможности, которые предоставляет HTTP/2 при проектировании классических HTTP API — "How Multiplexing Changes Your HTTP APIs".

HTTP API подвержен проблеме избыточной детализации. Например, при запросе большого количества однотипных сущностей каждый запрос будет отправляться независимо ( /widgets/id1, /widgets/id2 ). Такой подход неоптимален. Для решения этой проблемы создают дополнительные эндпойнты, которые могу обрабатывать запросы "батчами" ( /widgets/id1,id2,id3 ). Ещё можно использовать GraphQL, описывая список необходимых сущностей с помощью специального синтаксиса.

Марк пишет о том, что появление мультиплексирования в HTTP/2 (отправка множества параллельных запросов в рамках одного соединения), позволяет избавиться от необходимости создания специальных API для обработки батч-запросов. В статье, есть пример синтетического теста с 40 запросами. Для HTTP/1 накладные расходы на передачу данных составляют около 6Kb, для HTTP/2 — всего в 1440 байт. То есть благодаря HTTP/2 можно проектировать API любой степени детализации, не беспокоясь о проблемах неоптимальной передачи данных.

Мысли в статье интересные. Но мне не хватило сравнения описываемого подхода с GraphQL (плюсы, минусы, бенчмарки).

#http #performance #musings

https://www.mnot.net/blog/2019/10/13/h2_api_multiplexing

Прочитал статью Артура Басака — "Должен ли фронтенд разработчик уметь писать бэкенды?"

Артур пишет про то, что граница между фронтендом и бэкендом очень размыта. На западе под фронтендом понимается работа с CSS/HTML. У нас чаще всего по-другому — под фронтом понимается JavaScript, а владение CSS/HTML подразумевается как само собой разумеющееся.

С другой стороны фронтенд и бэкенд сильно переплетены друг с другом — для разработки сложных вещей требуется понимание и того, и другого. Например, в микросервисных архитектурах может использоваться Backend For Frontend (BFF) — сервис, который собирает и подготавливает данные для рендеринга или передачи на клиент. В компаниях BFF обычно разрабатывают фронтенд-разработчики.

В конце статьи есть хорошая мысль: любая технология — это всего лишь инструмент. Чем большим количеством инструментов владеет разработчик, тем больше он ценится на рынке.

#musings #backend #frontend

https://medium.com/front-end-in-regions-grodno/front-back-e1198c42d673

На этой неделе в сообществе web-разработчиков развернулся спор "HTTP/2 vs GraphQL". Марк-Андрэ Жиру встал на защиту GraphQL со статьёй "Is GraphQL Still Relevant in an HTTP2 World?"

В статье говорится о том, что HTTP/2 может помочь в снижении количества запросов к серверу и в более быстрой доставке ресурсов клиенту. Но тем не менее он не решает проблему поддержки большого количества эндпойнтов, с которым хорошо справляется GraphQL. Марк ещё пишет о том, что GraphQL очень удобен при разработке приложений, построенных на базе компонентов. GraphQL предоставляет много разных возможностей из коробки (интроспекция, типизированная схема и т.п.). Поддержка GraphQL существует во многих языках. В статье ещё есть раздел про сетевые ограничения, которые сказываются на дизайне API, построенных на базе HTTP/2, но мне он показался неубедительным.

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

#http #graphql

https://medium.com/@__xuorig__/is-graphql-still-relevant-in-an-http2-world-64964f207b8

Грег Уитворт — участник рабочей группы CSS и разработчик MS Edge — рассказал про результаты исследования среди разработчиков для выявления проблем при работе с <select> — "Can we please style the <select> control?!"

Исследование проводилось среди 1400 разработчиков при этом оценивался масштаб пользователей, который будет затронут потенциальными нововведениями. Самыми желаемыми функциями оказались встроенный поиск элементов и полноценная возможность стилизации у элемента <select>. Грег пишет, что пока не известно, каким образом будут реализованы все пожелания. Для этого в рамках WICG OpenUI будет создан прототип элемента управления, он послужит основой для создания нового предложения в стандарт.

Очень круто, что ребята из Microsoft взяли на себе ответственность по улучшению <select>. Скорее всего первые прототипы элемента будут реализованы в Edge.

#future #html

http://gwhitworth.com/blog/2019/10/can-we-please-style-select/

Сегодня столкнулся с новым атрибутом cookie SameSite. На web.dev есть хорошая статья про то, зачем о нужен и какую проблему решает — "SameSite cookies explained".

Cookie пользователей отправляются на сервер при любых запросах, даже если запрашивается статический ресурс с чужого сервера. Например если страница сайта site.com содержит изображение сайта site.net, при запросе изображения в запросе будут отправлены все куки пользователя для site.net. Чтобы ограничить отправку кук только тому сайту, которому они принадлежат (first-party) можно воспользоваться новым атрибутом SameSite.

Этот атрибут может содержать несколько параметров:
— Strict — ограничить отправку cookie только first-party;
— Lax — тоже что и Strict + отправлять куки при переходе на другой сайт;
— None — не ограничивать отправку cookie (будет работать только с Secure ).

Предположительно с версии Chrome 80 (февраль 2020) все куки без атрибута SameSite будут интерпретироваться как если бы для них был установлен SameSite=Lax. Поэтому если вы используете cookie, которые должны отправляться при любых запросах, для них необходимо явно установить SameSite=None.

#security #cookie

https://web.dev/samesite-cookies-explained/

Посмотрел доклад Эда Соудена — работает над государственными сайтами Великобритании — "What even is a table? A quick look at Accessibility APIs".

Эд рассказывает про работу с таблицами с точки зрения доступности. Скринридеры позволяют перемещаться по таблицам не только от колонки к колонке, но и к следующей строке в пределах одной колонки. Если применить к таблице свойство display: block, например, чтобы добавить overflow: scroll для небольших экранов, то скринридер больше ну будет воспринимать таблицу как таблицу и навигация будет сломана. Более того недостаточно использовать семантические теги, так как браузеры использует эвристику для определения табличной вёрстки. Если таблица состоит из одной ячейки, то она не будет считаться таблицей. Если таблица состоит из трёх-четырёх ячеек, которые занимают 95% ширины страницы, то она тоже не будет считаться таблицей (в Firefox). Но если таблица содержит двадцать строк, то она становится таблицей. Если в таблице в строках чередуется цвет, то она тоже будет считаться таблицей.

В конце доклада Эд советует всегда "слушать" вёрстку сайта с помощью скринридеров и не использовать атрибут role="table" для изменения семантики элемента, так это может вести к проблемам.

Доклад интересный. Очень рекомендую посмотреть, если интересуетесь темой a11y.

#a11y #internals

https://vimeo.com/139062429