Как отслеживать использование вашего сайта в автономном режиме, чтобы вы могли обосновать, почему вашему сайту необходимо улучшить работу в автономном режиме.
В этой статье показано, как отслеживать использование вашего сайта в автономном режиме, чтобы помочь вам обосновать, почему вашему сайту нужен лучший автономный режим. В нем также объясняются подводные камни и проблемы, которых следует избегать при внедрении аналитики использования в автономном режиме.
Подводные камни онлайн- и оффлайн-событий браузера
Очевидным решением для отслеживания использования в автономном режиме является создание прослушивателей событий online
и offline
(которые поддерживаются многими браузерами ) и размещение логики отслеживания аналитики в этих прослушивателях. К сожалению, у этого подхода есть несколько проблем и ограничений:
- В целом отслеживание каждого события состояния сетевого подключения может быть чрезмерным и контрпродуктивным в мире, ориентированном на конфиденциальность, где следует собирать как можно меньше данных. Кроме того, события
online
иoffline
могут срабатывать всего лишь за долю секунды потери сети, которую пользователь, вероятно, даже не увидит или не заметит. - Аналитическое отслеживание оффлайн-активности никогда не достигнет аналитического сервера, потому что пользователь… ну, офлайн.
- Локальное отслеживание временной метки, когда пользователь выходит из сети, и отправка автономной активности на сервер аналитики, когда пользователь снова подключается к сети, зависит от повторного посещения пользователем вашего сайта. Если пользователь покидает ваш сайт из-за отсутствия автономного режима и больше не заходит на него, у вас нет возможности это отследить. Возможность отслеживать потери в автономном режиме является критически важной информацией для обоснования того, почему вашему сайту нужен лучший автономный режим.
-
online
мероприятие не очень надежно, поскольку оно знает только о доступе к сети , а не о доступе к Интернету. Таким образом, пользователь может по-прежнему находиться в автономном режиме, и отправка команды отслеживания может завершиться неудачно. - Даже если пользователь по-прежнему остается на текущей странице, находясь в автономном режиме, ни одно из других событий аналитики (например, события прокрутки, клики и т. д.) также не отслеживается, что может быть более актуальной и полезной информацией.
- Само по себе пребывание в автономном режиме также не имеет особого смысла. Разработчику веб-сайта может быть важнее знать, какие ресурсы не удалось загрузить. Это особенно актуально в контексте SPA, где разрыв сетевого подключения может не привести к появлению страницы с ошибкой в автономном режиме браузера (что понятно пользователям), но с большей вероятностью приведет к незаметному сбою случайных динамических частей страницы.
Вы по-прежнему можете использовать это решение, чтобы получить базовое представление об использовании в автономном режиме, но необходимо тщательно учитывать множество недостатков и ограничений.
Лучший подход: сервисный работник
Решение, которое включает автономный режим, оказывается лучшим решением для отслеживания использования автономного режима. Основная идея состоит в том, чтобы хранить аналитические пинги в IndexedDB, пока пользователь находится в автономном режиме, и просто повторно отправлять их, когда пользователь снова подключается к сети. Для Google Analytics это уже доступно через модуль Workbox , но имейте в виду, что обращения, отправленные с задержкой более четырех часов, могут не быть обработаны. В простейшей форме его можно активировать в сервисном работнике на базе Workbox с помощью этих двух строк:
import * as googleAnalytics from 'workbox-google-analytics';
googleAnalytics.initialize();
Это отслеживает все существующие события и запросы просмотра страниц в автономном режиме, но вы не узнаете, что они произошли в автономном режиме (поскольку они просто воспроизводятся как есть). Для этого вы можете манипулировать запросами отслеживания с помощью Workbox, добавив флаг offline
в пинг аналитики, используя настраиваемое измерение ( cd1
в примере кода ниже):
import * as googleAnalytics from 'workbox-google-analytics';
googleAnalytics.initialize({
parameterOverrides: {
cd1: 'offline',
},
});
Что, если пользователь уйдет со страницы из-за того, что находится в автономном режиме, прежде чем восстановится подключение к Интернету? Несмотря на то, что обычно это переводит сервис-воркера в спящий режим (поскольку он не может отправить данные при восстановлении соединения), модуль Workbox Google Analytics использует API фоновой синхронизации , который отправляет аналитические данные позже, когда соединение восстанавливается, даже если пользователь закрывает вкладку или браузер.
Есть еще один недостаток: хотя это делает существующее отслеживание доступным в автономном режиме, вы, скорее всего, не увидите поступления большого количества релевантных данных, пока не внедрите базовый автономный режим. Пользователи по-прежнему быстро покидают ваш сайт, когда соединение разрывается. Но теперь вы можете, по крайней мере, измерить и количественно оценить это, сравнив среднюю продолжительность сеанса и вовлеченность пользователей с применением офлайн-измерения с вашими обычными пользователями.
SPA и ленивая загрузка
Если пользователи, посещающие страницу, созданную как многостраничный веб-сайт, переходят в автономный режим и пытаются перейти к ней, отображается автономная страница браузера по умолчанию, помогая пользователям понять, что происходит. Однако страницы, созданные как одностраничные приложения, работают по-другому. Пользователь остается на той же странице, а новый контент загружается динамически через AJAX без какой-либо навигации по браузеру. Пользователи не видят страницу с ошибкой браузера при выходе из сети. Вместо этого динамические части страницы отображаются с ошибками, переходят в неопределенное состояние или просто перестают быть динамическими.
Подобные эффекты могут возникнуть на многостраничных веб-сайтах из-за ленивой загрузки. Например, возможно, первоначальная загрузка произошла онлайн, но пользователь отключился от сети перед прокруткой. Весь лениво загруженный контент ниже сгиба автоматически выйдет из строя и будет отсутствовать.
Поскольку подобные случаи действительно раздражают пользователей, имеет смысл их отслеживать. Сервисные работники — идеальное место для выявления сетевых ошибок и последующего отслеживания их с помощью аналитики. С помощью Workbox можно настроить глобальный обработчик перехвата для информирования страницы о неудачных запросах путем отправки события сообщения:
import { setCatchHandler } from 'workbox-routing';
setCatchHandler(({ event }) => {
// https://developer.mozilla.org/docs/Web/API/Client/postMessage
event.waitUntil(async function () {
// Exit early if we don't have access to the client.
// Eg, if it's cross-origin.
if (!event.clientId) return;
// Get the client.
const client = await clients.get(event.clientId);
// Exit early if we don't get the client.
// Eg, if it closed.
if (!client) return;
// Send a message to the client.
client.postMessage({
action: "network_fail",
url: event.request.url,
destination: event.request.destination
});
return Response.error();
}());
});
Вместо того, чтобы прослушивать все неудачные запросы, есть другой способ — обнаружить ошибки только на определенных маршрутах. Например, если мы хотим сообщать об ошибках, происходящих только на маршрутах к /products/*
, мы можем добавить проверку в setCatchHandler
, которая фильтрует URI с помощью регулярного выражения. Более чистое решение — реализовать RegisterRoute с собственным обработчиком. Это инкапсулирует бизнес-логику в отдельный маршрут, что обеспечивает лучшую поддержку в более сложных сервис-воркерах:
import { registerRoute } from 'workbox-routing';
import { NetworkOnly } from 'workbox-strategies';
const networkOnly = new NetworkOnly();
registerRoute(
new RegExp('https:\/\/example\.com\/products\/.+'),
async (params) => {
try {
// Attempt a network request.
return await networkOnly.handle(params);
} catch (error) {
// If it fails, report the error.
const event = params.event;
if (!event.clientId) return;
const client = await clients.get(event.clientId);
if (!client) return;
client.postMessage({
action: "network_fail",
url: event.request.url,
destination: "products"
});
return Response.error();
}
}
);
На последнем этапе страница должна прослушать событие message
и отправить аналитический пинг. Опять же, обязательно буферизируйте аналитические запросы, которые происходят в автономном режиме внутри сервис-воркера. Как описано ранее, инициализируйте плагин workbox-google-analytics
для встроенной поддержки Google Analytics.
В следующем примере используется Google Analytics, но его можно применить таким же образом и к другим поставщикам аналитики.
if ("serviceWorker" in navigator) {
// ... SW registration here
// track offline error events
navigator.serviceWorker.addEventListener("message", event => {
if (gtag && event.data && event.data.action === "network_fail") {
gtag("event", "network_fail", {
event_category: event.data.destination,
// event_label: event.data.url,
// value: event.data.value
});
}
});
}
Это позволит отслеживать неудачные загрузки ресурсов в Google Analytics, где их можно будет проанализировать с помощью отчетов . Полученные данные можно использовать для улучшения кэширования сервис-воркеров и обработки ошибок в целом, чтобы сделать страницу более устойчивой и надежной в нестабильных сетевых условиях.
Следующие шаги
В этой статье были показаны различные способы отслеживания использования оффлайн, их преимущества и недостатки. Хотя это может помочь количественно оценить, сколько ваших пользователей отключаются от сети и сталкиваются из-за этого с проблемами, это все еще только начало. Пока ваш веб-сайт не предлагает хорошо продуманный автономный режим, вы, очевидно, не увидите большого использования офлайн-режима в аналитике.
Мы рекомендуем установить полное отслеживание, а затем постепенно расширять свои возможности в автономном режиме, обращая внимание на номера отслеживания. Сначала начните с простой страницы ошибок в автономном режиме — с Workbox это легко сделать — и в любом случае ее следует рассматривать как лучший UX-практик, аналогичный пользовательским страницам 404. Затем перейдите к более продвинутым резервным вариантам автономного режима и, наконец, к реальному офлайн-контенту. Убедитесь, что вы хорошо рекламируете и объясняете это своим пользователям, и вы увидите рост использования. В конце концов, каждый время от времени выходит из сети.
Советы о том, как убедить межфункциональных заинтересованных сторон инвестировать больше в ваш веб-сайт, можно найти в разделах «Как сообщать о показателях и формировать культуру производительности» и «Назначать скорость веб-сайта в кросс-функциональном режиме». Хотя эти публикации ориентированы на производительность, они должны помочь вам получить общее представление о том, как привлекать заинтересованные стороны.
Героическое фото Джей Си Геллидона на Unsplash .