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

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

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

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

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

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

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

Legacy Support

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

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

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

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

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

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

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

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

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 User Experience Report (CrUX), а также имеет большое количество в отчете и рекомендациях Google Page Speed ​​Insights. Одним из первых шагов, которые мы сделали, было определение некоторого критического CSS, который мы загружаем непосредственно в HTML, чтобы он был доступен браузеру как можно скорее — это ваше главное оружие для борьбы со сдвигами макета контента (CLS). Мы выбрали комбинацию автоматического извлечения критического CSS на основе страницы-прототипа и механизма, с помощью которого мы можем определить имена классов для извлечения (включая все подправила). Мы делаем это отдельно для общих стилей, стилей страниц товаров и стилей категорий, которые добавляются к соответствующим типам страниц.

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

Явные измерения по сравнению с CLS

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

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

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

The Case Of The Mysterious CLS Score

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

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

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

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

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

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

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

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

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

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

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

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

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

Кроме того, мы установили flex-shrink: 0 и flex-base: 340px для слайдов. изначально во флекс-боксе без упаковки. Это заставляет их располагаться на одной линии и дает приблизительную начальную ширину слайдов. With that puzzle solved — and yes, it was as much of a headache as it sounds — we added some fixes to keep room for the dots and arrows to fall into. With that in place, there is almost no CLS for the carousels anymore!

Hindsight Is ²⁰⁄₂₀

In the end, it was a lot of small changes over several months that improved our scores, and we are not finished. We mostly worked with two people on the front-end improvements, while the rest of the team focused on improving the back end. While it was probably a bit slower this way, it ensured that there was no overlapand the differences in scores could be clearly attributed. Some resources that helped a lot were the great articles here on Smashing Magazine about the magazine’s own improvements.

At some point, the things you should try become non-obvious because you don’t think they should make a huge difference, but sometime afterward you realize that they do. More than that, what this project taught us again is how important it is to have performance and the metrics for it in mind from the very beginningfrom envisioning the design and coding the prototype to the implementation in the templates. Small things neglected early on can add up to huge mountains you have to climb later on to undo.

Here are some of the key aspects we learned:

• Optimizing JavaScript is not as effective as loading it on demand;
• Optimizing CSS seems to gain more points than optimizing JavaScript;
• Write CSS classes with CLS and extraction of critical CSS in mind;
• The tools for finding CLS problems aren’t perfect yet. Think outside the box and check several tools;
• Evaluate each third-party service that you integrate for file size and performance timing. If possible, push back on integration of anything that would slow everything down;
• Retest your page regularly for CrUX changes (and especially CLS);
• Regularly check whether all of your legacy support entries are still needed.

We still have things on our list of improvements to make:

• We still have a lot of unused CSS in the main file that could be removed;
• We’d like to remove jQuery completely. This will mean rewriting parts of our code, especially in the checkout area;
• More experiments need to be conducted on how to include the external sliders;
• Our mobile point scores could be better. Further work will be needed for mobile especially;
• Responsive images need to be added for all product images;
• We’ll check the content pages specifically for improvements they may need, especially around CLS;
• Elements using Bootstrap’s collapse plugin will be replaced with the native HTML details tag;
• The DOM size needs to be reduced;
• We will be integrating a third-party service for faster and better search results. This will come with a large JavaScript dependency that we will need to integrate;
• We’ll work on improving accessibility both by looking at automated tools and by running some tests with screen readers and keyboard navigation ourselves.

Further Resources

• “DevTools Debugging Tips And Shortcuts (Chrome, Firefox, Edge),” Vitaly Friedman, Smashing Magazine
• “Some Performance Blog Posts I’ve Bookmarked And Read Lately,” Chris Coyier, CSS-Tricks
• “An In-Depth Guide To Measuring Core Web Vitals,” Barry Pollard, Smashing Magazine
• “From Semantic CSS To Tailwind: Refactoring The Netlify UI Codebase,” Charlie Gerard and Leslie Cohn-Wein, Netlify
• “CSS Auditing Tools,” Iris Lješnjanin, Smashing Magazine
• “Things You Can Do With CSS Today,” Andy Bell, Smashing Magazine
• “How To Improve CSS Performance,” Milica Mihajl ija, Calibre
• “The Mobile Performance Inequality Gap, 2021,” Alex Russell
• “Maximally Optimizing Image Loading For The Web In 2021,” Malte Ubl
• “The Humble Element And Core Web Vitals,” Addy Osmani, Smashing Magazine

(vf, yk, il, al)