Максимальное ускорение: делаем загрузку лендингов быстрее и минимизируем потери трафика.

Введение

Всем привет, Жёлтый на связи! Сегодня я хочу разобрать по косточкам одну из ключевых технических проблем любого арбитражника — скорость загрузки лендингов и вытекающие из этой проблемы потери трафика. Всем известно, что скорость загрузки страницы напрямую влияет на конверсию. Согласно исследованию Unbounce, проведённому в 2019 году, почти 70% пользователей признали, что скорость страницы влияет на их желание покупать онлайн. Вот ещё немного цифр из исследований: самые высокие показатели CR достигаются на страницах со временем загрузки от 0 до 2 секунд, а с каждой дополнительной секундой конверсия снижается в среднем на 4,42%​​. На данный момент среднее время загрузки мобильной веб-страницы составляет 15,3 секунды, что значительно превышает оптимальные показатели.

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

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

Хостинг

Первое, что вы должны учитывать перед тем, как начать сливать трафик — это вопрос физической удалённости вашего сервера от той страны, на которую будет дана реклама. Всё просто: чем дальше сервак — тем хуже скорость. Проверяется так: сначала замеряем скорость загрузки нашего лендинга из под прокси страны датацентра. Например: сервак у вас в Германии — берём хороший DE прокси и под ним заходим на ленд и замеряем секундомером скорость загрузки. Затем берём хороший прокси под целевое гео (например, Филиппины) и уже под ним заходим на наш лендинг и опять измеряем время. Дальше смотрим: какова разница, и насколько она критична.

Если вы работаете с каким-то одним макро-гео (т.е. Европа-Азия-Латам-Африка и т.п.), то лучше взять себе сервер в стране, у которой есть хорошая связанность с вашим целевым регионом. Где можно взять эту информацию? Смотрим карту магистральных кабелей сети интернет в картинках Яндекса или Гугла и выбираем.

У меня лично получилось вот так:

• Под Европу: DE, UK
• Под Азию и Австралию: SG
• Под USA и Canada: любая часть US
• Под Латам: юг US либо BR
• Под Арабов и Африку: SA, TR

Но что делать, если вы работаете не с одним, а с несколькими макро-гео и не хотите покупать кучу серверов? В таком случае, я бы порекомендовал вам хоститься на юге США. Оттуда в целом приемлемая связь до любой точки мира: Европа/Латам получше, Азия/Африка похуже. Я, например, использую сервера в Майами от компании FriendHosting и, если вы не льёте чернейшую грязь, вполне рекомендую вам воспользоваться их услугами.

Помимо прокси под гео проверять доступность и скорость загрузки ваших лендингов из разных регионов можно используя следующие сервисы:
Pingdom — бурж сервис с довольно небольшим доступным набором гео (из РФ потребуется VPN) + примерно такого же типа сервис Gift Of Speed.

В противовес им есть Ping-Admin — русскоязычный сервис с широчайшим выбором стран, рекомендую!

Версия протокола HTTP

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

Вот как это проверить: запускаем Google Chrome, переходим в Developer Tools (на винде — жмём F12) и там на вкладку Network. Далее загружаем наш сайт и изучаем данные, как на скрине ниже.

Если вы видите везде http/1.1, то вам придётся произвести общение с поддержкой вашего хостинга и узнать, возможно ли включить версию повыше. Если же вы только подбираете хостинг — уточняйте этот вопрос заранее!

Конструкторы

Если в вашей воронке присутствуют промежуточные сайты, на которых хостятся вайты, а блэк отображается путём того, что вы вставляете на этот вайт JS-интеграцию от, например, Кейтаро либо же если вы просто используете вайт-кнопку: «Из какой вы страны» или «Вам уже есть 18 лет?«, то у вас появляется дополнительная головная боль.

Теперь вам нужно понять не только скорость от гео юзера до гео сервера с трекером, но и скорость от юзера до гео сайта-конструктора.

Правило тут одно: чем больше разных серверов используется в связке, тем медленнее по итогу всё будет работать, и тем больше будут потери трафика! На конструкторах эти потери могут доходить до 50-75%, видел такие цифры своими глазами на связке Тайланд + американский конструктор.

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

Редиректы

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

Чаще всего вопрос редиректов актуален, когда вы льёте на что-то типа смартлинка/на ссылку ПП или на офферы с оплатой на сайте. Партнёрки чаще всего дают не конечный адрес, а обёрнутый в редирект, чтобы иметь возможность считать статистику и т.п. Но вот если одни партнёрки реселлят другие партнёрки, а те в свою очередь гонят трафик к конечному реклу…. Тогда кол-во редиректов может начать превышать допустимые пределы.

Чтобы отслеживать редиректы в вашей воронке, пользуйтесь прекрасными расширениями Link Redirect Trace либо Redirect Path. Первый есть и под Firefox, если что.

