-Поиск по дневнику

Поиск сообщений в predefglas

 -Подписка по e-mail

 

 -Статистика

Статистика LiveInternet.ru: показано количество хитов и посетителей
Создан: 10.12.2014
Записей:
Комментариев:
Написано: 94

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

Дневник

Пятница, 17 Июня 2016 г. 19:08 + в цитатник
Это второй кейс из серии «Как правильно ускорить сайт, и что это дает». Полный список кейсов мы публиковали здесь. В этом кейсе поучительно, как команда разработки договаривалась с другими подразделениями бизнеса, чтобы реально ускорить сайт. Компания 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 КБ. Команда поработала с дизайнерами, убедила их отказаться от прозрачности в изображениях и перейти к использованию формата JPG. Это позволило сэкономить 250 КБ на таком спрайте (экономия более чем в 6 раз). Однако не всегда техника спрайтов помогала. На примере ниже показано сборное изображение для страницы с галереей скриншотов. Каждый скриншот – размером 102х768. Общий размер изображения – 5 МБ. Использовать спрайты нужно обдуманно! 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: очевидная возможность его дальнейшей оптимизации. Программное обеспечение А/В-тестирования Как видно на указанной выше картинке, на странице существовала череда блокирующих вызовов: каждый следующий ждет завершения предыдущего и без этого не стартует. Всякий такой вызов шел к серверу, ответственному за тестирование, а сервер уже определял, должен ли данный пользователь «попадать» в определенный А/В-тест, если да – то ему в определенном месте показывался другой контент. Многие пользователи при этом не попадали ни в какой тест. Данные запросы в сумме давали порядка 750 миллисекунд. То есть 3/4 секунды (из 6-ти), чтобы в большинстве случаев ничего не сделать для пользователя. Другая проблема, связанная с А/В-тестами, заключалась в их логике: Всем пользователям загружался контент по умолчанию Если пользователь попадал в категорию тех, на ком проводится А/В-тест, ему также загружался и тестовый контент, который он видел на экране вместо контента по умолчанию. Сама архитектура А/В-тестов была порочной. Контент на странице был организован следующим образом: контейнер 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 секунды. Визуально страницы практически не отличались. Влияние на бизнес Команда отмечает, что достаточно тяжело измерить влияние всего этого процесса, потому что он длился более года. За это время компания внедряла множество других изменений: в предложениях, тарифных планах, продуктах. Однако в конкретных изолированных периодах времени, когда единственным изменением было изменение скорости загрузки, регистрировались улучшения конверсии. Например, на 14 неделе 2012 года, когда единственным изменением было ускорение загрузки страницы с 9-12 секунд до 5-6 секунд, конверсии выросли на 14%. Как скорость влияет на конверсию Влияние на конверсию команда свела к следующей итоговой формуле. Каждое уменьшение времени загрузки страницы на 1 секунду дает следующее влияние: Если страница загружается за 7 секунд или более: +3% за каждую секунду ускорения Если страница загружается от 5 до 7 секунд: +2% за каждую секунду Если страница загружается менее чем за 5 секунд: +1%. Примечание: важно помнить, что это результаты 2013 года. С тех пор и 5 секунд загрузки страницы стали достаточно долгим временем.
[Перевод] Руководство по работе с Redux

Метки:  

Моя эпичная история настройки целей сайта на Битриксе

Дневник

