Повышение производительности интернет-магазина (кейс)

Каждый фронтенд-разработчик гонится за одним и тем же Святым Граалем производительности: зелеными баллами в Google Page Speed. Ощутимые признаки хорошо выполненной работы всегда приветствуются. Однако, как и в случае с охотой за Граалем, вы должны задаться вопросом, действительно ли это тот ответ, который вы ищете. Не следует сбрасывать со счетов реальную производительность для ваших пользователей и то, как веб-сайт «ощущается», когда вы его используете, даже если это будет стоить вам одного или двух баллов в Page Speed ​​(иначе у всех нас была бы просто панель поиска и нестилизованный текст).

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

Работа с интернет-магазином jewellerybox была для нас долгожданным изменением темпа. Проект состоял из обновления программного обеспечения магазина до нашей собственной системы с открытым исходным кодом и переделки внешнего интерфейса магазина с нуля. Дизайн был разработан агентством дизайна и UX, которое также занималось прототипом HTML (на основе Bootstrap 4). Оттуда мы включили его в шаблоны — и на этот раз у нас был клиент, одержимый производительностью веб-сайта.

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

Интернет-магазины немного отличаются

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

• домашняя страница (и «контентные» страницы),
• страницы категорий и поиска,
• страницы сведений о продукте,
• корзина и касса (очевидно).

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

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

О чем вы думаете в первую очередь, когда представляете себе интернет-магазин? Изображения — много-много изображений товаров. Они в основном везде и будут доминировать в вашем дизайне. Кроме того, вы захотите показать много продуктов, чтобы люди покупали у вас — так что это карусель. Но ждать! Нажимают ли люди на продукты в нем? Мы можем узнать это, отследив карусель. Если мы отследим его, мы сможем его оптимизировать! И вдруг у нас на страницах появляются внешние карусели продуктов на базе искусственного интеллекта.

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

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

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

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

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

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

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

Вернемся к производительности: почему так важно снова улучшить производительность магазина? Очевидный ответ: вы хотите, чтобы люди покупали у вас . Есть несколько способов повлиять на это, и скорость вашего сайта очень важна. Исследования показывают, что каждая дополнительная секунда времени загрузки оказывает значительное влияние на коэффициент конверсии. Кроме того, скорость страницы является фактором ранжирования для поиска, а также для вашей рекламы в Google. Таким образом, повышение производительности окажет ощутимое влияние на итоговую прибыль.

Практические вещи, которые мы сделали

Некоторые узкие места в производительности легко определить, но полное улучшение — это более долгий путь со множеством поворотов и поворотов. Мы начали со всех обычных вещей, таких как повторная проверка кэширования ресурсов, просмотр того, что мы можем предварительно выбрать или загрузить асинхронно, убедившись, что мы используем HTTP/2 и TLSv1.3. Многие из них описаны в полезном обзоре CSS-Tricks, а журнал Smashing Magazine предлагает отличный контрольный список в формате PDF.

Перво-наперво: то, что загружается на все страницы

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

Значок Загрузка

Как и на многих веб-сайтах, в нашем дизайне мы используем несколько иконок. Прототип поставлялся с некоторыми пользовательскими значками, которые были встроенными символами SVG. Они были сохранены как один большой тег svg в заголовке HTML страницы с символом для каждой из иконок, который затем использовался как связанный svg в теле HTML. Это дает хороший эффект, делая их непосредственно доступными для браузера при загрузке документа, но, очевидно, браузер не может кэшировать их для всего веб-сайта.

Поэтому мы решили переместить их во внешний файл SVG и предварительно загрузить его. Кроме того, мы включили только те значки, которые действительно используем. Таким образом, файл можно кэшировать на сервере и в браузере, и не нужно будет интерпретировать лишние SVG. Мы также поддерживаем использование Font Awesome на странице (которую мы загружаем через JavaScript), но мы загружаем ее по запросу (добавляем крошечный скрипт, который проверяет наличие любых тегов <i> , а затем загружаем Font Awesome JavaScript для получения любых SVG-файлов). значки, которые он находит). Поскольку мы придерживаемся собственных значков в верхней части страницы, мы можем запустить весь скрипт после загрузки DOM.