Совет тут один: почаще работайте с прямыми реклами!

CloudFlare

Какой разговор об ускорении загрузки обойдётся без упоминания CloudFlare? Пожалуй, что никакой. Клауд может закешировать у себя все JS-скрипты, CSS-стили и картинки и выдавать их пользователям. В чём прикол? А он в том, что у Клары масса серверов, разбросанных по всему миру, и почти наверняка найдётся тот, что будет находится достаточно близко к юзеру. Соответственно, ресурсы загрузятся быстро + снизится нагрузка на ваш собственный сервак.

И вот именно для этого (а вовсе не для прятанья IP-адресов от фэбэ) Клара отлично подходит. Чтобы увидеть воочию, что кеширование работает, можете прокинуть ваш домен через CloudFlare, а потом зайти на него и посмотреть на вкладке Network в Developer Tools следующее:

Если видите в заголовке cf-cache-status слово HIT — всё гут, ресурс подгружается из CDN.

Да, учтите, что по умолчанию клауд не кеширует html или тем более php, что более чем правильно, ибо эти файлы у нас зачастую генерируются динамически — со всякими там макросами трекера типа {subid}. А вот полный список расширений файлов, которые клауд-таки кеширует.

Про более тонкие настройки кеша в CloudFlare читайте вот тут.

Работа с изображениями

Обычно одним из самых «тяжёлых» элементов любого сайта являются картинки. Поэтому первым делом, после того как вы наладили ваши хостинги и сервера, смотрите на то, сколько весят изображения. Мы с вами будет изменять их размеры, сжимать, использовать современные форматы и отказываться от неэффективных, включать ленивую загрузку и т.д.

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

Погнали!

Изменение длины и ширины

Для начала просто зайдите в папку с вашим лендингом и отсортируйте все файлы по размеру, по убыванию. Я для этого использую Total Commander, но сойдёт любой файловый менеджер.

На скрине видно, что самый тяжёлый файл, весом в 2.7 мегабайт — это картинка, размером 1890х1270 пикселей. Кому она такая нужна на лендинге? Очевидно, что никому. Она тупо жрёт трафик!

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

Для быстрого пакетного изменения размеров изображений рекомендую юзать софты навроде ImBatch или XnConvert. Либо возьмите мой скрипт resize1280.bat. Копируете скрипт в папку с картинками, запускаете и через минуту все картинки будут нужного размера.

Вот та же самая папка, но уже после того, как я изменил размеры у четырёх самых крупных картинок. Гляньте вниз вправо. Видите общий размер папки? Он изменился практически в 2 раза, с восьми до четырёх мегабайт!

Сжатие

Самыми распространёнными форматами картинок в этих ваших интернетах являются JPG и PNG. И тот и другой используют внутри различные алгоритмы сжатия контента, чтобы не занимать много места. Но зачастую даже их можно «досжать».

С помощью чего это можно сделать? Вот несколько вариантов:

• сервис TinyPNG — поддерживает и JPG и PNG, есть ограничения на бесплатное использование;
• утилита PngQuant — бесплатная софтина для PNG, запускаемая из командной строки, либо мой скрипт comresspng.bat, который её использует под капотом;
• библиотека MozJPEG — один из лучших вариантов для JPG. В комплекте идёт утилита cjpeg для работы из командной строки. Либо используйте мой скрипт compressjpg.bat, сделанный на её основе.

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

Вот 2 пары изображений, в каждом случае удалось добиться сжатия более чем в 2.5 раза!

Если же мы применим сжатие ко ВСЕМ PNG-файлам нашего лендинга, то получим общее уменьшение веса лендинга ЕЩЁ в 2 раза, было 4 мегабайта, стало 2 мегабайта.

А вот ниже пример для обработки пачки JPG-файлов: сжатие в 8 раз, ха!

Используем новые форматы: WebP и Avif

Я даже не буду убеждать вас перейти вместо JPG и PNG, на WebP, а просто покажу очередной скриншот.

Итак, вместо 1.7 мегабайта в PNG у нас стало 236 килобайт. Разница в 7 (семь) с лишним раз! Распространённость формата такова, что на 95% девайсов в мире он будет работать на ура.

Если паритесь по поводу оставшихся 5%, то вы всегда можете прописать в HTML код так, что этим людям будут показаны картинки в PNG/JPG. Выглядеть это будет примерно так:

<picture>
  <source srcset="image.webp" type="image/webp">
  <source srcset="image.jpg" type="image/jpeg"> 
  <img src="image.jpg" alt="Alt Text!">
</picture>

Ну а если хотите пойти ещё дальше, то… конвертируйте свои PNG/JPG в AVIF! Там пока что поддержка похуже, но результаты зачастую интереснее. Для популяризации формата создан отдельный сайт на котором можно попробовать сконвертировать свои файлы, но я бы вместо этого рекомендовал вам заюзать бесплатную софтину ImageMagick ну или на крайняк сервис Convert.io.

