Лучшие статьи и кейсы стартапов
Включить уведомления
Дадим сигнал, когда появится
что-то суперстоящее.
Спасибо, не надо
Вопросы Проекты Вакансии
Ускорение и защита сайта
Рекомендуем
Продвинуть свой проект
Лучшие проекты за неделю
26
Битрикс24

Битрикс24

www.bitrix24.ru

16
Отследить-посылку

Отследить-посылку

B2B-сервис трекинга посылок

14
myPreza

myPreza

mypreza.ru

13
WebResidentTeam

WebResidentTeam

webresident.agency

12
Perezvoni.com

Perezvoni.com

perezvoni.com

11
Expresso

Expresso

www.expresso.today

10
YAGLA

YAGLA

yagla.ru

10
Reader

Reader

Интернет-журнал о современных технологиях.

Показать следующие
Рейтинг проектов
Подписывайтесь на Спарк в Facebook

Компания Intuit ускорила сайт почти в 5 раз и увеличила конверсию на 20%

498 1 В избранное Сохранено
Авторизуйтесь
Вход с паролем
Продолжаем разбирать кейсы из серии "Как скорость сайта влияет на конверсию". Сегодня - история Intuit, которая добилась существенного ускорения сайта в результате двухэтапной работы.

Компания Intuit производит программное обеспечение для бизнеса в области финансов и бухгалтерии. Первая версия веб-сайта компании была выпущена в 1996 году, затем постоянно модифицировалась. Менялись разработчики и стандарты Web, сайт обрастал разными «заплатками» и дополнительным кодом. В 2012 году сайт компании стал загружаться ужасно долго — 15 секунд.Команде разработчиков была поставлена задача снизить на 50% время загрузки 50 топовых страниц на 6 разных сайтах компании.Типичная веб-страница представляла собой следующее:

  • Общий объем: 1,5-2 МБ
  • Изображения: 50-70+ штук, объемом порядка 1,2 МБ
  • Внешние CSS/JS: 30-40+
  • Объем Javascript: более 400 КБ
  • 30х-редиректы: более 20
  • HTTP-запросы: более 120

Начинаем с нуля

CSS/JS

Одно из базовых правил ускорения загрузки сайта: «минимизируйте http-запросы». Это оказалось не так просто сделать, поскольку на сайтах использовалось множество изображений и CSS/JS файлов. Многие файлы использовались и на других сайтах компании, некоторые стили были прописаны внутри страниц и не выделены в файлы. Присутствовали глобальные переменные и функции Javascript. Команда провела глобальную чистку CSS/JS, оптимизировала проходы по дереву документа DOM, создала глобальный файл стилей и скриптов, который использовался на всех сайтах. Были созданы несколько таких же файлов, которые использовались только на определенных сайтах.В итоге запросы, связанные с CSS/JS, сократились в 10 раз (с 30-40 до 3-4).

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

Основной частью работы было объединение изображений (спрайты), чтобы снизить количество http-запросов.В дизайне использовались изображения с прозрачностью (24-битовые PNG-файлы). Например, указанный ниже спрайт имел размер 306 КБ.

b_57b2ce323c598.jpg

Команда поработала с дизайнерами, убедила их отказаться от прозрачности в изображениях и перейти к использованию формата JPG. Это позволило сэкономить 250 КБ на таком спрайте (экономия более чем в 6 раз). Однако не всегда техника спрайтов помогала. На примере ниже показано сборное изображение для страницы с галереей скриншотов. Каждый скриншот – размером 102х768. Общий размер изображения – 5 МБ. Использовать спрайты нужно обдуманно!

b_57b2ce32e1df1.jpg

CDN

Сайты компании уже использовали Akamai. Кое-где были проблемы с конфигурацией, файлы загружали иногда с CDN, а иногда со своих серверов. Все сайты использовали одинаковый CDN-домен images.smallbusiness.intuit.com.Файлы cookie передавались при каждом http-запросе к этому домену. Средний размер cookie: 0,8-1 КБ. Умножаем на более чем 100 запросов на странице, получаем, что порядка 100 КБ трафика тратилось только на cookie.Проблему решили переконфигурированием Akamai. Все статические файлы стали загружаться с CDN, перешли на использование CDN-домена без cookie.

Тэги отслеживания

На сайте использовалось 20-30 различных тэгов (пикселей) отслеживания. Команда сайта поработала с маркетологами, все тэги отслеживания были проверены на необходимость их наличия, от многих отказались. Те тэги, которые остались, были заменены их последней актуальной версией, чтобы улучшить производительность.В итоге из 20-30 их количество удалось сократить до 8-10.

Другие виды оптимизации

  • Все изображения, не используемые в спрайтах, проверили на оптимальную компрессию.
  • Изображения, располагающиеся ниже первой видимой части страницы, стали загружаться позже, асинхронно.
  • Перестали использовать все нестандартные шрифты.
  • Удалили дублирующийся код.
  • Удалили 30х-редиректы.
Итоговая длительность всех работ по оптимизации составила 6 месяцев.
Результат: оптимизированные страницы стали загружаться за 6 секунд вместо 15.

Лучше, чем просто хорошо

Затем у руководства компании стали возникать вопросы: можно ли еще больше ускорить загрузку страниц. Перед командой оптимизаторов встала необычная проблема, поскольку основные шаги оптимизации они уже проделали на предыдущем этапе.Команда провела анализ всех других возможных узких мест и определила следующие источники проблем с загрузкой:
  • Программное обеспечение, ответственное за А/В-тестирование.
  • Проблемный проигрыватель видео.
  • Медленная шапка сайта.
  • Javascript: очевидная возможность его дальнейшей оптимизации.

