Html5-boilerplate: Используйте localStorage для отслеживания Google Analytics, когда это возможно

Хотя я не уверен, хотим ли мы заблокировать Modernizr как зависимость.

Может быть, было бы лучше просто добавить его в документы?

Также пингуйте @mathiasbynens.

Спасибо за оптимизацию вырезки, Дэвид. Как @alrra , я думаю, что мы хорошо добавим его в документы.

Кредит принадлежит не мне; это было доведено до моего сведения @elmerbulthuis. Хотя я бы не стал рассматривать это как оптимизацию самого _snippet_, как такового --- это скорее оптимизация сети в целом :-p.

Интересно, сколько байтов можно было бы сэкономить в глобальном масштабе, если бы все приняли решение localStorage .

Я, очевидно, большой поклонник этого решения. Единственная проблема с включением его по умолчанию в шаблон — это та, о которой упоминал @davidmurdoch : сначала нам нужно протестировать функции для localStorage . Это можно сделать с помощью Modernizr или путем добавления небольшого фрагмента автономного кода , но в любом случае это немного увеличит размер страницы. Опять же, в долгосрочной перспективе это сэкономит много байтов, поскольку файлы cookie не будут отправляться в заголовках запросов для любых ресурсов в затронутом домене.

Что-то вроде этого:

(function(b,o,i,l,e,r){b.GoogleAnalyticsObject=l;b[l]||(b[l]=
function(){(b[l].q=b[l].q||[]).push(arguments)});b[l].l=+new Date;
e=o.createElement(i);r=o.getElementsByTagName(i)[0];
e.src='//www.google-analytics.com/analytics.js';
r.parentNode.insertBefore(e,r)}(window,document,'script','ga'));
(function(){var a=(function(){var c=new Date,b;try{
localStorage.setItem(c,c);b=localStorage.getItem(c)==c;
localStorage.removeItem(c);return b&&localStorage}catch(d){}}());
ga('create','UA-XXXXX-X',a?{storage:'none',clientId:a.gaId}:{});
ga(function(b){a.gaId=b.get('clientId')});ga('send','pageview')}());

(В нем используется тест функций localStorage , взятый с http://mathiasbynens.be/notes/localstorage-pattern.)

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

К вашему сведению: это может сэкономить около 33 необработанных байтов (заголовки/файлы cookie не сжаты) за круговорот для каждого запроса к затронутым доменам.

Текущее решение @mathiasbynens для обнаружения встроенных функций на 130 сжатых байтов* больше (очевидно, это будет отличаться для каждой уникальной страницы, но это дает нам приблизительное представление). Итак, мы, вероятно, должны посмотреть, сможем ли мы еще немного поиграть в гольф.

Лично я хотел бы увидеть сжатый diff размером до 65 байт и скоро попробую сам. :-)

_∗используя этот дефлятор: http://www.vervestudios.co/projects/compression-tests/snippet-deflator_

318 байт в формате GZIP (наша текущая версия — 248 байт в формате GZIP):

(function(l,e){GoogleAnalyticsObject='ga',(window.ga||(ga=function(l,e){(ga.q=ga.q||[]).push(arguments)})).l=+new Date,l=document.createElement('script'),l.src='//www.google-analytics.com/analytics.js',(e=document.getElementsByTagName('script')[0]).parentNode.insertBefore(l,e);ga('create','UA-XXXXX-X',(function(l,e){try{l=(localStorage[ga.l]=ga.l)==ga.l;localStorage.removeItem(ga.l);return l}catch(l){}}())?{storage:'none',clientId:localStorage.clientId}:{});ga(function(l,e){localStorage.clientId=l.get('clientId')});ga('send','pageview')}())

Это не очень хорошо проверено, поэтому мне все равно нужно это сделать. Но это начало.

И, к сожалению, тест localStorage , вероятно, где-то скомпрометирован в каком-то браузере, так как я избавился от вызовов setItem и getItem и использовал некоторые другие «трюки» для игры в гольф.

Это все, что у меня есть на данный момент. :-)

Мне только что пришло в голову, что мы сжимаем сам фрагмент, что довольно бессмысленно. Результаты Gzip зависят от остальной части документа (т. е. исходного кода HTML, если он встроен в документ, или остальной части файла JavaScript, если он является его частью). Может быть, сравнение размера фрагмента в сжатом виде — не лучший способ измерить это?

Ваш фрагмент выглядит красиво. Хороший улов повторного использования временной метки ga.l вместо создания новой!

И, к сожалению, тест localStorage , вероятно, скомпрометирован где-то в каком-то браузере, так как я избавился от вызовов setItem и getItem и использовал некоторые другие "трюки" игры в гольф.

Если это так, то это будет ИМХО.

Мы можем заменить document.getElementsByTagName('script')[0] на document.scripts[0] , когда поддержка Firefox < 9 больше не является проблемой.

@mathiasbynens GZIPping только фрагмент будет приблизительно соответствовать _минимальной_ байтовой экономии от сжатия. Так что это не совсем спорный вопрос. Почти во всех случаях степень сжатия фрагмента будет увеличиваться по мере увеличения размера страницы.

Нужно еще протестировать! Я добавил обратно вызовы getItem и setItem и сумел сократить их до 309 байт:

+function(l,e){(ct=this[GoogleAnalyticsObject='ct']||function(l,e){(ct.q=ct.q||[]).push(arguments)}).l=+new Date,l=document.createElement('script'),l.src='//www.google-analytics.com/analytics.js',(e=document.getElementsByTagName('script')[0]).parentNode.insertBefore(l,e);try{localStorage.setItem(ct.l,ct.l),l=localStorage.getItem(ct.l)-ct.l,localStorage.removeItem(ct.l)}catch(l){};ct('create','UA-XXXXX-X',l?{}:{clientId:localStorage.clientId,storage:'none'}),ct(function(l,e){localStorage.clientId=l.get('clientId')}),ct('send','pageview')}()

• Теперь я использую IIFE, который использует знак + вместо круглых скобок.
• Я также использую localStorage.clientId вместо localStorage.gaId , поскольку clientId экономит несколько байтов.
• Использование this вместо window сэкономило еще 1 байт (в сочетании с перемещением назначения GoogleAnalyticsObject ).
• Изменение ga на ct (ct более распространено) сохранило еще один байт (это, вероятно, не стоит путаницы).
• Избавившись от вызова функции и повторно используя l для проверки localStorage , назначив его 0 в случае успеха, мы сэкономили кучу байтов.

Опять же, это требует гораздо больше испытаний.

@davidmurdoch Есть какие-нибудь обновления по тестам? Можем ли мы написать тестовый поток для этого, чтобы другие могли помочь в тестировании?

Извините, я пропал без вести, меня поставили на высокоприоритетный 6-месячный проект, и я не смог посвятить много времени чему-то другому.

Самый простой (и самый глупый) способ проверить это — просто заменить код аналитики этим новым кодом и посмотреть, есть ли у вас странные колебания в числах и версиях браузеров. Я сделал это сам и не видел ничего торчащего. Тем не менее, у меня все равно не так много oldie посетителей.

Другой способ — загрузить этот экспериментальный скрипт аналитики в сгенерированный iframe (чтобы не мешать фрагменту стабильной аналитики) и вызвать _trackPageview оттуда, разумеется, под другой учетной записью GA. Затем вам просто нужно сравнить данные через неделю или около того.

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

Я только что начал тест для http://drublic.github.io/css-modal/. В последние месяцы у меня было 97 тысяч просмотров страниц, но они сильно распространились по браузеру.

Числа:

1. Хром 44,01%
2. Фаерфокс 34,38%
3. Internet Explorer 8,86%
4. Опера 5,26%
5. Сафари 4,01%
6. Android-браузер 2,22%

Давайте подождем и посмотрим. У меня параллельно работает "нормальная" статистика.

Кроме того, я думаю, что код нуждается в дополнительных обновлениях для удобства чтения (80 символов в строке и место для вставки идентификатора).

Я вернусь к этому тесту примерно через неделю.

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

Реализация по умолчанию показывает 2964 уникальных посещения за период с 13 по 17 марта.
Локальное хранилище показывает 756 уникальных посещений за тот же период времени.

Возможных причин может быть три:

• моя реализация отрезанного повреждена
• загрузка iframe блокируется браузерами
• интеграция с локальным хранилищем фрагментов нарушена

В настоящее время я не вижу ошибок в своем коде здесь: http://drublic.github.io/css-modal/test-gau-localstorage.html (это iframe, интегрированный в сайт).

Также я не сталкивался с блокировкой фреймов браузерами или страницами. Кто-нибудь знает, может ли это случиться?

Что приводит меня к решению, что локальное хранилище, отрезанное GUA, содержит ошибки. Я не смотрел, в чем могут быть проблемы.
Можем ли мы разработать неминифицированный вариант для дальнейшего тестирования и минимизации после того, как получим рабочее решение?

Также я бы предпочел отказаться от этого из HTML5BP v5.0 и выпустить его с 5.1, если мы найдем решение. Что вы думаете, ребята?

Также я бы предпочел отказаться от HTML5BP v5.0 и выпустить его с 5.1.

@drublic :+1: (добавлена ​​проблема в веху v5.1.0 ).

Если у вас такие цифры, возможно, это связано с тем, что вам нужно указать clientId по умолчанию при вызове ga('create', w/ storage:'none' .

https://developers.google.com/analytics/devguides/collection/analyticsjs/domains#disableCookies

Только что написал об этой проблеме на своем сайте здесь: Google Async Analytics с использованием LocalStorage и создал тестовую страницу здесь: http://davidmurdoch.com/google-async-analytics-using-localstorage-test/.

Пожалуйста, читайте, делитесь и тестируйте.

(примечание: если вы обнаружите какие-либо опечатки или ошибки на этих страницах, сообщите мне об этом в твиттере @pxcoach .

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

Прежде всего, я не думаю, что для проекта H5BP будет хорошей идеей рекомендовать фрагмент отслеживания Google Analytics, который функционально отличается от официально рекомендованного. Люди, вероятно, решат, что это одно и то же, и если на самом деле это не так, это вызовет путаницу. Если в документации Google Analytics утверждается, что GA поддерживает какую-то функцию, а это не так, потому что кто-то использует другой фрагмент, это, вероятно, приведет к некоторым довольно сложным для отладки проблемам (особенно если H5BP не делает очевидным, что фрагменты отличаются).

Если есть что-то, что GA может сделать лучше, мы хотели бы развиваться вместе с потребностями сообщества, а не отклоняться от него. (Кстати, не стесняйтесь пинговать или копировать меня по любым вопросам Github, связанным с GA.)

В любом случае, вот основная проблема с localStorage и почему GA не предлагает его в качестве механизма хранения по умолчанию:

localStorage ограничен location.origin , тогда как файлы cookie могут быть привязаны к домену верхнего уровня. Хранилище файлов cookie позволяет Analytics.js выполнять отслеживание поддоменов по умолчанию, и это было бы невозможно с localStorage. Кроме того, если части вашего сайта используют HTTP, а другие части — HTTPS, это также приведет к сбою (под сбоем я подразумеваю, что хранилище не является общим, поэтому вы потеряете идентификатор клиента, и GA будет рассматривать его как отдельный сеанс). ). Хотя это правда, что это не беспокоит большинство пользователей GA, я все же думаю, что было бы плохо предлагать этот предложенный фрагмент в качестве замены из-за потери функций, которую я только что описал.

При этом, основываясь на этой проблеме и сообщении в блоге @davidmurdoch , мы попытаемся расставить приоритеты в создании официально поддерживаемого механизма localStorage. В настоящее время параметр storage поддерживает только параметры cookie и none , но мы хотели бы добавить третий параметр localStorage , чтобы пользователи, которые не нужно включить субдомен или межсхемное отслеживание. Я не знаю, когда это будет добавлено, но я могу обновить эту проблему, когда/если она будет.

Всем ли это кажется разумным?

@philipwalton Спасибо за комментарий!

Всем ли это кажется разумным?

Копия: @davidmurdoch , @mathiasbynens

При этом, основываясь на этой проблеме и сообщении в блоге @davidmurdoch , мы попытаемся расставить приоритеты в создании официально поддерживаемого механизма localStorage.

:+1:

Пожалуйста, обновите проблему, когда она будет добавлена. Спасибо!

@philipwalton , :+1: Отличные новости! Однако вам не нужно _пытаться_, чтобы построить его, мы уже это сделали! :-p (шучу, шучу).

Я продолжу и обновлю свой пост в блоге этой новостью и создам репозиторий GitHub с неофициальным кодом отслеживания localStorage , обязательно подчеркнув его недостатки. Спасибо!

:+1: но также кажется, что будущему вебу нужен какой-то topLevelStorage . Рад, что опция будет доступна. Имея это в виду, и когда сниппет попадет, какое предпочтение может быть отдано h5bp?

@jonathantneal , у нас было globalStorage в Firefox, в котором была кросс-схема, порт и хранилище поддоменов. Firefox был единственным, кто реализовал его, и с тех пор он был помечен как устаревший. :-(

@davidmurdoch Большое вам спасибо за то, что вы открыли этот вопрос и покопались в нем, мы искренне ценим это!

@philipwalton Еще раз спасибо, что присоединились к обсуждению, и, как сказал @mathiasbynens , держите нас в курсе!

и создайте репозиторий GitHub с неофициальным кодом отслеживания localStorage, обязательно подчеркнув его недостатки.

Репозиторий @davidmurdoch https://github.com/davidmurdoch/ga-localstorage(хотя он еще не обновлен).

Я только что опубликовал сценарий «Google Analytics с использованием localStorage» в npm: https://www.npmjs.org/package/ga-localstorage .

Репозиторий https://github.com/davidmurdoch/ga-localstorage также был обновлен кодом.

Здравствуйте, вы читали этот ТАК комментарий?

http://stackoverflow.com/questions/4502128/convert-google-analytics-cookies-to-local-session-storage/19207035#comment -44767913

Мне было бы любопытно узнать, что вы все думаете.

@caesarsol Я думаю, что это действительно плохая идея. Как я описал в своем комментарии , файлы cookie и localStorage не имеют одинаковых ограничений, поэтому менять их местами для каждого отдельного скрипта, работающего на странице, крайне рискованно.

привет @philipwalton , спасибо за ответ, но, возможно, я плохо объяснил, я имел в виду этот комментарий пользователя SO _smhmic_:

Это может нарушать GA TOS! Вот подержанная цитата члена команды GA, взятая из этой статьи: «Использование механизмов управления состоянием HTTP» (читай: localStorage) «для распространения состояния cookie является обходом наших гарантий конфиденциальности. Это нарушает Условия использования Google Analytics. ". Моя интерпретация этого заключается в том, что GA использует файлы cookie, а не localStorage, потому что больше пользователей знакомы с концепцией файлов cookie и способами их очистки; таким образом, использование GA файлов cookie является функцией конфиденциальности. - шмик

Использование механизмов управления состоянием HTTP» (читай: localStorage) для распространения состояния файлов cookie является обходом наших мер защиты конфиденциальности. Это нарушает Условия использования Google Analytics.

Хм, я не думаю, что это правда. Существуют функции отказа, предоставляемые GA (например, расширения Chrome), которые не полагаются на разработчика, использующего файлы cookie. Я думаю, смысл этого раздела TOS в том, что вы не можете создать механизм, с помощью которого кто-то, кто использует официальное расширение «не отслеживать», будет _все еще_ отслеживаться.

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

Обновлять:

TOS не запрещает использовать localStorage для хранения ClientID; теперь он официально поддерживается Google: https://developers.google.com/analytics/devguides/collection/analyticsjs/cookies-user-id#using_localstorage_to_store_the_client_id

Примечание: если вам необходимо поддерживать (чрезвычайно) старые браузеры (такие как iOS5 и FF4), их фрагмент кода может не работать (см.: https://github.com/Modernizr/Modernizr/blob/master/feature-detects/storage/localstorage. js).