Мы также используем смайлики в некоторых местах для цветных значков, о чем никто из нас на самом деле не думал, но об этом попросил наш редактор контента Даэна, и это отличный способ показать значки без какого-либо отрицательного влияния на производительность (единственное предостережение: разные дизайны в разных операционных системах).

Загрузка шрифта

Как и на многих других веб-сайтах, мы используем веб-шрифты для типографских нужд. Дизайн требует двух шрифтов в теле ( Josefin Sans двух начертаний), одного для заголовков ( Nixie One ) и одного для специально оформленного текста ( Moonstone Regular ). С самого начала мы хранили их локально, используя сеть доставки контента (CDN) для повышения производительности, но после прочтения замечательной статьи Саймона Херна о том, как избежать смещения макета при загрузке шрифта, мы поэкспериментировали с удалением жирного шрифта и использованием обычного.

В наших тестах визуальная разница была настолько незначительной, что ни один из наших тестировщиков не мог сказать, не увидев оба одновременно. Итак, мы уменьшили вес шрифта . Работая над этой статьей и готовя наглядное пособие к этому разделу, мы наткнулись на большие различия в браузерах на основе Chromium для Mac и браузерах на основе WebKit на экранах с высоким разрешением (ура, сложность!). Это привело к еще одному раунду дискуссий о том, что мы должны делать.

После некоторого времени назад и вперед мы решили оставить полужирный шрифт и использовать -webkit-text-stroke: 0.3px , чтобы помочь этим конкретным браузерам. Разница с использованием фактического отдельного веса шрифта незначительна, но недостаточна для нашего случая использования, когда мы почти не используем полужирный шрифт, а только несколько слов за раз (извините, любители шрифтов).

Кроме того, некоторые продукты можно персонализировать с помощью гравировки . Эти гравюры могут быть выполнены с использованием нескольких шрифтов, и для некоторых мы предлагаем предварительный просмотр с примененным шрифтом. Для них мы загружаем шрифт по запросу, когда он выбирается в раскрывающемся списке выбора шрифта. Предварительные просмотры в раскрывающемся списке — это образцы изображений того, как выглядит шрифт. Это избавляет нас от необходимости загружать 10 или более дополнительных файлов шрифтов.

Устаревшая поддержка

Однажды CSS-Tricks удивил меня статьей «Как создать фавикон в 2021 году». Мы использовали все размеры сенсорных значков в мире — статья заставила меня переоценить то, что нам действительно нужно, и показала мне, что иногда то, что было верно несколько лет назад, может больше не понадобиться. Основываясь на статье, мы ограничили наши списки фавиконов и сенсорных значков рекомендуемыми версиями.

Точно так же мы также преобразовали шрифт, который у нас был только как версия WOFF, в WOFF2 , который намного меньше, и мы решили предоставить WOFF2 для шрифтов (оставив WOFF в качестве запасного варианта). И мы удалили директивы CSS, которые больше не нужны.

Ленивая загрузка и загрузка по требованию

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

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

Одной вещью, которую мы заметили очень рано, было большое влияние клиента чата. Это было более 500 КБ одного только JavaScript, и, хотя у меня, к сожалению, больше нет диаграммы, она также загружалась медленно. Несмотря на то, что JavaScript был настроен на асинхронную загрузку, Google включил его в измерения времени до интерактивности.

Мы не смогли полностью проследить, почему это произошло, но из-за этого и его размера мы начали искать альтернативы вместо того, чтобы пытаться исправить то, над чем у нас был ограниченный контроль. Вместо этого мы убедили jewelrybox попробовать собственный виджет чата с открытым исходным кодом , который дает нам больше контроля над тем, как он загружается, и который к тому же намного меньше. Чтобы улучшить его, мы изначально загружаем только значок чата; остальное загружается, когда вы нажимаете, чтобы открыть его.

Невидимая сторонняя карусель

Jewellerybox хотела попробовать сторонний сервис, который использует искусственный интеллект для улучшения персонализации продуктов в каруселях на нескольких страницах. Для этого мы решили вызвать его API из серверной части, чтобы иметь больший контроль над тем, что загружается (без больших зависимостей JavaScript) и как долго мы ждем ответа от их службы (с определенными резервными вариантами). Благодаря этому карусели загружаются так же, как и неперсонализированные, и также могут кэшироваться с помощью уникального ключа кэша.

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

Второе место: оптимизация JavaScript — тяжелая битва с внешними врагами

Карусель подводит нас ко второй большой области, на которой мы сосредоточились: JavaScript. Мы проверили тот JavaScript, который у нас был, и большая его часть взята из библиотек для разных задач с очень небольшим количеством пользовательского кода. Мы оптимизировали код, который мы написали сами, но очевидно, что вы можете сделать только часть вашего общего кода — большие преимущества заключаются в библиотеках.

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

В нескольких случаях было! Например, мы решили заменить библиотеку слайдеров Slick на GliderJS, в которой меньше функций, но есть все, что нам нужно, плюс она быстрее загружается и имеет более современную поддержку CSS! Кроме того, мы убрали много автономных библиотек из основного файла JavaScript и начали загружать их по запросу.

Поскольку мы используем Bootstrap 4, мы по-прежнему включаем jQuery в проект, но работаем над заменой всего нативными реализациями. Для самого Bootstrap на GitHub есть версия bootstrap.native без зависимости от jQuery, которую мы сейчас используем. Он меньше по размеру и работает быстрее. Кроме того, мы генерируем две версии нашего основного файла JavaScript: одну без полифилов и одну с их включением, и мы заменяем версию с ними, когда они нужны браузеру, что позволяет нам предоставить оптимизированную основную версию для большинства людей. Мы протестировали сервис «полифилл по требованию», но его производительность не оправдала наших ожиданий.

И последнее, что касается темы jQuery. Изначально мы загружали его с нашего сервера. Мы увидели улучшение производительности в нашей тестовой системе при загрузке через Google CDN, но Page Speed ​​Insights пожаловался на производительность (интересно, кто мог это решить), поэтому мы снова протестировали хостинг самостоятельно, и в производственной среде она была фактически быстрее из-за CDN, который мы используем.

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

Третье место: изображения — форматы, размеры и все такое прочее

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

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

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

Для логотипа веб-сайта мы используем файл SVG, исходную версию которого мы получили от клиента. Логотип представляет собой замысловатый шрифт, в котором отсутствуют части букв, так как они были бы в несовершенном оттиске, сделанном вручную. В больших размерах вам нужно будет показать детали, но на веб-сайте мы никогда не используем его выше 150 на 30 пикселей. Исходный файл был размером 192 КБ, не огромный, но и не супермаленький. Мы решили поиграть с SVG и уменьшить в нем детализацию, и в итоге у нас получилась версия размером 40 КБ в разархивированном виде. При размерах дисплеев, которые мы используем, визуальной разницы нет.

Последнее, но не менее важное: CSS

Критический CSS

CSS широко фигурирует в отчете Google об опыте использования Chrome (CrUX), а также в отчете и рекомендациях Google Page Speed ​​Insights. Одной из первых вещей, которую мы сделали, было определить критический CSS, который мы загружаем непосредственно в HTML, чтобы он был доступен для браузера как можно скорее — это ваше главное оружие в борьбе со сдвигами макета контента (CLS). Мы выбрали комбинацию автоматического извлечения критического CSS на основе страницы-прототипа и механизма, с помощью которого мы можем определить имена классов для извлечения (включая все подправила). Мы делаем это отдельно для общих стилей, стилей страниц продуктов и стилей категорий, которые добавляются на соответствующие типы страниц.

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

Явные измерения против CLS

Для меня CLS — это то, что Google вытащил из своей шляпы, и теперь нам всем нужно разобраться с этим и обдумать это. В то время как раньше мы могли просто позволить контейнерам получать свой размер из элементов внутри них, теперь загрузка этих элементов может влиять на размер блока. Имея это в виду, мы использовали вкладку «Производительность» в инструментах разработчика и супер-полезный GIF-генератор Layout Shift, чтобы увидеть, какие элементы вызывают CLS. Оттуда мы посмотрели не только на сами элементы, но и на их родителей и проанализировали свойства CSS, которые повлияют на макет. Иногда нам везло — например, логотипу просто нужно было явно указать размер на мобильных устройствах, чтобы предотвратить изменение макета, — но в других случаях борьба была реальной.

Совет для профессионалов: иногда сдвиг вызывается не кажущимся элементом, а предшествующим ему элементом. Чтобы определить возможных виновников, сосредоточьтесь на свойствах, которые изменяются по размеру и интервалу. Основной вопрос, который следует задать себе: что может заставить этот блок двигаться?

Поскольку на странице так много изображений, нам пришлось потрудиться, чтобы заставить их правильно работать с CLS. Барри Поллард справедливо напоминает нам об этом в своей статье «Установка высоты и ширины на изображениях снова важна». Мы потратили много времени на определение правильных значений ширины и высоты (плюс соотношения сторон) для наших изображений в каждом случае, чтобы снова добавить их в HTML. В результате для изображений больше не происходит сдвига макета, потому что браузер получает информацию раньше.

Дело о таинственном счете CLS

Удалив множество серьезных проблем с CLS в верхней части страницы, мы столкнулись с препятствием. Иногда (не всегда) при просмотре Page Speed ​​или Lighthouse мы получали показатель CLS выше 0,3, но никогда на вкладке «Производительность». Генератор Layout Shift GIF иногда показывал это, но выглядело так, будто перемещался весь контейнер страницы .

С включенным дросселированием сети и процессора мы наконец-то увидели это на скриншотах! Заголовок на мобильных устройствах увеличился на 2 пикселя в высоту из-за элементов внутри него. Поскольку заголовок на мобильных устройствах в любом случае имеет фиксированную высоту, мы пошли на простое исправление и добавили к нему явную высоту — дело закрыто. Но это стоило нам много нервов, и это показывает, что инструментарий здесь все еще очень неточен.

Это не работает — давайте переделаем!

Как мы все знаем, показатели Page Speed ​​для мобильных устройств намного жестче, чем для настольных компьютеров, и одной из областей, где они были особенно плохи для нас, были страницы продуктов. Оценка CLS была выше крыши, и у страницы также были проблемы с производительностью (несколько каруселей, вкладок и некэшируемых элементов). Что еще хуже, макет страницы означал, что некоторая информация перетасовывалась или добавлялась дважды.

На рабочем столе у ​​нас в основном есть два столбца для контента:

• Столбец A : карусель с фотографиями товаров, за которой иногда следуют цитаты блоггеров, за которыми следует макет с вкладками с информацией о товаре.
• Колонка B : название товара, цена, описание и кнопка «Добавить в корзину».
• Строка C : карусель похожих товаров.

Однако на мобильных устройствах сначала должна была появиться карусель с фотографиями продуктов, затем столбец B, затем макет с вкладками из столбца A. Из-за этого определенная информация дублировалась в HTML, контролировалась display: none , а порядок изменялся. переключается с помощью свойства flex: order . Это определенно работает, но не очень хорошо для оценок CLS, потому что в основном все нужно переупорядочивать.

Я решил провести простой эксперимент в CodePen: смогу ли я добиться одинакового базового расположения блоков на десктопе и на мобильном устройстве, переосмыслив HTML и используя display: grid вместо flexbox, и позволит ли это мне просто переупорядочивать области сетки по мере необходимости? Короче говоря, это сработало, и это решило CLS, и у него есть дополнительное преимущество: теперь название продукта появляется в HTML гораздо раньше, чем раньше — дополнительная победа в SEO!

Взлом карусели для CLS

Слово «карусель» уже упоминалось несколько раз — и не зря. Мало того, что мы изменили библиотеку каруселей, которую используем (и изменили поведение загрузки изображений в ней), нам еще пришлось иметь с ней дело для CLS, потому что у нас есть несколько страниц, на которых карусель находится выше сгиба и, следовательно, может сильно повлиять на показатели скорости.

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

Извините за этот короткий разглагольствования, но на самом деле карусели продуктов и категорий — это идеальный шторм гибких элементов в адаптивном магазине: изображения могут быть не универсальной высоты, названия продуктов могут занимать несколько строк, а у вас могут быть или не быть ярлыки. По сути, это сводится к следующему: фиксированная высота строки невозможна, и вы также не знаете ширину. Веселые времена.

В конце концов, мы решили сделать все слайды (кроме первого) visibility: hidden до тех пор, пока карусель не завершит загрузку, после чего мы добавляем к карусели класс, чтобы все слайды снова стали видимыми . Это решает проблему, связанную с тем, что поначалу он занимает дополнительную высоту.

Кроме того, мы устанавливаем flex-shrink: 0 и flex-base: 340px для слайдов в флексбоксе без упаковки изначально. Это заставляет их располагаться на одной линии и дает приблизительную начальную ширину слайдов. Когда эта загадка решена — и да, это была такая головная боль, как кажется — мы добавили некоторые исправления, чтобы оставить место для точек и стрелок. После этого для каруселей почти не осталось CLS!

Задним числом ²⁰ ⁄ ₂₀

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

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

Вот некоторые из ключевых аспектов , которые мы узнали:

• Оптимизация JavaScript не так эффективна, как его загрузка по требованию;
• Кажется, что оптимизация CSS приносит больше очков, чем оптимизация JavaScript;
• Пишите классы CSS с учетом CLS и извлечения критического CSS;
• Инструменты для поиска проблем CLS еще не совершенны. Думайте нестандартно и проверьте несколько инструментов;
• Оцените каждую стороннюю службу, которую вы интегрируете, по размеру файла и времени производительности. Если возможно, отложите интеграцию всего, что замедляет работу;
• Регулярно тестируйте свою страницу на наличие изменений CrUX (и особенно CLS);
• Регулярно проверяйте, нужны ли все ваши устаревшие записи поддержки.

У нас все еще есть вещи в нашем списке улучшений , которые нужно сделать:

• У нас все еще есть много неиспользуемого CSS в основном файле, который можно удалить;
• Мы хотели бы полностью удалить jQuery. Это будет означать переписывание частей нашего кода, особенно в области оформления заказа;
• Необходимо провести дополнительные эксперименты по включению внешних ползунков;
• Наши мобильные баллы могли бы быть лучше. Дальнейшая работа будет необходима, особенно для мобильных устройств;
• Адаптивные изображения должны быть добавлены ко всем изображениям товаров;
• Мы проверим страницы с контентом на наличие улучшений, которые могут им понадобиться, особенно в отношении CLS;
• Элементы, использующие плагин Bootstrap для сворачивания, будут заменены собственным тегом details HTML;
• Размер DOM необходимо уменьшить;
• Мы будем интегрировать сторонний сервис для более быстрого и качественного поиска. Это приведет к большой зависимости от JavaScript, которую нам нужно будет интегрировать;
• Мы будем работать над улучшением специальных возможностей, рассматривая автоматизированные инструменты и самостоятельно проводя некоторые тесты с программами чтения с экрана и навигацией с помощью клавиатуры.

Дополнительные ресурсы

• «Советы и ярлыки по отладке DevTools (Chrome, Firefox, Edge)», Виталий Фридман, Smashing Magazine
• «Некоторые сообщения в блоге о производительности, которые я добавил в закладки и прочитал в последнее время», Крис Койер, CSS-Tricks
• «Подробное руководство по измерению основных веб-показателей», Барри Поллард, Smashing Magazine
• «От семантического CSS до Tailwind: рефакторинг кодовой базы пользовательского интерфейса Netlify», Чарли Джерард и Лесли Кон-Вейн, Netlify
• «Инструменты аудита CSS», Ирис Лешнянин, Smashing Magazine
• «Вещи, которые вы можете сделать с CSS сегодня», Энди Белл, Smashing Magazine
• «Как улучшить производительность CSS», Милица Михайлия, Caliber
• «Разрыв неравенства в производительности мобильных устройств, 2021 г.», Алекс Рассел.
• «Максимальная оптимизация загрузки изображений для Интернета в 2021 году», Malte Ubl
• «Скромный элемент <img> и основные веб-жизненные силы», Эдди Османи, Smashing Magazine