Программное обеспечение А/В-тестирования

b_57b2ce3375fb2.jpg

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

b_57b2ce3465cc7.jpg

Данные запросы в сумме давали порядка 750 миллисекунд. То есть 3/4 секунды (из 6-ти), чтобы в большинстве случаев ничего не сделать для пользователя.Другая проблема, связанная с А/В-тестами, заключалась в их логике:
  • Всем пользователям загружался контент по умолчанию
  • Если пользователь попадал в категорию тех, на ком проводится А/В-тест, ему также загружался и тестовый контент, который он видел на экране вместо контента по умолчанию.
Сама архитектура А/В-тестов была порочной.

b_57b2ce3500c13.jpg

Контент на странице был организован следующим образом: контейнер div с именем класса, за которым располагался код Javascript, который обращался к серверу тестирования за нужным контентом. Если сервер тестирования определял, что этот пользователь участвует в А/В-тесте, и присылал другой контент, то код искал в DOM нужный div и вставлял в него измененный контент. Каждый такой код должен был пройти весь DOM, найти предстоящий перед ним div и вставить в него другой контент.Что в итоге было сделано:
  • Удален код, связанный с уже закончившимися тестами
  • Закомментированы неактивные пока тесты
  • Перешли на другое ПО для проведения А/В-тестирования

Проигрыватель видео

Проигрыватель видео, как оказалось, не только проигрывает видео, но еще и добавляет проблем. Вот как выглядит загрузка видеопроигрывателя на странице:
  • SWF-файл (сам проигрыватель) загружается за 6-8 секунд
  • Много внешних вызовов к разным аналитическим сервисам: 23 запроса, 9 доменов, 7 SWF-файлов
  • Статичная картинка, которую проигрыватель показывает, пока пользователь не нажал на проигрывание, занимает более 3 секунд загрузки
  • Пока статичная картинка не загрузится, страница блокируется и другие элементы не загружаются
Решение: заменили 3 разных проигрывателя видео на страницах на один, другого вендора.
Рекомендация: если по каким-то причинам вы не можете перейти на другой проигрыватель видео, хотя бы используйте технику «lazyload».

Общая шапка и меню

Проблемы были очень существенны, если учесть, что шапка загружалась на ВСЕХ страницах всех сайтов:
  • 2 обращения к А/В-тестированию
  • Спрайты вместо CSS
  • Javascript в событиях «mouseover»
  • Сотни отслеживаний событий (event listeners)
  • Более 1100 элементов DOM
Команда создала специальную пустую страницу, где загружалась только шапка с меню: эта страница грузилась 5 секунд.В итоге команда полностью переписала навигацию с использованием стандартов HTML/CSS/JS, минимизировала использование изображений и проходов по DOM, использовала делегирование событий.В результате, каждая страница стала загружаться на 1-1,5 секунды быстрее.

Использование библиотеки Control.js

Эта библиотека написана Стивом Сандерсом, и помогает разработчикам контролировать, как Javascript загружается и выполняется.Когда скрипт загружается через обычный тэг <script>.Команда использовала Control.js на некоторых страницах, но не на всех сайтах. Оказалось, что непросто управлять кодом, который отслеживал событие onload. Другая причина – не всем разработчикам известна эта техника, и возникли сложности с написанием ТЗ для сторонних разработчиков.

Предзагрузка ресурсов

Предзагрузка использовалась на страницах, связанных с конверсиями различных типов, когда заранее известно, какая будет следующая страница, куда перейдет пользователь.Пока пользователь бездействует, либо вводит свои данные в форму, ресурсы следующей страницы загружаются в фоне. Когда пользователь попадает на следующую страницу, ее ресурсы уже находятся в кэше, что позволяет показать страницу очень быстро.Команда также оптимизировала ряд других моментов: переписали много Javascript-кода, увеличили использование «lazy load», где-то изменили инфраструктуру и перешли на более быстрый стек.

Итоговые результаты

  • В феврале 2012 года типичная страница «весила» 1,2 МБ и загружалась 15 секунд.
  • По окончании процесса оптимизации в апреле 2013 года типичная страница «весила» 400 КБ и загружалась за 3,6 секунды.
Визуально страницы практически не отличались.

b_57b2ce35753b6.jpg

Влияние на бизнес

Команда отмечает, что достаточно тяжело измерить влияние всего этого процесса, потому что он длился более года. За это время компания внедряла множество других изменений: в предложениях, тарифных планах, продуктах.Однако в конкретных изолированных периодах времени, когда единственным изменением было изменение скорости загрузки, регистрировались улучшения конверсии. Например, на 14 неделе 2012 года, когда единственным изменением было ускорение загрузки страницы с 9-12 секунд до 5-6 секунд, конверсии выросли на 14%.

b_57b2ce362bfad.jpg

Как скорость влияет на конверсию

Влияние на конверсию команда свела к следующей итоговой формуле. Каждое уменьшение времени загрузки страницы на 1 секунду дает следующее влияние:
  1. Если страница загружается за 7 секунд или более: +3% за каждую секунду ускорения
  2. Если страница загружается от 5 до 7 секунд: +2% за каждую секунду
  3. Если страница загружается менее чем за 5 секунд: +1%.
Примечание: важно помнить, что это результаты 2013 года. С тех пор и 5 секунд загрузки страницы стали достаточно долгим временем.
+3
Добавить в избранное Сохранено
Авторизуйтесь
Вход с паролем
Первые Новые Популярные
FriendHelp
Проект построен на «Теории 6 рукопожатий» и «Концепции слабых связей».
Выбрать файл
Читайте далее
Загружаем…
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать