Русский
Русский
English
Статистика
Реклама

Lighthouse

Перевод Безжалостное избавление от Layout Shift на netlify.com

04.12.2020 00:04:03 | Автор: admin

Приветствую. Представляю вашему вниманию перевод статьиRuthlessly Eliminating Layout Shift On Netlify.com, опубликованной 25 ноября 2020 года автором Zach Leatherman.

На сайте Netlify у нас есть небольшой баннер, который появляется вверху для привлечения трафика к новым и интересным вещам, происходящим в мире Netlify.

Этот баннер состоит из двух частей:

  1. Расширенная фича HTML, о которой знают только разработчики старой школы: гиперссылка.

  2. Кнопка закрытия (которая сохраняет предпочтение для будущих загрузок страницы)

В жизненном цикле этого компонента есть несколько ключевых этапов производительности, и вот как это работало раньше:

  1. Первоначальный рендеринг страницы. По умолчанию баннер скрыт. До загрузки JavaScript или без JavaScript баннер не отображается.

  2. После загрузки JavaScript мы проверяем localStorage, чтобы узнать, закрывал ли пользователь баннер ранее. Значение - URL-адрес ссылки, чтобы при изменении баннера он снова отображался, даже если пользователь его закрыл. Если нужно - рендерим баннер.

  3. Наконец, мы вешаем события на кнопку закрытия. Для гиперссылки это не нужно, потому что ее поведение предоставляется исключительно в HTML (вааау).

Шаги 2 и 3 объединены и выполняются вместе в одном компоненте. В некоторых предедущих версиях сайта время между шагами 1 и 2 могло достигать ~600 мс.

При редизайне нашего сайта (заметьте, быстрее) мы вставили JavaScript шагов 2 и 3 в конец <body>, и задержка все еще была:

Решение

Что нам нужно сделать? Сделать поведение наоборот. Обычно баннер по умолчанию скрыт. Мы должны сделать баннер видимым по умолчанию и с помощью JavaScript скрывать его, если нужно.

Это изменяет наш выше упомянутый Шаг 1, первоначальный рендеринг страницы. Теперь без JavaScript или до загрузки JavaScript баннер будет виден.

Мы также разделили код JavaScript-компонента на две отдельные части: в одной проверяем, есть ли у пользователя флаг для скрытия, и отдельный веб-компонент для привязки событий.

Update: Я собрал этот код и выложил на GitHub для повторного использования.

HTMLи CSS

Мы используем opacity для скрытия кнопки закрытия, чтобы изза неё не перерисовывался компонент, когда он отобразится с помощью JavaScript.

.banner--hide announcement-banner,announcement-banner[hidden] {  display: none;}[data-banner-close] {  opacity: 0;  pointer-events: none;}.banner--show-close [data-banner-close] {  opacity: 1;  pointer-events: auto;}
<announcement-banner>  <a href="http://personeltest.ru/aways/www.netlify.com/sustainability/">Read about our Sustainability</a>  <button type="button" data-banner-close>Close</button></announcement-banner>

JavaScript

banner-helper.js, вставленный в<head> страницы:

// Адрес CTA ссылки, мы инжектим его из JSON файлаlet ctaUrl = "https://www.netlify.com/sustainability/";let savedCtaUrl = localStorage.getItem("banner--cta-url");if(savedCtaUrl === ctaUrl) {  document.documentElement.classList.add("banner--hide");}

banner.js, отоложен на потом (на сколько позже - зависит от вас):

