В браузерном JavaScript интерфейсы стали предсказуемыми.
«Однопоточный», с транзакционным скриптом рендеринга: пустой экран — загрузка — интерфейс.
Разработчик Артём Белов из Cxense с акцентом на закон Парето рассказал, как, потратив 20% времени, рендеринг приложения на 80% быстрее с помощью приёмов «реактивного дизайна» — ещё не сформулированных, но уже используемых в продуктах с приоритет на UX.
А как насчет более опытных ребят, которые не вылезают из Webpack и не заставляют Webpack страдать, а не наоборот? Они включают в себя плагины.— Всем привет, я Артём Белов.Но поскольку мы находимся в начале разработки этой методики, экосистема предлагает нам плагин, который берет ваш HTML, генерирует на его основе HTML со встроенным CSS, выдает QR-код для рекламы.
Серьезно? После этого можно использовать «!important», чтобы прервать стили.
Возможно, стоит задаться вопросом, почему я до сих пор во фронтенде.
Слово «реактивный» в наши дни можно понять неправильно: существует большой процент людей, которые изучили React до изучения JavaScript. Поэтому произношение таких родственных слов немного двусмысленно.
Ну, для меня это все-таки физика, закон сохранения импульса.
Начнем с проблемы.
Это наш профессиональный перфекционизм.
Ведь мы не показываем интерфейс до тех пор, пока он не станет «идеальным» — по нашему мнению.
И я не знаю, что победит в номинации за информативность: белый экран браузера или спиннер с надписью «Не стесняйтесь ждать вечно»; Мне это не ясно.
Но одно можно сказать наверняка: рендеринг, как и ответ приложения, не является транзакцией.
Отображение интерфейса не является логической единицей, поэтому его необходимо разбить на части.
А во фронтенде вообще себе помогаем, лежим.
В основном, когда мы говорим о «времени загрузки» нашего приложения, мы не говорим всю фразу — «среднее время загрузки».
Хотя не нужно быть гением, чтобы сделать вторую загрузку приложения мгновенной, используя Service Worker. И грустно, что Lighthouse поощряет тот факт, что приложение может не подавать признаков жизни и только на последних двух-трех кадрах проверки говорит: «Я вообще-то собираюсь рендерить».
И получить оценку 100 и меньше в тесте производительности приложения — сейчас не самое сложное.
Гугл это заметил, спасибо.
И такое емкое понятие, как «Время интерактивности», было разделено на этапы, а именно: «Первый интерактивный», «Время последовательного интерактивного взаимодействия» и «Первая задержка ввода».
Если первые два термина можно понять с помощью Google Translate, как взаимодействовать и улучшать, то второй можно объяснить, заглянув в основную ветку браузера.
Пример.
Если пользователь нажимает на текстовое поле сразу после загрузки интерфейса, может возникнуть пауза, прежде чем в текстовом поле отобразится курсор ввода.
Это связано с тем, что основной поток был занят, и в момент щелчка интерфейс казался готовым к взаимодействию.
Все это сводится к тому, что метрики в Lighthouse имеют практически одинаковое время выполнения — тогда они должны быть сбалансированы.
«Первая осмысленная отрисовка» должна быть максимально быстрой, «Первая содержательная отрисовка» должна быть позади, а «Время последовательного взаимодействия» не должно иметь такой большой разницы от белого экрана браузера до полной готовности интерфейса.
Конечно, найдутся специалисты, которые скажут, что достигается это просто: «Нам нужно разбить приложение на маршруты в Webpack и выполнить рендеринг на стороне сервера.
Да тут работы на полчаса!» Но это не совсем так.
Уважаемый эксперт не упоминает, что на каждом новом маршруте происходит одно и то же - загрузка.
И опять же, все метрики в Lighthouse имеют между собой небольшую дельту, потому что маршрут обычно значим.
А бывает, что ты не работаешь в крупной успешной компании, и Серверного рендеринга там нет. И, пользуясь своим служебным положением, вы начинаете R&D с четкой целью — получить прогрессивный рендеринг.
Как прогрессивный JPEG в пункте 167 «Путеводителя» Лебедева.
В принципе, план НИОКР выглядит очень просто.
Нужно как-то получить прибыль.
И не забывайте о главном – времени и дедлайнах, которые любят гореть.
И, держа в руках манифест программиста-минималиста, вы должны помнить: тратьте 20% своего времени на 80% результата.
Я закрепил инструменты.
Например, лаг-радар.
Я, правда, не углублялся в Санта-Барбару, которая украла у кого-то идею, Дэн Абрамов или наоборот. На прошлой презентации JSConf Island 2018 была показана довольно интересная концепция: радар зеленый, пока не обнаружит задержки в основной ветке, и когда они чувствительны, радар становится желтым, а когда они критичны, радар становится красным.
И, нажав Cmd+Shift+P на Mac или Ctrl+Shift+P на Windows, я посмотрел процент покрытия кода.
И тут я посмотрел на связку.
И снова на обложке, и снова на связке.
И я просто решил принять ситуацию.
Мне не нужно ничего отсюда уносить.
В конце концов, во многих проектах используются инструменты, которые де-факто являются стандартами.
Например, Иван Акулов совместно с Google Chrome Labs давно создал репозиторий для оптимизации веб-пакетов — webpack-libs-optimizations. И зачем мне это повторять, говорить о Code Split, о Lazy load? Это то, что известно и является прогрессивным стандартом 2018 года.
А отвечая на вопрос «Что можно скачать за полсекундыЭ» — JS и здесь победитель.
Например, вы можете скачать 100 килобайт JPG и потратить на его обработку 0,04, но JS об этом позаботится, потому что на его обработку уходит гораздо больше времени, в 20 раз.
Потому что вам нужно запомнить, что происходит при запуске приложения.
После загрузки начинается то, что вы хотите составить: загрузить в один момент, а в другой момент разобрать, скомпилировать и выполнить код. 
Я посмотрел, что тег предлагает нам.
Вариантов много, и я решил воспользоваться подсказкой.
Хм, в зале нет ни пультов, ни телефона.
Я беру 50:50. У нас остались опции «defer» и type="module".
Они загружаются, не блокируя парсинг, но обрабатываются сами и выполняются позже, когда приложение будет к этому максимально готово — освобождая основной поток.
Но правильного варианта не существует, и на ум приходят слова великого человека Бена Шварца.
Не то чтобы он сказал это по-русски, но: 
Чтобы этого избежать, мне нужен JS, поэтому Initial Request — единственный способ избавиться от ненужных запросов.
Что ж, вам придется снова настроить Webpack. Это не всегда подключение плагинов.
Глядя на разрез бандла, я не очень понимаю, как я повторяю те или иные фрагменты кода между файлами.
Возможно, их стоит включить в Критический запрос? 
С помощью ConcatenationPlugin() мы очистим манифест Webpack, то есть список всех файлов модуля Webpack, а затем встроим этот JSON, тем самым избавившись от этого ненужного запроса.
Затем определите, существует ли асинхронный код, который можно внедрить.
И, наконец, встройте мозги Webpack прямо в страницу, чтобы вам не приходилось ждать загрузки всех модулей.
Да, возьмите фрагмент времени выполнения и вставьте его в HTML. 
В общем, интеграция мозгов Webpack даёт не самый феерический прирост, но сейчас поговорим о Critical CSS. 
Но.
мы поняли, что Critical CSS невозможен для ребят, у которых одностраничное приложение.
В конце концов, без полного HTML-маршрута инструменты не смогут создать критический CSS. 
И хорошо, что есть Кукловод, который смог это сделать.
Ведь то, что вместе с ним было представлено — папка «puppeteer-examples» на GitHub — было раскуплено для проектов.
Так родился проект Rendertron. Правда, чтобы получить от него хоть какую-то ошибку, нужно вставить адрес, нажать Enter. и всё.
Хорошо, что есть и другие пакеты npm, которые работают. Они на рынке, судя по всему, дольше.
После установки и сборки пакета, используя обычный Curl, я могу предварительно отрендерить HTML своего приложения на локальном сервере и тем самым получить Critical HTML, который так необходим для создания Critical CSS. 
Bootstrap HTML вместо ожидания рендеринга дал прирост, как и ожидалось, но останавливаться на достигнутом пока рано.
Давайте продолжим наше путешествие к критическому CSS. 
Еще раз спасибо Эdy Osmani за заботу об экосистеме и создание HtmlCriticalWebpackPlugin(), где для настройки требуется ответить всего на пару вопросов: где сохранять Critical CSS и в каком виде? 
Ох, вы могли заметить подозрительную строчку «малярка».
Это очень интересный момент, когда Оди Османи использует сторонний пакет, у которого, оказывается, даже есть веб-интерфейс.
Но, честно говоря, мне стыдно пользоваться веб-интерфейсом; видимо это для верстальщиков, у которых не установлена командная строка.
Но здесь все просто, как в рекламе Яппи из 90-х: достаточно нажать «Создать».
И это даёт не самое феерическое увеличение, но очень чувствительно для первой покраски приложения.
Мир на правильном пути, и приложение немного приближается к тому моменту, когда шрифты начинают танцевать.
Этот рубеж известен как 3 секунды.
И так начинается раздел, в котором мы, фронтенд-разработчики, редко терпим неудачу: игра со шрифтами.
Рецепты загрузки шрифтов.
Здесь нам поможет font-display. Поняв, что нам не нужно двигаться с места в карьер, давайте сначала определимся: вспышка невидимого текста, FOIT, или вспышка нестилизованного текста, FOUT, нам страшна.
И - спойлер - самое страшное для нас - это мелькание невидимого текста, так как оно вызывает больше перерисовок.
Короче говоря, посмотрев, какие свойства font-display существуют, вы сможете выбрать для себя подходящий: swap или Fallback. По большому счету, из пяти объектов недвижимости можно выбрать тот, который вам нужен, подходящего варианта нет. 
Более того, я слышал, что существует проект Font Style Matcher, который позволит мне выбрать достойный системный запасной шрифт для моего шрифта Comic Sans и не загружать его из Google Fonts. Хотя это не совсем так.
Есть такие люди, как Зак Зезерман, которые придумали концепцию FOFT. 
Что практически незаметно в браузере.
Это достигается тем, что при загрузке римского шрифта в стандартном стиле браузер уже настолько умен, что может сделать «фальшивый» жирный, курсив, подчеркнутый и зачеркнутый шрифт на основе стандартного стиля.
Вспышку дает, но ее практически нет. Для этого вам необходимо осуществить так называемую предварительную загрузку шрифта.
Но что, если я скажу вам, что шрифт можно встроить в CSS? И это правда, и это тоже дает прибавку! 
Это похоже на комбинацию техник.
Вам просто нужно встроить римский шрифт прямо в CSS. Таким образом, можно получить увеличение первого основного знакомства пользователя с приложением, а затем загружать остальные гарнитуры по мере необходимости, но не сразу.
И сейчас, после стольких манипуляций, «Time to Consistentially Interactive» все еще имеет значительную дельту от других показателей.
Я лишь улучшил окраску приложения.
Это неплохо, но не то, к чему я стремился.
Я думаю, мне нужно уловить какую-то проблему.
И ее поймали за хвост. После всего: 
Совершенно очевидно, почему это не реализовано во многих браузерах.
Прыгающая прокрутка, и как определить, что следует, а что не следует загружать – дело не самое простое.
Возможно, его доставят. Но опять же специалисты вам скажут — есть ленивая загрузка.
Но вспомните, как вы с ним взаимодействуете.
Вы не можете охватить 100% случаев.
А если вы пойдете по пути оптимизации и выполните все контрольные пункты в книге «Основная оптимизация изображений» Оди Османи, то у вас тоже останутся нерешенные проблемы.
Но я заметил, что Эди Османи любит упоминать Reddit в своих альманахах и статьях на Medium. Я вспомнил, что там работает мой знакомый, и, позвонив ему за советом, он напомнил мне, что есть такое понятие, как Percieved Performance, и это определение лежало в глубине моего сознания.
Кстати, здесь нам помогают дизайнеры.
Это когда важно не время, а то, как вы подадите свою заявку.
И очень правильная тактика для этого — «заполнители контента».
Например, YouTube может это сделать.
YouTube удается воспроизвести видео до загрузки всех вспомогательных компонентов.
Это сделано, забегая вперед, за счет заполнителей контента, таких серых анимированных плашек.
Что экосистема предлагает нам на данный момент? Ничего особенного.
КодПен.
Давайте посмотрим их реализацию.
Вполне себе карта, которая может вписаться в любой шаблон дизайна.
Давайте посмотрим… 
Нам нужно объявить несколько переменных на 30 строк, объявить грамм свойств на 50 строк, немного анимации и мы получим 100 строк кода.
Это 10 из 10 по шкале Лиа Виру.
А как насчет более опытных ребят, которые не вылезают из Webpack и не заставляют Webpack страдать, а не наоборот? Они включают в себя плагины.
Но поскольку мы находимся в начале разработки этой методики, то экосистема предлагает нам плагин, который берет ваш HTML, генерирует на его основе HTML со встроенным CSS, выдает QR-код для рекламы, видимо.
Серьезно? После этого можно использовать «!important», чтобы прервать стили.
Возможно, стоит задаться вопросом, почему я до сих пор во фронтенде.
Но есть группа людей, которым шутки по поводу их продукта просто не смешны.
ПостCSS. 
На них всегда можно положиться.
В частности, вы можете реализовать этот прием — «постоянные заполнители» — используя концепцию CSS «многофонового фона».
Это когда одно свойство «фон» может содержать несколько значений, разделенных запятыми.
CanIUse только ответы, да.
Выглядит это так, что нам знакомо.
Знакомые – благодаря Medium. 
К вашему изображению применяется линейный градиент, который отображается максимально быстро, а над ним позже появится полноразмерное изображение.
В коде это выглядит примерно так.
Первый приоритетный запрос начинает нагружать изображение, конечно, тяжелое.
И мгновенно, при получении CSS, отобразится линейный градиент. Но линейный градиент не такой прямой и плавный, как ослабление.
Поэтому код следует подобрать другим плагином, который сделает линейный градиент более плавным.
Но вы можете добавить к наложениям небольшой градиент, чтобы они покрывали все случаи.
В этом случае это не будет работать должным образом, поскольку изображение слишком сложное, чтобы создать абстракцию только с помощью линейного градиента.
Но скип здесь подойдет. 
Это модуль CLI, позволяющий создать заполнитель для вашего изображения и прикрепить его с помощью техники «множественного фона».
Конечно, полноразмерное изображение будет загружаться гораздо дольше, а плейсхолдер из squip из-за своего веса будет отображаться гораздо быстрее.
Но это не совсем то, к чему я стремлюсь.
Я бы хотел, чтобы тяжелые изображения появлялись тогда, когда они мне нужны, а не тогда, когда они нужны браузеру.
И мне нужно разделить это на два файла CSS, поместить один в , где будут легкие изображения, а затем загрузите тяжелые изображения в .
А как быть с остальными изображениями, например, в JS? 
В частности, манипуляции с SVG выглядят разочаровывающе.
Вы вроде хотите перерисовать SVG, но у вас нет контроля над ним через обычный CSS. 
Судя по новым тенденциям, SVG должен будет стать компонентом.
Использование пакета, который Дэн Абрамов использовал в «create-react-app», — «svgr».
Это инструмент CLI, который просто вставляет SVG в ваш JS, и вы можете работать с ним как с компонентом.
На самом деле это три строки кода.
Но дизайнеры, похоже, не осознают, что многие фреймворки должны иметь один корневой элемент компонента.
Наверняка я не попрошу его экспортировать SVG из Sketch «особым способом»?
Из-за ряда мелких подобных проблем приходится обратить внимание на подозрительно популярные проекты.
Например, некая «react-icon-base», которая предлагает себя в качестве замены ярлык.
А именно, пакет как бы говорит нам: вместо тег, оберните в себя ваш SVG-код, после чего я сам применю свойства: заливку, текст, обводку и все, что захотите, потому что у меня есть логика, которая служит «мостом» из CSS. 
И с помощью простой команды вы можете создать собственный шаблон svgr для своего проекта.
Честно говоря, я не знаю, почему этот проект только для React.
Далее вы можете импортировать иконки без синтаксического сахара любым удобным для вас способом.
И, наконец, отойти от возможно устаревшего тег к компонентному подходу, о котором все говорят. 
И в пользу чего? Например, вам рекомендуется попробовать использовать псевдокласс «:export» в ваших файлах SCSS\SASS. 
Я почти уверен, что это работает и в вашей версии Webpack. Псевдокласс «:export» экспортирует переменные, объявленные вами в SCSS. После этого вы можете импортировать их в JS-код. И всё, и не надо обрастать велосипедами, типа какого-нибудь JSON-файла со всеми цветами и так далее.
Svgr позволяет уменьшить первую отрисовку приложения.
Но это не так справедливо, ведь код просто перенесли с CSS на JS.
Но во-вторых, мы забыли про скип, какой будет прирост после его использования? 
Имея простые навыки динамического импорта, мы воспользуемся следующей техникой.
Давайте загрузим облегченную версию изображения, пропустим заполнитель и отобразим его в интерфейсе.
Затем при динамическом импорте в .
then() будем ждать полноразмерную иконку, не блокируя взаимодействие с интерфейсом.
В результате мы получаем SVG, который находится под нашим контролем, и мы можем
Теги: #CSS #JavaScript #frontend #interfaces #react.js #react #Оптимизация клиента #webpack #postcss #svg #yarn #response #среднее время #tti #lag-ra #preload #prerendering #inline #background-image #placeholders #градиент #прогрессивный рендеринг
-
Приятный Элемент Игр
19 Oct, 24 -
Хотите Узнать Самые Дорогие Клики В Бегуне?
19 Oct, 24