Вот результат в AVIF, который получен с помощью ImageMagick и его сравнение со сжатыми JPG:

Как видите, в двух случаях победил AVIF, а в двух других — сжатие через MozJPEG. Так что экспериментируйте и выбирайте то, что лучше подходит именно вам.

Lazy loading

Простой трюк, значительно повышающий скорость загрузки ваших лендингов. Сплошные плюсы, минусов нет, и поэтому рекомендую использовать данную фичу ВСЕГДА и везде!

Так что это такое, и как работает? Ленивая подгрузка означает, что изображения проклы или ленда не будут загружаться, пока не понадобятся пользователю (т.е. пока он до них не доскроллит).

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

Обычное изображение кодируется в HTML как тег img, например:
<img src="1.jpg"/>

Изображение с «ленивой загрузкой» отличается всего лишь одним атрибутом:
<img loading="lazy" src="1.jpg"/>

Берём любой текстовый редактор, открываем index.html лендинга, запускаем замену текста и меняем <img на <img loading="lazy". Изи!

Работа с Gif

Первое, что необходимо уяснить: GIF — это ЗЛО! Практически везде, где используются GIF их можно и нужно заменять на видео.

У вас есть на выбор 2 формата: MP4 или WebM. Но в любом случае видео будет занимать раз в 10 (десять!) меньше места. По-моему, выбор очевиден. Используйте для конвертирования гифок мои скрипты: gif2mp4.bat и gif2webm.bat.

А вот что нужно сделать в html-файле — заменяем ваш тег <img>, где была гифка на следующую конструкцию:

<video autoplay loop muted playsinline>
<source src="video.webm" type="video/webm">
<source src="video.mp4" type="video/mp4">
</video>

Таким образом видос будет проигрываться автоматом и по кругу, как и гифка.
Если у тега <img>, в котором была прописана гифка, были какие-то атрибуты id или class — добавляем их к нашему новому тегу <video>, чтобы применились соответствующие стили.

Работа с видео

Иногда нам приходится встраивать в прокладки-лендинги видеоконтент. Но хранить большие видеофайлы у себя на хостинге — не самая здравая идея. Потому что стоит только десятку-другому юзеров зайти к вам на сайт и начать проигрывать контент… ваш сервер точно не скажет вам за это спасибо. Поэтому гораздо лучше размещать видео там, где это принято, т.е. на YouTube. И всё вроде бы хорошо: заливаешь туда свой видос, дальше нажимаешь кнопочку Share, выбираешь Embed, копируешь код iframe-а и вставляешь себе на сайт, так?

Так — да не так. Вы видели, сколько весят те скрипты, которые загрузятся пользователю, который зайдёт к вам на огонёк? Два, мать его, с половиной мегабайта! На некоторых гео, где у пользователей говёный интернет, эти 2.5Мб станут причиной того, что юзер не дождётся загрузки, плюнет и уйдёт.

И что же делать? Умные люди уже давно запилили скрипт под названием YTDefer, который более чем в 10(!) раз сократит размер подгружаемого контента (до 209Кб). Как это происходит? Весь прикол в том, что скрипт загрузит только заглавную картинку видоса, а весь остальной контент загрузится только после того, как пользователь кликнет на Play.

Офигенно же! Весьма рекомендую вам как минимум иметь в виду, что такое решение есть, и кинуть его себе в закладки, ведь никогда не знаешь, когда оно понадобится 🙃

Работа с CSS стилями

При изменении стилей мы с вами вступаем на довольно скользкую почву и тонкий лёд. Поэтому я сразу же хочу вас предупредить: во-первых, может быть вам ВООБЩЕ не стоит сюда лезть, ну его нахер. Ну а во-вторых — обязательно сделайте резервную копию тех стилей, что вы будете редактировать. Потому что что-то весьма вероятно может пойти не так!

Очистка

Если ваш лендинг использует какие-нибудь стандартные громоздкие библиотеки стилей типа: Bootstrap, FontAwesome и т.п., то скорее всего 90% этих библиотек не используется по назначению и лежит мёртвым грузом, да к тому же ещё и довольно сильно влияет на скорость загрузки.

Поэтому можно попробовать удалить всё лишнее, используя следующий сервис:

PurifyCss.Online — вставляем в поле слева полный код вашего index.html, а в поле справа по очереди вставляем все данные из каждого css-файла ленда. На выходе получаем объединённый и очищенный css-файл.

Обязательно проверьте работоспособность вашего лендинга, после того, как вы заменили все стили, что у вас были, на новый очищенный. На десктопе и мобильном телефоне, протыкайте все кнопки-ссылки и т.п. И вот тоооолько если ничего не сломалось — тогда можете смело удалить ставшие ненужными файлы.

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

