Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 83
Ах он сука такой, значит, до этого замедлял?! :)
Ну как минимум, он скачивал свой 24кб ga.js во время загрузки страницы, теперь он это может делать после…
Но после первой загрузки, он обычно закэширован надежно и на всех остальных сайтах используется один и тот же :)
Но после первой загрузки, он обычно закэширован надежно и на всех остальных сайтах используется один и тот же :)
Дык, проинформируйте нас в тексте статьи. Я думаю, многим здесь интересно знать, что изменится.
24 кило не 1.5 метра:)
если критично — всегда можно выкачать ga.js к себе на сайт и скармливать это кэшу, периодически обновляя его (ga.js) по cron-у
да и в htaccess можно пихнуть
чтоб на подольше хватало:)
но раз можно с обходом по флангу, то значит так веселее
если критично — всегда можно выкачать ga.js к себе на сайт и скармливать это кэшу, периодически обновляя его (ga.js) по cron-у
да и в htaccess можно пихнуть
<FilesMatch "\.(js)$"> Header set Cache-Control "max-age=290304000, public" Header unset Last-Modified </FilesMatch>
чтоб на подольше хватало:)
но раз можно с обходом по флангу, то значит так веселее
Всем похуй.
Прошу прощения за ламерский вопрос, а код на страницах надо менять?
Да.
Вот этот, меняете на тот что вверху
Старый код будет работать как и до этого, это просто асинхронная версия.
Вот этот, меняете на тот что вверху
<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript">
try{
var pageTracker = _gat._getTracker("UA-xxxxxx-x");
pageTracker._trackPageview();
} catch(err) {}</script>Старый код будет работать как и до этого, это просто асинхронная версия.
Эээ, а Яндекс в СНГ поисковиках отсутствует? о_О
переехал ;) спасибо
На самом деле, старый вариант не так уж и тормозит загрузку, т.к. сам гугл советут вставлять код в конце страницы, перед , тем более ещё и кэширование.
Ухты какой изящный способ подключения библиотек. Вроде так просто создать скрипт типа:
useLib("/js/jquery.js");
А он загрузит библиотеку…
И ведь простая идея, не надо 50 разных строчек в заголовке страницы писать.
useLib("/js/jquery.js");
А он загрузит библиотеку…
И ведь простая идея, не надо 50 разных строчек в заголовке страницы писать.
Развею несколько мифов относительно этого «улучшения»:
1) Как GA замедлял загрузку страницы, так и будет продолжать замедлять. «Из воздуха» скачиваться ничего не будет, пользовательский канал будет так же забит
2) Этот скрипт не добавляет загрузку GA после загрузки страницы. Он просто по-другому вызывает библиотеку.
3) Еще раньше (последние года два точно) GA «не замедлял» загрузку, ибо в нем нет document.write (картинка-счетчик вставляется через new Image())
4) Если раньше можно было запихнуть GA перед и забыть о нем, то теперь предлагается такое «псевдо»-улучшение. Что оно делает? Создает отдельный поток в браузере, загружающий скрипт и вставляющий его в head. Поток этот блокирует загрузку остальных ресурсов (т.е. у браузера несколько потоков, один будет занят GA вместо того, чтобы картинки, например, загружать). Если же вставлять этот код перед </body>, то он будет работать абсолютно аналогично предыдущему (тогда спрашивается, зачем вообще это «улучшение» нужно).
5) Более того, если сейчас все ломанутся вставлять этот вызов в head, то загрузка этих сайтов замедлится (в силу п.4). Т.е. такое «улучшение», на самом деле, не повысит скорость загрузки GA на сайтах, но увеличит точность счетчика (на это постоянно идет ругань, возможно, потому что GA тупо не успевает загрузиться). Но скорость загрузки страницы это понизит.
Такое вот «улучшение». Сухой остаток: либо у вас страница быстро загружается, либо точно считается при помощи внешних счетчиков. Третьего не дано (т.е. лучше всего считать внутренними серверными, конечно, но они не все могут). А еще лучше — сделать загрузку страницы настолько быстрой, что даже загрузка GA после нее будет происходить для всех пользователей.
1) Как GA замедлял загрузку страницы, так и будет продолжать замедлять. «Из воздуха» скачиваться ничего не будет, пользовательский канал будет так же забит
2) Этот скрипт не добавляет загрузку GA после загрузки страницы. Он просто по-другому вызывает библиотеку.
3) Еще раньше (последние года два точно) GA «не замедлял» загрузку, ибо в нем нет document.write (картинка-счетчик вставляется через new Image())
4) Если раньше можно было запихнуть GA перед и забыть о нем, то теперь предлагается такое «псевдо»-улучшение. Что оно делает? Создает отдельный поток в браузере, загружающий скрипт и вставляющий его в head. Поток этот блокирует загрузку остальных ресурсов (т.е. у браузера несколько потоков, один будет занят GA вместо того, чтобы картинки, например, загружать). Если же вставлять этот код перед </body>, то он будет работать абсолютно аналогично предыдущему (тогда спрашивается, зачем вообще это «улучшение» нужно).
5) Более того, если сейчас все ломанутся вставлять этот вызов в head, то загрузка этих сайтов замедлится (в силу п.4). Т.е. такое «улучшение», на самом деле, не повысит скорость загрузки GA на сайтах, но увеличит точность счетчика (на это постоянно идет ругань, возможно, потому что GA тупо не успевает загрузиться). Но скорость загрузки страницы это понизит.
Такое вот «улучшение». Сухой остаток: либо у вас страница быстро загружается, либо точно считается при помощи внешних счетчиков. Третьего не дано (т.е. лучше всего считать внутренними серверными, конечно, но они не все могут). А еще лучше — сделать загрузку страницы настолько быстрой, что даже загрузка GA после нее будет происходить для всех пользователей.
Ждал появления sunnybear :)
«увеличит точность счетчика»
Улучшение всё-же есть ;)
«увеличит точность счетчика»
Улучшение всё-же есть ;)
чета Вы перемудрили в п.4.
Например FF выделяет по несколько потоков на домен. Таким образом картинки будут продолжать грузиться точно в стольки же потоках, так как GA грузится с другого домена
Например FF выделяет по несколько потоков на домен. Таким образом картинки будут продолжать грузиться точно в стольки же потоках, так как GA грузится с другого домена
о-да. Я и перемудрил :)
Любой браузер выделяет ограниченное число потоков (пруфлинк) на загрузку (причем, скорее всего, они делятся еще и между вкладками, надо бы проверить) сайта. Если у нас 1 поток занят, то это приводит (в зависимости от браузера) к разного рода последствиям: загрузка становится медленнее на 3-25%.
Любой браузер выделяет ограниченное число потоков (пруфлинк) на загрузку (причем, скорее всего, они делятся еще и между вкладками, надо бы проверить) сайта. Если у нас 1 поток занят, то это приводит (в зависимости от браузера) к разного рода последствиям: загрузка становится медленнее на 3-25%.
да — бедный файрфокс, который гружит в 6 потоков с домена и в 30 потоков вообще, очень замедлит загрузку страницы, если одн поток будет отдан другому домену, при этом еще 29 (не считаем другие вкладки) будут распределены на другие домены. таким образом, что бы скрипт GA повлиял на скорость загрузки, картинки и прочие ресурсы должны грузиться с еще 5 доменов сразу же и в колличестве не менее 6 штук с каждого.
не берем в расчет размеры ресурсов, так как в таком случае освобождение стека, который мог бы быть занят загрузкой картинки, а не GA будет еще медленнее, а значит влияние загрузки GA будет еще меньше.
тут даже о 3% речь идти не может
не берем в расчет размеры ресурсов, так как в таком случае освобождение стека, который мог бы быть занят загрузкой картинки, а не GA будет еще медленнее, а значит влияние загрузки GA будет еще меньше.
тут даже о 3% речь идти не может
1 поток = 3% скорости загрузки (при 30 потоках). Что здесь не верно?
Картинки, в среднем, меньше 30 Кб GA, так что занятие потока весьма ощутимо.
Также не забываем про IE, у которого с потоками вообще полный бардак (в версии 8 хоть немного разгребли).
Картинки, в среднем, меньше 30 Кб GA, так что занятие потока весьма ощутимо.
Также не забываем про IE, у которого с потоками вообще полный бардак (в версии 8 хоть немного разгребли).
неверно то, что эти 3% проявились бы, если бы все ресурсы грузились в этих 30 потоках с любого домена.
представим ситуацию.
есть сайт. у сайта есть CSS, JS и картинки. каждый тип ресурса лежит на своем поддомене:
css.site.com
js.site.com
imgs.site.com
пусть каждого типа ресурсов — 10 штук.
пользователь открывает страницу. создается 18 потоков и начинает грузиться 6 стилей, 6 сриптов и 6 картинок. еще 12 потоков простаивает. вообще. простаивает.
добавляем еще подгрузку GA:
пользователь открывает сраницу. создается 19 потоков и начинает грузиться 6 стилей, 6 скриптов, 6 картинок и 1 GA.
Где тут замедление? Можете экстраполировать эту логику далее, что бы понять что загрузка 1 скрипта малого размера с отдельного домена в современных браузерах рояля практически не играет
представим ситуацию.
есть сайт. у сайта есть CSS, JS и картинки. каждый тип ресурса лежит на своем поддомене:
css.site.com
js.site.com
imgs.site.com
пусть каждого типа ресурсов — 10 штук.
пользователь открывает страницу. создается 18 потоков и начинает грузиться 6 стилей, 6 сриптов и 6 картинок. еще 12 потоков простаивает. вообще. простаивает.
добавляем еще подгрузку GA:
пользователь открывает сраницу. создается 19 потоков и начинает грузиться 6 стилей, 6 скриптов, 6 картинок и 1 GA.
Где тут замедление? Можете экстраполировать эту логику далее, что бы понять что загрузка 1 скрипта малого размера с отдельного домена в современных браузерах рояля практически не играет
в данном конкретном случае я (почти) с Вами согласен. Только скорость загрузки тоже ограничена.
Пусть в данном примере все 18 файлов имеют размер по 10 Кб. Всего 180 Кб + 20 Кб GA.
Если мы загружаем GA в самом конце — все отлично.
Если мы его загружаем асинхронно со всеми этими ресурсами, то замедление аж 10% в силу общего использования канала (от профайдера).
Да, у нас еще издержки на установление соединения, но они обычно не больше, чем издержки на загрузку. Так что 5% тут по-всякому выходит.
И это только для данного конкретного примера. Обычно на странице от 50 объектов и от 6 различных хостов.
Пусть в данном примере все 18 файлов имеют размер по 10 Кб. Всего 180 Кб + 20 Кб GA.
Если мы загружаем GA в самом конце — все отлично.
Если мы его загружаем асинхронно со всеми этими ресурсами, то замедление аж 10% в силу общего использования канала (от профайдера).
Да, у нас еще издержки на установление соединения, но они обычно не больше, чем издержки на загрузку. Так что 5% тут по-всякому выходит.
И это только для данного конкретного примера. Обычно на странице от 50 объектов и от 6 различных хостов.
по поводу «почти не играет» я могу долго дискуссию поддерживать. Лучше всего это картинкой отобразить (по X — время загрузки в секундах, по Y — процент пользователей)
Да, у нас 58%, которые «в танке» и у которых «загрузка за 4 секунды». Но что прикажете делать с остальными 42%
Да, у нас 58%, которые «в танке» и у которых «загрузка за 4 секунды». Но что прикажете делать с остальными 42%
и что нам показывает этот график, касательно дискуссии? как это корелирует с установленным GA?
У меня описанный вариант треккинга вызывает симпатию, т.к. я долгое время работал с прокси, через прокси и с учетом прокси, локальный дебаг под ВПН и т.д.
Такой код позволяет НЕ задерживать загрузку страницы, если прокси/настройки сети не разрешают доступ для Google Analytics в данный момент.
Такой код позволяет НЕ задерживать загрузку страницы, если прокси/настройки сети не разрешают доступ для Google Analytics в данный момент.
Моя критика направлена не на подход, а на то, какое это на самом деле «улучшение».
GA сейчас и так ничего не блокирует, ибо вставляется перед </body>. Да, теперь (в некоторых браузерах с запрещенным через прокси GA) еще и индикатор загрузки не будет показываться.
Т.е. я не хочу сказать, что новый вариант подключения GA хуже. Нет. Я просто говорю, что он (почти) никак не лучше. Хотя шуму на этот счет уже много поднято.
GA сейчас и так ничего не блокирует, ибо вставляется перед </body>. Да, теперь (в некоторых браузерах с запрещенным через прокси GA) еще и индикатор загрузки не будет показываться.
Т.е. я не хочу сказать, что новый вариант подключения GA хуже. Нет. Я просто говорю, что он (почти) никак не лучше. Хотя шуму на этот счет уже много поднято.
>Поток этот блокирует загрузку остальных ресурсов (т.е. у браузера несколько потоков, один будет занят GA вместо того, чтобы картинки, например, загружать).
Это не совсем правда, тоесть GA конечно будет занимать один поток браузера, но не будет блокировать все остальные загрузки и рендеринг документа, как блокировал бы старый.
Ну и ничего не мешает повесть вызов этой функции на онлоад, тогда он точно ничего не будет блокировать.
Это не совсем правда, тоесть GA конечно будет занимать один поток браузера, но не будет блокировать все остальные загрузки и рендеринг документа, как блокировал бы старый.
Ну и ничего не мешает повесть вызов этой функции на онлоад, тогда он точно ничего не будет блокировать.
старый не блокировал. Он вставлялся перед </body>
зато пока старый не загрузился, не происходило domReady, следовательно не вешались обработчики событий(всё-таки почти везде они вешаются именно по domReady) и сайт скорее всего оставался не юзабельным до загрузки GA.
Ну и ещё раз напишу главный профит новой версии: её можно повесить на onload без танцев с бубном, и 99% что она уже ничего не замедлит.
Я понимаю если бы ты придерался к реализации(да document.documentElement.firstChild.appendChild может зафейлиться при какой-то очень корявой разметке) но сама идея асинхронной загрузки очень правильная и хорошая.
Ну и ещё раз напишу главный профит новой версии: её можно повесить на onload без танцев с бубном, и 99% что она уже ничего не замедлит.
Я понимаю если бы ты придерался к реализации(да document.documentElement.firstChild.appendChild может зафейлиться при какой-то очень корявой разметке) но сама идея асинхронной загрузки очень правильная и хорошая.
Данный код даёт профит только в том случае, если у клиента в момент загрузки сайта не доступен хост GA. Браузер в этом случае не будет дожидаться загрузки счетчика и продолжит грузить страницу. Во всех остальных случаях будет то, что вы описали, т.е. такой способ будет скорее вреден, чем полезен.
Буквально на днях у меня не грузились ни адсенс, ни директ на сайтах. Видимо с каналами что-то было. Половина страницы, содержащая меню, загрузится и висит (долго висит), дожидаясь ответа от гугла/яндекса. А ты сидишь, ждешь, когда уже наконец статья догрузится. С асинхронным подключением такого бы не было.
Буквально на днях у меня не грузились ни адсенс, ни директ на сайтах. Видимо с каналами что-то было. Половина страницы, содержащая меню, загрузится и висит (долго висит), дожидаясь ответа от гугла/яндекса. А ты сидишь, ждешь, когда уже наконец статья догрузится. С асинхронным подключением такого бы не было.
Но теперь ничего не мешает грузить ГА в jQuery по onload. Что и даст требуемое — загрузку после полной обработки страницы.
что самое интересное, и раньше тоже не мешало :)
В принципе да. Но тогда приходилось
1. onload c загрузкой GA вставлять в начало скрипта
2. Все обработки на страницах тоже инициализировать по onload
Сейчас это упростилось
1. onload c загрузкой GA вставлять в начало скрипта
2. Все обработки на страницах тоже инициализировать по onload
Сейчас это упростилось
> onload c загрузкой GA вставлять в начало скрипта
начало страницы
начало страницы
да нет, зачем? Таймеры решали. Сейчас да, чуть-чуть проще, но кода меньше не стало.
а разве $.onload не в порядке очереди выполняются?
в порядке, но какое это имеет значение? Нам все равно выполнить GA надо только после его загрузки, а не раньше.
я имею ввиду что данная конструкция вызовет ошибку в старом случае:
Потому что onload с попыткой обратиться к _gat будет выполнен раньше, чем пройдет загрузка js
[body]
$(function(){
var pageTracker = _gat._getTracker('UA-XXXXX-X');
pageTracker._trackPageview();
});
...
$(function(){
//load GA here
});
[/body]
Потому что onload с попыткой обратиться к _gat будет выполнен раньше, чем пройдет загрузка js
а я говорю, что конструкция
ошибки не вызовет
$(function(){
//load GA here
setTimeout(function(){
if (typeof _gat==='undefined') {
setTimeout(arguments.callee,100)
} else {
var pageTracker = _gat._getTracker('UA-XXXXX-X');
pageTracker._trackPageview();
}
});
});ошибки не вызовет
ну, там интервал еще пропустил
У нас еще есть обработка целей — к примеру в коде часто встречается что-то типа
pageTracker._trackPageview("/avia/details");
Согласитесь, каждый раз подобное оборачивать в setTimeout не очень удобно )
pageTracker._trackPageview("/avia/details");
Согласитесь, каждый раз подобное оборачивать в setTimeout не очень удобно )
А я уже было обрадовался )
Ну и еще самое главное: опера подключает динамически созданные скрипты синхронно, так что для нее этот код аналогичен старому.
но увеличит точность счетчика (на это постоянно идет ругань, возможно, потому что GA тупо не успевает загрузиться).
А каким образом точность увеличится? Если счетчик будет догружаться после загрузки страницы, то посетитель за это время может повтыкать на страничку чутка и навалить с неё, а в это время код счетчика ещё пытается пролезть через узкую щель модемного канала. В результате этого быстрочитателя счетчик посчитать не успеет.
А если страничка будет лагать до того момента как запустится счетчик — втыкатель будет с нетерпением ждать пока прогрузятся ожидаемые им букофки и не закроет страницу, в результате мы его успешно посчитаем.
Поправьте плиз меня если я мыслю не так как на самом деле ;)
А каким образом точность увеличится? Если счетчик будет догружаться после загрузки страницы, то посетитель за это время может повтыкать на страничку чутка и навалить с неё, а в это время код счетчика ещё пытается пролезть через узкую щель модемного канала. В результате этого быстрочитателя счетчик посчитать не успеет.
А если страничка будет лагать до того момента как запустится счетчик — втыкатель будет с нетерпением ждать пока прогрузятся ожидаемые им букофки и не закроет страницу, в результате мы его успешно посчитаем.
Поправьте плиз меня если я мыслю не так как на самом деле ;)
Че-то firebug упорно утверждает что ga.js скачивается НЕ после загрузки страницы.
комментарий выше. Автора «GA загружается после загрузки страницы» можно смело минусовать за проф. непригодность :)
хм, значит я как-то неправильно трактовал «The asynchronous snippet allows browsers to continue rendering the page while ga.js loads in the background. Since the browser might encounter tracking API calls before ga.js has finished loaded, a different syntax must be used for customizing your snippet.»
нет-нет, Вы тоже немного заблуждаетесь. async здесь означает лишь (имхо, надо бы почитать спецификацию для прояснения) только «плотность» загрузки потоков загрузки (сорри за тавтологию) в браузере и порядок выполнения скриптов. Т.е. скрипт во всех браузерах будет загружаться асинхронно, просто в некоторые «более асинхронно», чем в других
А почему на самом сайте https://www.google.com/analytics/ нет ни какой об этом информации?…
Код там предлагается старый.
Код там предлагается старый.
если веб-мастера коммерческого сайта настолько (уж извините за прямоту) тупы, что не могут понять разницу между двумя кусками кода, то это уже на их совести :)
Есть и более изощренные методы подключения GA на сайте: например, в составе какой-то общей библиотеки. Так еще быстрее получится. И кэшироваться будет лучше (относительно данного сайта).
Есть и более изощренные методы подключения GA на сайте: например, в составе какой-то общей библиотеки. Так еще быстрее получится. И кэшироваться будет лучше (относительно данного сайта).
В GA меня напрягает такой момент: если у меня отключен VPN для доступа в инет или просто в организации пропал инет, то на местных-локальных сайтах начинается проблема с Javascript/jQuery. Он не выполняется, пока не загрузится GA или не выйдет таймаут в браузере или пока не нажмешь «stop».
Причем кэширование GA-скрипта на локальном сайте не помогает. Наверно GA пытается коннектиться к своему серверу раньше, чем выполняются $.ready в jQuery, на этом и стопорится выполнение JS.
Причем кэширование GA-скрипта на локальном сайте не помогает. Наверно GA пытается коннектиться к своему серверу раньше, чем выполняются $.ready в jQuery, на этом и стопорится выполнение JS.
У меня он давно блокируется Adblock-ом, как и всё остальное подобное.
Я боролся так c помощью jQuery:
$(document).ready(function() {
$.getscript('http://www.google-analytics.com/urchin.js', function(data) {
uacct = «UA-XXXXXX-4X»;
urchinTracker();
}, 'script');
});
$(document).ready(function() {
$.getscript('http://www.google-analytics.com/urchin.js', function(data) {
uacct = «UA-XXXXXX-4X»;
urchinTracker();
}, 'script');
});
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Теперь Google Analytics работает Асинхронно