Понедельник, 16 Мая 2016 г. 01:23 + в цитатник
Друзья, любите ли вы настройку целей так как «люблю» её я? Для меня это дело всегда непростое и муторное, в интернетах почти нет информации об этом, а тема, на мой взгляд, важная. Сегодня мой пост посвящается настройке целей сайта на Битриксе, если пост понравится, то расскажу про другие CMS 1.1. На кой вообще нужны цели на сайте? Цели необходимо настроить, чтобы не просто смотреть на график посещаемости, а понимать какой канал является эффективным, а какой нет. Приведу цитату из справки Google: “Цели являются отличным индикатором эффективности работы вашего сайта или приложения. Целью может быть любое действие, в котором вы заинтересованы, называемое конверсией. Вот некоторые примеры целей: покупка (для сайта электронной торговли), прохождение уровня игры (для мобильного игрового приложения), отправка контактной информации (для сайта по привлечению клиентов). Определение целей – важнейший компонент планирования аналитической оценки. Правильно выбранные цели позволяют получать важную информацию, такую как количество конверсий и коэффициент конверсии для сайта или приложения. Без этих сведений практически невозможно оценить эффективность онлайн-бизнеса и маркетинговых кампаний.” support.google.com/analytics/answer/1012040?hl=ru Настраивайте только те цели, которые действительно будете анализировать и отслеживать. Например, регистрация, отправка контактных данных, запрос обратного звонка и другие действия, которые потенциально ведут к продаже можно считать целями. Цель, которая срабатывает в момент просмотра посетителем двух страницы, либо пребывании на сайте более трёх минут, на самом деле целями не являются." 1.2. Какими бываю цели? Основные цели — покупка товара — отправка контактных данных — звонок Вспомогательные цели -просмотр карточки товара -просмотр контактов -просмотр 3 страниц 1.2. Нууу… у меня есть счётчики, зачем мне ещё цели? Несмотря на то, что у вас настроены счетчики статистики, они не смогут отследить все. Сервисы отслеживают в основном просмотры страниц. А самое вкусное остаётся за бортом, например клики, отправки форм, и другие более сложные события (например, “регистрация на сайте, подтвержденная по е-майл”) Итак, на рисунке мы видим, что “просмотры страниц” сразу отправляются в аналитику, и тут все в порядке “клики, отправки форм” можно отследить с помощью Google Tag Manager. На практике не всегда просто настроить отслеживание валидной отправки формы. “сложные события” — это то, что не удается отследить с помощью предыдущих средств. Для их отслеживания в код сайта в нужные места внедряются небольшие коды java script, которые и отправляют необходимую информацию в аналитику. Хочется отметить, что для каждой системы, которой необходима информация о свершении цели, необходимо вставить свою команду в код. И тут нас ждёт опасность: после того как уже все настроено, отлажено и проверено появляется необходимость отправлять данные куда-нибудь еще. И чтобы это сделать придется пройтись везде, где мы уже вставляли коды. Другими словами, сделать всю работу два раза. Именно в этом случае нам на помощь приходит Google Tag Manager. 1.3. Зачем нужен Google Tag Manager? Установка только одного кода, все остальные МОЖНО НУЖНО установить через него. — Позволяет отслеживать клики, клики по ссылкам, отправку форма и др. — Позволяет создавать собственные правила, чтобы вызывать нужные коды в нужное время. — Позволяет отправлять данные о достижении целей куда угодно. Благодаря Tag Manager вырисовывается более удобная и правильная схема настройки целей: Этот способ позволяет масштабировать проделанную вами работу на любые системы, в которых нужны данные о достижении ваших целей. 1.3.1. Как правильно установить Google Tag Manager? Единственно правильный путь — установка после открывающего тега body и не включая его ни в какие другие блоки. Тогда код будет срабатывать сразу. А все что нужно активировать по окончании сборки модели DOM или когда страница загрузится полностью можно легко настраивать правилами Tag Manager 1.3.2. Что обычно устанавливают через GTM? Все сторонние коды, например: — Коды счетчиков GA, YM — Доп сервисы UpToCall, Jivosite и т.п. — Коды ретаргетинга для соцсетей. и тд и тп 1.4. Какой код надо вставить на сайт для отслеживания достижения целей? Команды, которые нужно вставить очень просты 2. Настройка целей в Битрикс Честно, я бы все формы на сайте реализовал через «навесные сервисы», проблем было бы меньше. На нашем сайте стоит обработчик JotForm adverbs.ru/feedback и я вслепую могу настроить все цели. На CMS же все формы всегда реализованы по-разному и иногда, простите, не через то место :-) Здесь я постараюсь по шагам описать процесс настройки нескольких целей на примере реального проекта. Сразу скажу, что я не являюсь программистом на Битрикс. Если в моих словах ниже будут ошибки в терминологии или предложенных вариантах решения просьба не закидывать меня помидорами, а подсказать или поправить в комментариях. Буду мегаблагодарен :-) 2.1. Определимся со списком целей Прежде чем приступать к настройке целей необходимо определиться с самими целями. Не поленитесь и составьте список целей с их названием, описанием, ссылками, скриншотами и комментариями. Уверяю через месяц вы уже не вспомните что и зачем делали. После нескольких десятков итераций наш файл целей выглядит так: Забегая вперед скажу, что Google Tag Manager позволяет отслеживать много разных событий без правки кода сайта. Однако на практике все таки много целей приходится настраивать, добавляя дополнительные коды в исходный код сайта. 2.2. Куда в битрикс вставлять код? На каждом сайте и в каждой CMS это придется делать в разных местах. Если вы ничего не понимаете в программировании, то вам точно нужен программист. Более того скажу, что даже для любого сайта, написанного на Битрикс, скорее всего вам придется вставлять коды в разные места. И даже для разных форм одного и того же сайта это будут различны места, особенно если над сайтом колдовали и шаманили несколько программистов в разное время :) Так приступим же, друзья, к практике:-) Разбирать будем на примере “живого” проекта a-tria.ru. Цели, описанные в таблице выше, как раз для него. Входим в админку сайта. 2.3. Настройка цели “Заказать звонок” 2.3.1. Вставка кода цели “Заказать звонок” Цель должна срабатывать НЕ при клике на кнопку, а при успешной отправке данных формы. Обычно, если какая то часть сайта представляет собой компонент, то при наведении на нее курсора мыши появляется всплывающее меню. Как на картинке ниже. Но при наведении на форму заказа звонка ничего не появляется, значит можно предположить, что форма каким-то образом “зашита” в шаблон сайта. Открываем для редактирования шаблон сайта. Находим в нем текст “Заказать обратный звонок” И видим, что ссылка открывает страницу по адресу /modal-forms/call-back/ Ну что ж, заглянем туда Здесь мы видим что в шаблон этой страницы включен компонент z-labs:ajax.call_order Его можно найти вот по этому пути: /bitrix/components/z-labs/ajax.call_order Но то, что нам нужно нашлось в шаблоне этого компонента чуть глубже, вот тут: /bitrix/components/z-labs/ajax.call_order/templates/call-back/template.php После просмотра файла было найдено место, где выводится сообщение об успешной отправке формы. Рядом с ним мы и вставили код, который отправляет данные о свершении целевого действия: yaCounterXXXXXXXX.reachGoal(‘forms_zvonok’);, где XXXXXXXX- номер вашего счетчика Яндекс метрики forms_zvonok — идентификатор цели в вашей Яндекс метрике. Более подробная информация о передаче информации о достижении цели в Яндекс метрику: yandex.ru/support/metrika/objects/reachgoal.xml ga(‘send’, ‘event’, ‘forms’, ‘zvonok’); , где ‘event’ — типа обращения ecent указывает, что мы отправляем в аналитику событие ‘forms’ — категория, ‘zvonok’ — действие на которое настроены цели в вашей аналитике. Более подробная информация об отслеживании событий в Google Analytics: developers.google.com/analytics/devguides/collection/analyticsjs/events?hl=ru 2.3.2. Настройка цели “Заказать звонок” в Google Analytics В Google Analytics переходим во вкладку “Администратор” > “Цели” — Указываем, что цель будет “Специальная”. — Указываем название: “Обратный звонок” и тип цели “Событие”. — Указываем подробные сведения о цели. Категория “forms”, Действие: “zvonok” 2.3.3. Настройка цели “Заказать звонок” в Яндекс метрике В яндекс метрике процесс настройки цели не менее простой. Заходим в раздел “Настрока” > “Цели” Указываем “Название”: “Обратный звонок”, Тип условия: “JavaScript событие”, идентификатор цели: “forms_zvonok” 2.4. Настройка цели “Форма участвовать в акции” 2.4.1. Вставка кода цели “Форма участвовать в акции” Редактируем шаблон Текст “Участвовать в акции” нашли, но тут нет ссылок как в прошлый раз. Возможно нажатие обрабатывается подключаемым скриптом. Посмотрим, что подключается к этому файлу: Помимо стандартных скриптов, подключается какой-то script.js Здесь мы находим определение функции, которая будет срабатывать при клике на элемент с классам “callbutton”. Именно этот класс установлен на нужной нам кнопке. Ниже видим код отвечающий за отправку сообщения. Вставляем код, который отправляет данные о достижении цели. 2.4.2. Настройка цели “Форма участвовать в акции” в Google Analytics и Яндекс метрике Аналогичным образом добавляем цели в Яндекс и Гугл. В Яндекс метрике идентификатор цели “forms_akciya”, в гугл аналитике событие с идентификаторами “forms”, “akciya” 2.5. Как понять что код отправляет данные? Думаю, что любой программист скажет вам, что невозможно писать код, если у вас нет средств отладки. Далеко не все знают про это, но средства отладки есть и здесь. 2.5.1. Отладка в Яндекс.Метрике Для того, чтобы увидеть отправляются ли данные в Яндекс.Метрику вам необходимо в адресной строке браузера ввести адрес сайта, на котором вы настраиваете цели и добавить параметр отладки: www.site.ru/?_ym_debug=1 Открыть инспектор кода, вкладку “Console”. Когда вы совершите на сайте целевое действие, то увидите сообщения о том что данные отправляются. 2.5.2. Отладка в Google Analytics В Google Analytics немного иной способ проверить отправляются ли данные в аналитику. Для этого есть отчеты в “режиме реального времени”--> “События” Просматривая этот отчет, мы практически в ту же секунду увидим визуальное отображение при совершении целевого действия на сайте. Если его нет, значит что-то не так. 2.5.3. Отладка в Google Tag Manager Невероятно, но факт, в GTM также есть система отладки, причем достаточно неплохая. В интерфейсе рядом с кнопкой “Опубликовать” жмем на стрелочку. В открывшемся меню выбираем “Предварительный просмотр и отладка”. После перехода в режим отладки, в том же браузере нужно открыть сайт, для которого вы настраиваете цели. В этом же окне откроется отладочная панель GTM Здесь вы увидите все события, которые фиксирует Google Tag Manager, а также какие теги были активированы на эти действия. 3. Вместо послесловия... Мы разобрались с общей правильной схемой настройки целей и разобрали по шагам пример настройки двух целей реального проекта. Напоследок хочу дать несколько советов: — Делайте все постепенно, после каждого шага проверяя, что все сделано правильно и работает. — Идентификаторы для целей гугл и яндекс делайте одинаковые, с идентичным написанием. Если идентификатор для яндекс “forms_zvonok”, то для гугл идентификаторы должны быть “forms”, “zvonok”, иначе это приведет к путаннице. — Давайте понятные названия для целей, т.е. названия должны быть такие, чтобы любой человек посмотрев на них мог вам сказать что это за цели. Например, если цель срабатывает при отправке формы “заказать звонок”, то пусть название будет “Форма — Заказать звонок”. Если же цель срабатывает при нажатии на кнопку “Заказать звонок”, и не важно отправил он форму или нет, то назовите цель “Кнопка — Заказать звонок”. Либо придумайте любой другой понятный принцип именования. — Используйте только латинские маленькие буквы и знак подчеркивания в названии идентификаторов. Так будет меньше шансов ошибиться в написании и вы не потратите лишние пару часов на поиск багов. — Обязательно запишите все что вы сделали, например в таблицу настройки целей — Сначала лучше сделать меньше, но чтобы это четко работало, чем много, но работающее через раз и непонятно как. PS: буду благодарен за любые комментарии :-)

Метки:  

 Страницы: [1]