class Banner extends HTMLElement {  connectedCallback() {    // Независимо от того, когда это выполняется, кнопка закрытия будет скрыта,     // пока этот класс не будет добавлен - он предотвращает призрачные клики     // по кнопке до добавления обработчика событий.    this.classList.add("banner--show-close");    let button = this.getButton();    if(button) {      button.addEventListener("click", () => {        this.savePreference();        this.close();      });    }  }  getButton() {    return this.querySelector("[data-banner-close]");  }  savePreference() {    let cta = this.querySelector("a[href]");    if(cta) {      let ctaUrl = cta.getAttribute("href");      localStorage.setItem("banner--cta-url", ctaUrl);    }  }  close() {    this.setAttribute("hidden", true);  }}window.customElements.define("announcement-banner", Banner);

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

Результат

Обратите внимание, что первый рендер содержит баннер! Это одинаковый рендеринг вне зависимости от того, задействован ли JavaScript или нет.

На этой диаграмме видно, что мы снизили показатели Layout Shift до нуля.

И поскольку мы вставили скрипт для повторных просмотров в <head>, когда пользователь скрывает баннер и переходит на новую страницу, баннер также будет скрыт перед первым рендерингом.

Довольно неплохо для таких маленьких изменений!

Следующей целью будет улучшение отображения веб-шрифтов.

Подробнее..

Не лайтхаусом единым как проверить свой сайт со всех сторон

14.10.2020 10:20:11 | Автор: admin


Когда мы говорим о веб-валидаторах и оптимизации сайта под них, мы чаще всего имеем ввиду Lighthouse/Pagespeed Insights от Google, который давно стал де-факто стандартом для оценки производительности сайта. Кто-то стремится к заветным 100 баллам даже на прототипах и шаблонных приложениях в две кнопки, кто-то в шутку создает абсолютно недоступный сайт с идеальным рейтингом, но для всех фронтендеров лайтхаус предоставляет вменяемую, хоть и довольно поверхностную, аналитику производительности сайта и поиск бутылочных горлышек. Однако скорость загрузки лишь один из множества параметров, которые стоит проверять на своём сайте, и для большинства других есть свои валидаторы и скоринговые алгоритмы. Мы рассмотрим инструменты для каждого из значимых направлений и составим список, по которому стоит прогонять свой сайт, чтобы в дальнейшем не отлавливать проблемы вручную.

На что мы будем обращать внимание?


Разбивка на категории может быть у каждого своя, мы возьмём следующую:

  • Производительность, об неё уже достаточно сломано копий
  • Доступность, идущая следом по важности
  • Чистота и качество кода
  • Сетевые проверки
  • SEO и остальное


Доступность


Главная головная боль разработчика после скорости загрузки обеспечить пользователям всех групп удобное взаимодействие с сайтом. Всё просто, достаточно следовать WCAG (Web Content Accessibility Guidelines), расставлять альтернативный текст для картинок, форм и иконок, следить за читаемостью страницы со скринридера, соблюдением i18n и кучи других вещей из стандартов w3, которые невозможно удержать в голове, но важно не забывать в вебе.

Web Accessibility Evaluation Tool


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



Automated Accessibility Testing Tool


AATT от PayPal всесильный комбайн, стандартный инструмент валидации для кучи крупных компаний. Работает не только с вебом, потому и сидит на локалхосте, умеет общаться по API с другими серверами на вашей машине.

Axe by Deque


Axe входит в состав AATT, но также доступен в виде отдельного расширения для Chrome. Подойдёт для быстрой проверки уже выверенного продукта. Вообще у него довольно крутая экосистема, которой пользуются такие гиганты как Google и Microsoft.

WCAG


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

Код


Тут важно вспомнить что все эти валидаторы обычные алгоритмы, которые могут ошибаться и в 90% случаем найдут за что вас прищучить. Просто обращайте внимание на свои косяки и игнорируйте косяки программные.

Nu HTML Checker


Nu удобный HTML валидатор от W3C с подробными предупреждениями и проверкой многих неочевидных правил:



CSS Validator


Как следует из названия, подробный валидатор CSS от W3C, аггрегирует ошибки и вываливает целые тонны предупреждений, которые просто невозможно взять и пофиксить в один заход.

CSS Stats


Офигенный сервис, наглядно разбирающий ваш CSS на части. Покажет в порядке использования все цвета, кегли, гарнитуры, посчитает все свойства, отступы, z-индексы и вообще поможет справиться с лапшеобразными стилями:







i18n Checker


Этот чекер покажет используемые языки, проверит содержимое соответстчующих тегов и заголовков. Нужен редко, но полезен.

Rocketvalidator


Сервис действительно очень быстро анализирует HTML и CSS, но скоринг ещё не доделан.

Сеть и ссылки



Link Checker


Крутой чекер от W3C, документирует коды ответа и собственно проблемы со всеми ссылками, до которых может дотянуться при заданной глубине рекурсии



Проверка оптимизации для мобильных устройств


Этот гугловский портал показывает недогруженные ресурсы и отображает загружаемый роботами контент.

Pagewatch


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



SEO и прочее



Browseo


Инструмент, показывающий сайт с точки зрения поисковых ботов.

Majestic report


Статистика с кучей графиков по трендам и темам.

Sitecheck


Лёгкий аудит безопасности со своим скорингом и мониторингом чёрных списков/скама/спама. Ищёт уязвимости и предлагает решения:



Favicon Check


Этот инструмент проверит наличие и совместимость иконок сайта для всех платформ, включая мобильные иконки для PWA.



Заключение


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



На правах рекламы


Подыскиваете VDS для отладки проектов, сервер для разработки и размещения? Вы точно наш клиент :) Посуточная тарификация серверов самых различных конфигураций, антиDDoS и лицензии Windows уже включены в стоимость.

Подробнее..

Бенчмарки VKUI и других ребят из UI-библиотек

26.05.2021 12:10:08 | Автор: admin

Меня зовут Григорий Горбовской, я работаю в Web-команде департамента по экосистемным продуктам ВКонтакте, занимаюсь разработкой VKUI.

Хочу вкратце рассказать, как мы написали 8 тестовых веб-приложений, подключили их к моно-репозиторию, автоматизировали аудит через Google Lighthouse с помощью GitHub Actions и как решали проблемы, с которыми столкнулись.

VKUI это полноценный UI-фреймворк, с помощью которого можно создавать интерфейсы, внешне неотличимые от тех, которые пользователь видит ВКонтакте. Он адаптивный, а это значит, что приложение на нём будет выглядеть хорошо как на смартфонах с iOS или Android, так и на больших экранах планшетах и даже десктопе. Сегодня VKUI используется практически во всех сервисах платформы VK Mini Apps и важных разделах приложения ВКонтакте, которые надо быстро обновлять независимо от магазинов.

VKUI также активно применяется для экранов универсального приложения VK для iPhone и iPad. Это крупное обновление с поддержкой планшетов на iPadOS мы представили 1 апреля.

Адаптивный экран на VKUIАдаптивный экран на VKUI

Масштабирование было внушительным поэтому мы провели аудит, проанализировали проблемы, которые могут возникнуть у нас и пользователей при работе с VKUI, и заодно сравнили свои решения с продуктами ближайших конкурентов.

Какие задачи поставили

  1. Выявить главные проблемы производительности VKUI.

  2. Подготовить почву, чтобы развернуть автоматизированные бенчмарки библиотеки и наших веб-приложений на основеVKUI.

  3. Сравнить производительность VKUI и конкурирующих UI-фреймворков.

Технологический стек

Инструменты для организации процессов:

Чтобы проще взаимодействовать с несколькими веб-приложениями, в которых применяются разные UI-библиотеки, здесь используем lerna. Это удобный инструмент, с помощью которого мы объединили в большой проект ряд приложений с отличающимися зависимостями.

Бенчмарки мы проводим через Google Lighthouse официальный инструмент для измерения Web Vitals. Де-факто это стандарт индустрии для оценки производительности в вебе.

Самое важное делает GitHub Actions: связывает воедино сборку и аудит наших приложений.

Библиотеки, взятые для сравнения:

Название

Сайт или репозиторий

VKUI

github.com/VKCOM/VKUI

Material-UI

material-ui.com

Yandex UI

github.com/bem/yandex-ui

Fluent UI

github.com/microsoft/fluentui

Lightning

react.lightningdesignsystem.com

Adobe Spectrum

react-spectrum.adobe.com

Ant Design

ant.design

Framework7

framework7.io


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

Тестируемые приложения

Первым делом мы набросали 8 приложений. В каждом были такие страницы:

  1. Default страница с адаптивной вёрсткой, содержит по 23 подстраницы.

    • На главной находится лента с однотипным контентом и предложением ввести код подтверждения (абстрактный). При его вводе на несколько секунд отображается полноэкранный спиннер загрузки.

    • Страница настроек, в которую входит модальное окно с примитивным редактированием профиля и очередным предложением ввести код.

    • Страница с простым диалогом условно, с техподдержкой.

  2. List (Burn) страница со списком из 500 элементов. Главный аспект, который нам хотелось проверить: как вложенность кликабельных элементов влияет на показатель Performance.

  3. Modals страница с несколькими модальными окнами.

Не у всех UI-фреймворков есть аналогичные компоненты недостающие мы заменяли на равнозначные им по функциональности. Ближе всего к VKUI по компонентам и видам их отображения оказались Material-UI и Framework7.

Сделать 8 таких приложений поначалу кажется простой задачей, но спустя неделю просто упарываешься писать одно и то же, но с разными библиотеками. У каждого UI-фреймворка своя документация, API и особенности. С некоторыми я сталкивался впервые. Особенно запомнился Yandex UI кажется, совсем не предназначенный для использования сторонними разработчиками. Какие-то компоненты и описания параметров к ним удавалось найти, только копаясь в исходном коде. Ещё умилительно было обнаружить в компоненте хедера логотип Яндекса <3

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

Автоматизация

Краткая блок-схема, описывающая процессы в автоматизацииКраткая блок-схема, описывающая процессы в автоматизации

Подготовили два воркфлоу:

  • Build and Deploy здесь в первую очередь автоматизировали процессы сборки и разворачивания. Используем surge, чтобы быстро публиковать статичные приложения. Но постепенно перейдём к их запуску и аудиту внутри GitHub Actions воркеров.

