| Практика разгона одностраничников для CPA Добрый день, уважаемые дамы и господа. Сегодня я немного вам расскажу про партнёрский маркетинг – CPA, который активно стал расцветать в Рунете. Хотя для России этот бизнес относительно молодой в сравнении с Западными сегментом рынка электронной коммерции, но по мнению большинства русскоязычных SEO специалистов на данный момент CPA = CostPerAction = оплата за действие смело можно назвать одним из самых перспективных на данный момент видов заработка для веб-мастеров в Интернете. Если коротко, то заработок в CPA-партнерках строится на принципе получения определенного вознаграждения за конкретные действия пользователей, которые перешли на лендинг-пейдж по вашей партнерской ссылке, которую вы продвигаете различными доступными эффективными способами рекламы, начиная от контекста и заканчивая CPA-дорвеями. Среди самых распространённых схем слива трафика в CPA можно выделить две: прямо на оффер или через прокладку(она же простыня, лендинг пейдж, одностраничник или sales-letter) на оффер. Размеры у одностраничников бывают разные – короткие или длинные, но цель одна чтобы целевой посетитель перешёл на наш оффер и совершил, то действие которое нам надо и за которое партнёрка платит вознаграждение. С короткими страницами приземления проще, чем с длинными, так как с последними имеется парочка узких мест, которые надо регулярно оптимизировать для того, чтоб конверт был выше – первое это поведенческие факторы, которые напрямую влияют на баунсрейт лендинга(причина - не каждый прокручивает скроллинг до конца «простыни» и получается страница не целиком просматривается посетителями, а нам как раз нужно наоборот, как можно большее число пользователей прокручивающих sales-letter до конца, иначе все наши усилия псу под хвост) и второе скорость загрузки самой страницы, которая важна не только посетителям, которым подчас надоедает долго ждать загрузки всех многочисленных графических изображений, которыми перенасыщенны одностраничники, но и сами поисковые системы тоже рьяно к этому относятся, ставя фактор скорости загрузки HTML-страницы, как один из немаловажных факторов релевантности в СЕРЧЕ. Если с первым проще, статей на тему - Поведенческие факторы: «с чем их едят и чем приправляют»? – полно в Интернете, то о втором пункте – оптимизации времени загрузки одностраничников сегодня мы с вами и поговорим. Прежде всего напомню, что есть так называемая зона первого экрана, которая у каждого пользователя пришедшего к нам на сайт будет разная, но ни у одного из них не будет загружена страница на всю свою длину, поэтому многие кто заинтересуется предложением должны будут проскроллить страницу вниз, так пользователи увидят второй экран и т.д. Почти, как уже год Google стал отслеживать скорость не всей загруженной страницы, а стал отдавать приоритет отдельной загрузки первого экрана и далее полной загрузки. Тут стоит упомянуть о новом термине, как TTI - time to interact, это период времени, который необходим для загрузки основных элементов первого экрана WEB-страницы и старта визуального взаимодействия пользователя с нашим коммерческим предложением, при этом может быть только загружена ещё часть 65-75% всего одностраничника, но мы уже вовлекаем пользователя своей воронкой продаж. Если вы обратите внимание на эту инфографику, то увидите визуально всё то о чём я написала Теперь надо как вы поняли помимо улётной крейсерской скорости, по новым критериям Google дополнительно иметь ещё высокую стартовую скорость, как практически в мире автомобилей, все любят бахвалиться тем за сколько секунд его ласточка разгоняется до 100 км/час, а уже после сообщают так невзначай, что по спидометру можно выжать 300-320 км/час. Вот практически и с HTML-страницами у нас должен быть подобный подход – среднее время разгона до 100% первого экрана колеблется в районе 4-5 секунд, а на полную загрузку всего, не важно какой длины, одностраничника общее время должно быть в рамках 8-9секунд. Теперь собственно вопрос – как форсировать наш образный движок одностраничника до такой немыслимой скорости TTI? Ответ - это отложенная визуализация контента - путём покадровой загрузки страницы, не надо в ущерб себе загружать первыми интерактивные элементы страницы, к примеру ЯВА-скрипты, которые на странице начинают отрабатывать последними, их же можно отложить до окончательного момента загрузки страницы, такой оптимизацией можно реально ускорить время и выиграть те драгоценные секунды, для того чтобы наши лендинг пейдж летали на сверхзвуковой, чем у конкурентов. Теперь практический пример – я нашла в Google, на данный момент один из популярных одностраничников по Форекс-тематике, который как раз соответствует всему тому, что я описала. На самом одностраничнике размещено 13 картинок, текстовка, а внутри при загрузке отрабатывают более десятка Java-скриптов. Прям скажу удачный одностраничник-серядничок, то что Google прописал. Почему именно на нём я остановилась? Главная причина это то, что при загрузке этого лендинга я увидила вот что. Все картинки, кроме первого экрана загружаются покадрово, не сразу! Думаете это мой 8Мбит/с канал глючит, как бы не так. Браузер, увы опять мимо – пробовала и на Хроме, Опере и Мозилле, один и тот же результат, вот Интернет эксплорер мульку с картинками не сечёт? Как дотошный исследователь, я полезла в дебри HTML-страницы конкретно выявить, какой скрипт отвечает за такую покадровую загрузку изображений на странице и нашла этого виновника торжества, им оказался скрипт - load.image.js, вот его код
Скрытый текст (вы должны войти под своим логином или зарегистрироваться и иметь 33 сообщение(ий)): У вас нет прав чтобы видеть скрытый текст, содержащийся здесь. | как видите тут ничего сложного – всё сводится к отслеживанию скроллинга пользователем и когда идёт скроллинг вниз подгружается очередная картинка и так до конца страницы. Сколько на этом можно съэкономить времени, вот смотрите первый экран загрузился за 0,931 секунды, а весь одностраничник закончил свой рендеринг за 4,185 секунд! Шустро, не то слово. Копаем дальше, как замерить скорость загрузки страницы и узнать какой когда элемент рендерится и сколько на это уходит времени? Я для этого использую бесплатный сервис - webpagetest.org. Тут всё просто на главной странице сервиса в адресной строке указываю адрес подопытной WEB-страницы можно поиграться с опциями – изменить реферрер браузера и свою геолокацию, далее нажимаем на – Старт тестирования. Через несколько секунд, всё зависит от объёма HTML-странички мы увидим детальный отчёт со всем спектром компонентов как видите скрипт - load.image.js подгружается третьим и т.д., но пробежавшись по листингу всех файлов я не нашла в списке самих изображений, которые так специфично загружаются: image2, image3, image4, image5, image6, image7 и т.д. Значит мои домыслы верны – одностраничник загружен полностью на 100 процентов со всеми необходимыми скриптами и стилями, но изображения которые расположены на странице ниже первого экрана нет – они последовательно слайсятся(способ передачи определённой части трафика/контента) только в тот момент когда начнёт выполнять свою функцию скрипт - load.image.js. Это и логично - пользователю как бы ни к чему то что скрыто в данный момент за границами расширения экрана, а поисковикам тем более. Казалось на этом можно остановиться, но чтобы успокоить себя окончательно, что с моей стороны для оптимизации скорости загрузки sales-letter сделано всё возможное и невозможное, перепроверим в этом же сервисе выбрав вкладку – Performance review и получаем отчёт о возможных векторах дополнительной работы над WEB-страницей, к примеру что-то надо закешировать или заархивировать и т.д. Дополнительно приведу список аналогичных сервисов для тестирования скорости ваших сайтов: • webwait.com • linkvendor.com/seo-tools/speedtester.html • iwebtool.com/speed_test • selfseo.com/website_speed_test.php • whichloadsfaster.com • websiteoptimization.com/services/analyze • developers. google.com/speed/pagespeed/insights Успехов, вам. |
Спасибо сказали: | 13й(29.04.2014), 4axvan4i(18.04.2014), Ailton(03.03.2014), aldruhn(18.04.2014), ArhStrAngeR(16.04.2014), bljaher(03.03.2014), bortnovsky(03.03.2014), dikobraz(29.04.2014), dima67(06.03.2014), DOleg(03.03.2014), Elka(02.09.2014), feuer81(27.04.2014), Fringer(03.03.2014), GOODPower(29.04.2014), HelgerLEE(17.04.2014), ishipilov(23.04.2014), janissary(18.04.2014), JumJum(15.06.2014), kajona(18.04.2014), kvk000(18.04.2014), liveman(15.04.2014), Logan(24.04.2014), maxim324(28.04.2014), MetalMessiah(20.04.2014), mrstorm(23.04.2014), netactor(19.04.2014), ogonek(18.04.2014), PavelDrum(09.04.2014), seoalb(03.03.2014), ShadowCaster(03.03.2014), Skoba(25.04.2014), SPIELER-x(18.04.2014), sprigan(27.04.2014), STRIJ(16.04.2014), Tiberis(03.03.2014), tolev(29.04.2014), torres15(15.04.2014), Translit13(06.03.2014), Valerevna(18.04.2015), Vitaxxxa(03.03.2014), web-search(02.04.2014), Webrumors(29.08.2014), winter(22.03.2014), zhurik(30.03.2014), Дмитрий Талалай(06.03.2014), Думка(02.04.2014), Скив(22.04.2014), Уфимец(28.04.2014), | |