Объединение

Если на вашем лендинге используется несколько файлов стилей, то их по-любому стоит взять и объединить! Для загрузки такого комбинированного стиля будет использован всего один HTTP-запрос, а не 2-3-4, что живительным образом отразится на отрисовке вашего лендинга.

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

Как объединять стили? Новый css-файл + операция Copy-Paste. Можете использовать команду: copy *.css new.css из командной строки.

Минификация

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

Копируем свой css, вставляем, жмём Minify, получаем сжатый, заменяем старый на новый — профит!

Preload

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

<link rel="preload" href="style.css" as="style" />
<link rel="preload" href="main.js" as="script" />

Заметили? Помимо того, что я в первой строке указал атрибут rel="preload" я ещё и дал подсказку браузеру, чтобы он знал, что именно он подгружает. В первом случае — это стиль. А вот во втором — это скрипт! Да-да, их тоже можно подгружать предварительно. Поэтому, если у вас на ленде, например, есть какие-то хитрые Javascript-меню, то можете попробовать подгрузить скрипт с таким меню заранее.

Подробнее почитать документацию про предзагрузку можно вот тут.

Работа со скриптами

Тут принцип примерно тот же, что и при редактировании стилей: не особо разбираетесь — плюньте. Не стоит оно того. И делайте бэкапы!

Объединяем

Если на вашем лендинге используется более 3-4 скриптов, то взять их и объединить в один-единственный — достаточно неплохая затея. Суть в том, что для загрузки такого комбинированного скрипта будет использован всего один HTTP-запрос, а не 3-4, что должно улучшить время загрузки.

Но только если у вас не какие-то там громадные скрипты на сотни килобайт! Если у вас именно такие (нахер они вам нужны на обычных арбитражных лендах, м?), то объединение в один файл наоборот ухудшит вашу ситуацию.

Как объединять? Да ну руками же. Создаёте новый файл и в него копируете контент всех имеющихся скриптов. Можете использовать команду: copy *.js new.js из командной строки.

Минифицируем и по желанию обфусцируем

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

Сайтов, позволяющих по-быстрому сжать Javascript-код пруд-пруди. Например, вот. Пользоваться элементарно: вставили код, нажали Minify, получили код, заменили старый новым.

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

CDN

Есть масса скриптов, которые арбитражники регулярно используют в работе. Не наших там каких-то чисто арбитражных, а общеизвестных. Самый распространённый — это JQuery. Есть ещё OwlCarousel, всякие маски номеров и т.п. Так вот, для того, чтобы ваш сайт грузился быстрее, не копируйте эти скрипты локально, а используйте их из CDN!

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

Короче говоря. Подключаем JQuery вот так:

<script src="https://code.jquery.com/jquery-3.6.1.min.js"></script>

Все прочие скрипты ищите вот на этих CDN, практически наверняка там есть всё, что вам нужно:

• Сdnjs
• Jsdelivr
• Unpkg

Defer и Async

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

Вариант №1

<script src="myscript.js" defer></script>

Вариант №2

<script src="myscript.js" async></script>

Добавляйте эти атрибуты ПОСЛЕДОВАТЕЛЬНО. Добавили первый — проверили полностью работоспособность скриптов: рулетка крутится, картинки скроллятся и т.п. Всё ок? Поменяли первый на второй и проверили снова. Какой лучше работает? Тот и оставляем.

Ставим скрипты в подвал

Просто запомните: лучшее место для ваших скриптов на лендинге — это НЕ ТЕГ <head> а подвал, т.е. самый конец кода, перед закрывающимся тегом </body>. Таким образом мы сначала загружаем весь-весь-весь текстовый контент и только потом отрабатывают скрипты.

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

Проверка изменений

После того, как вы применили какие-либо техники из указанных выше, было бы неплохо посмотреть: как сильно внесённые изменения повлияли на скорость загрузки вашего сайта? Помимо самого очевидного способа, про который я рассказал в разделе Хостинг, можно использовать следующие инструменты для проведения измерений:

Гугловский PageSpeed Insights — измеряет производительность отдельно для мобильной и десктопной версии сайта, показывает её в процентах от нуля до ста: чем больше тем лучше. Помимо всего прочего даёт кучу подсказок по поводу того, что и как подправить на сайте, чтобы он стал грузиться быстрее. Эталонный инструмент!

GTMetrix — канадский сервис, не сильно уступающий предыдущему (для доступа из РФ требуется VPN). Но по умолчанию тестирует сайт только под десктоп, для тестов с мобильного устройства потребуется приобрести подписку. Также даёт советы по поводу возможных улучшений.

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

Выводы

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

Пожелаю вам минимальных потерь трафика и, конечно же, лейте в плюс! А на связи был Жёлтый, до скорого.