  • Run Benchmarks а здесь создаётся issue-тикет в репозитории со ссылкой на активный воркфлоу, затем запускается Lighthouse CI Action по подготовленным ссылкам.

UI-фреймворк

URL на тестовое приложение

VKUI

vkui-benchmark.surge.sh

Ant Design

ant-benchmark.surge.sh

Material UI

mui-benchmark.surge.sh

Framework7

f7-benchmark.surge.sh

Fluent UI

fluent-benchmark.surge.sh

Lightning

lightning-benchmark.surge.sh

Yandex UI

yandex-benchmark.surge.sh

Adobe Spectrum

spectrum-benchmark.surge.sh


Конфигурация сейчас выглядит так:

{  "ci": {    "collect": {      "settings": {        "preset": "desktop", // Desktop-пресет        "maxWaitForFcp": 60000 // Время ожидания ответа от сервера      }    }  }}

После аудита всех приложений запускается задача finalize-report. Она форматирует полученные данные в удобную сравнительную таблицу (с помощью магии Markdown) и отправляет её комментарием к тикету. Удобненько, да?

Пример подобного репорта от 30 марта 2021 г.Пример подобного репорта от 30 марта 2021 г.

Нестабильность результатов

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

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

Предупреждения из отчётов Google LighthouseПредупреждения из отчётов Google Lighthouse

GitHub Actions по умолчанию выполняет задачи параллельно, как и в нашем воркфлоу с бенчмарками. Решение ограничить максимальное количество выполняющихся одновременно задач:

jobs.<job_id>.strategy.max-parallel: 1

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

Результаты от 30 марта 2021 г.

VKUI (4.3.0) vs ant:

app

type (app link)

report

performance

vkui (4.3.0)

default

report

0.99

ant

default

report

0.99

vkui (4.3.0)

modals

report

1

ant

modals

report

0.99

vkui (4.3.0)

list

report

0.94

ant

list

report

0.89

list - У ant нет схожего по сложности компонента для отрисовки сложных списков, но на 0,05 балла отстали.

VKUI (4.3.0) vs Framework7:

app

type (app link)

report

performance

vkui (4.3.0)

default

report

0.99

f7

default

report

0.98

vkui (4.3.0)

modals

report

1

f7

modals

report

0.99

vkui (4.3.0)

list

report

0.94

f7

list

report

0.92

list - Framework7 не позволяет вложить одновременно checkbox и radio в компонент списка (List).

VKUI (4.3.0) vs Fluent:

app

type (app link)

report

performance

vkui (4.3.0)

default

report

0.99

fluent

default

report

0.94

vkui (4.3.0)

modals

report

1

fluent

modals

report

0.99

vkui (4.3.0)

list

report

0.94

fluent

list

report

0.97

modals - Разница на уровне погрешности.

list - Fluent не имеет схожего по сложности компонента для отрисовки сложных списков.

VKUI (4.3.0) vs Lightning:

app

type (app link)

report

performance

vkui (4.3.0)

default

report

0.99

lightning

default

report

0.95

vkui (4.3.0)

modals

report

1

lightning

modals

report

1

vkui (4.3.0)

list

report

0.94

lightning

list

report

0.99

list - Lightning не имеет схожего по сложности компонента для отрисовки сложных списков.

VKUI (4.3.0) vs mui:

app

type (app link)

report

performance

vkui (4.3.0)

default

report

0.99

mui

default

report

0.93

vkui (4.3.0)

modals

report

1

mui

modals

report

0.96

vkui (4.3.0)

list

report

0.94

mui

list

report

0.77

default и modals - Расхождение незначительное, у Material-UI проседает First Contentful Paint.

list - При примерно одинаковой загруженности списков в Material-UI и VKUI выигрываем по Average Render Time почти в три раза (~1328,6 мс в Material-UI vs ~476,4 мс в VKUI).

VKUI (4.3.0) vs spectrum:

app

type (app link)

report

performance

vkui (4.3.0)

default

report

0.99

spectrum

default

report

0.99

vkui (4.3.0)

modals

report

1

spectrum

modals

report

1

vkui (4.3.0)

list

report

0.94

spectrum

list

report

1

list - Spectrum не имеет схожего по сложности компонента для отрисовки сложных списков.

VKUI (4.3.0) vs yandex:

app

type (app link)

report

performance

vkui (4.3.0)

default

report

0.99

yandex

default

report

1

vkui (4.3.0)

modals

report

1

yandex

modals

report

1

vkui (4.3.0)

list

report

0.94

yandex

list

report

1

default - Разница на уровне погрешности.

list - Yandex-UI не имеет схожего по сложности компонента для отрисовки сложных списков.

modals - Модальные страницы в Yandex UI объективно легче.

Выводы из отчёта Lighthouse о VKUI

  • VKUI по показателям на одном уровне с другими библиотеками. Сильных просадок, как и значительного превосходства, нет.

  • Одно из явных проблемных мест вложенные Tappable протестированы на большом списке. Единственная библиотека, в которой полноценно реализован этот кейс, Material-UI. И VKUI уверенно обходит её по производительности.

  • Lighthouse ругается на стили после сборки много неиспользуемых. Они же замедляют First Contentful Paint. Над этим уже работают.

Два CSS-чанка, один из которых весит 27,6 кибибайт без сжатия в gzДва CSS-чанка, один из которых весит 27,6 кибибайт без сжатия в gz

Планы на будущее vkui-benchmarks

Переход с хостинга статики на локальное тестирование должен сократить погрешность: уменьшится вероятность того, что из-за внешнего фактора станет ниже балл у того или иного веб-приложения. Ещё у нас в репортах есть показатель CPU/Memory Power и он немного отличается в зависимости от воркеров, которые может дать GitHub. Из-за этого результаты в репортах могут разниться в пределах 0,010,03. Это можно решить введением перцентилей.

Также планируем сделать Lighthouse Server для сохранения статистики по бенчмаркам на каждый релиз.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru