Cómo hacer un seguimiento del uso sin conexión de tu sitio para que puedas justificar por qué necesita una mejor experiencia sin conexión
En este artículo, se muestra cómo hacer un seguimiento del uso sin conexión de tu sitio para ayudarte a justificar por qué tu sitio necesita un mejor modo sin conexión. También se explican las dificultades y los problemas que se deben evitar cuando se implementan las estadísticas de uso sin conexión.
Las dificultades de los eventos del navegador en línea y sin conexión
La solución obvia para hacer un seguimiento del uso sin conexión es crear objetos de escucha de eventos para los eventos online
y offline
(que son compatibles con muchos navegadores) y colocar tu lógica de seguimiento de estadísticas en esos objetos de escucha. Lamentablemente, este enfoque tiene varios problemas y limitaciones:
- En general, hacer un seguimiento de cada evento de estado de conexión de red puede ser excesivo y contraproducente en un mundo centrado en la privacidad, en el que se deben recopilar la menor cantidad posible de datos. Además, los eventos
online
yoffline
pueden activarse durante una fracción de segundo de pérdida de red, que un usuario probablemente ni siquiera vería o notaría. - El seguimiento de estadísticas de la actividad sin conexión nunca llegaría al servidor de estadísticas porque el usuario está… sin conexión.
- El seguimiento de una marca de tiempo de forma local cuando un usuario se desconecta y el envío de la actividad sin conexión al servidor de estadísticas cuando el usuario vuelve a conectarse depende de que el usuario vuelva a visitar tu sitio. Si el usuario abandona tu sitio debido a la falta de un modo sin conexión y nunca vuelve, no tienes forma de hacer un seguimiento de eso. La capacidad de hacer un seguimiento de las bajas sin conexión es un dato fundamental para crear un caso sobre por qué tu sitio necesita un mejor modo sin conexión.
- El evento
online
no es muy confiable, ya que solo conoce el acceso a la red, no el acceso a Internet. Por lo tanto, es posible que un usuario siga sin conexión y que el envío del ping de seguimiento falle. - Incluso si el usuario permanece en la página actual sin conexión, no se realiza un seguimiento de ninguno de los otros eventos de Analytics (p.ej., eventos de desplazamiento, clics, etc.), que podrían ser la información más relevante y útil.
- Estar sin conexión en sí tampoco es muy significativo en general. Como desarrollador de sitios web, es posible que sea más importante saber qué tipos de recursos no se pudieron cargar. Esto es especialmente relevante en el contexto de los SPA, en los que una conexión de red caída podría no generar una página de error sin conexión del navegador (que los usuarios comprenden), pero es más probable que falle de forma silenciosa en partes dinámicas aleatorias de la página.
Puedes usar esta solución para obtener una comprensión básica del uso sin conexión, pero debes considerar cuidadosamente las muchas desventajas y limitaciones.
Un mejor enfoque: el trabajador de servicio
La solución que habilita el modo sin conexión resulta ser la mejor para hacer un seguimiento del uso sin conexión. La idea básica es almacenar los pings de Analytics en IndexedDB mientras el usuario esté sin conexión y volver a enviarlos cuando vuelva a conectarse. En el caso de Google Analytics, esta función ya está disponible listo para usar a través de un módulo de Workbox, pero ten en cuenta que es posible que no se procesen los hits enviados con más de cuatro horas de demora. En su forma más simple, se puede activar dentro de un trabajador de servicio basado en Workbox con estas dos líneas:
import * as googleAnalytics from 'workbox-google-analytics';
googleAnalytics.initialize();
De esta manera, se realiza un seguimiento de todos los eventos existentes y los pings de vistas de página sin conexión, pero no sabrías que ocurrieron sin conexión (ya que solo se vuelven a reproducir tal como están). Para ello,
puedes manipular las solicitudes de seguimiento con Workbox
agregando una marca offline
al ping de Analytics, con una dimensión personalizada (cd1
en el
ejemplo de código que aparece a continuación):
import * as googleAnalytics from 'workbox-google-analytics';
googleAnalytics.initialize({
parameterOverrides: {
cd1: 'offline',
},
});
¿Qué sucede si el usuario sale de la página porque no tiene conexión, antes de que se restablezca la conexión a Internet? Aunque, por lo general, esto pone en suspensión al trabajador del servicio (porque no puede enviar los datos cuando se restablece la conexión), el módulo de Google Analytics de Workbox usa la API de Background Sync, que envía los datos de estadísticas más adelante cuando se restablece la conexión, incluso si el usuario cierra la pestaña o el navegador.
Sin embargo, hay un inconveniente: si bien esto permite que el seguimiento existente funcione sin conexión, es probable que no veas muchos datos relevantes hasta que implementes un modo sin conexión básico. Los usuarios abandonarían tu sitio rápidamente cuando se interrumpa la conexión. Pero ahora, al menos, puedes medir y cuantificar esto comparando la duración promedio de la sesión y la participación de los usuarios con la dimensión sin conexión aplicada en comparación con tus usuarios habituales.
SPA y carga diferida
Si los usuarios que visitan una página creada como un sitio web de varias páginas se desconectan y tratan de navegar, aparece la página sin conexión predeterminada del navegador, lo que ayuda a los usuarios a comprender lo que sucede. Sin embargo, las páginas compiladas como aplicaciones de una sola página funcionan de manera diferente. El usuario permanece en la misma página y el contenido nuevo se carga de forma dinámica a través de AJAX sin ninguna navegación del navegador. Los usuarios no ven la página de error del navegador cuando se quedan sin conexión. En su lugar, las partes dinámicas de la página se renderizan con errores, entran en estados no definidos o simplemente dejan de ser dinámicas.
Debido a la carga diferida, pueden ocurrir efectos similares en los sitios web de varias páginas. Por ejemplo, es posible que la carga inicial se haya realizado en línea, pero que el usuario se haya desconectado antes de desplazarse. Todo el contenido cargado de forma diferida debajo de la mitad inferior de la página fallará de forma silenciosa y no se mostrará.
Dado que estos casos son muy molestos para los usuarios, tiene sentido hacerles un seguimiento. Los trabajadores de servicio son el lugar ideal para detectar errores de red y, con el tiempo, hacerles un seguimiento con estadísticas. Con Workbox, se puede configurar un controlador de captura global para informar a la página sobre las solicitudes fallidas mediante el envío de un evento de mensaje:
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();
}());
});
En lugar de escuchar todas las solicitudes que fallan, otra forma es detectar errores solo en rutas específicas. A modo de ejemplo, si queremos informar errores que ocurren solo en las rutas a /products/*
, podemos agregar una verificación en setCatchHandler
que filtre el URI con una expresión regular.
Una solución más clara es implementar registerRoute con un controlador personalizado. Esto encapsula la lógica de negocio en una ruta independiente, con una mejor capacidad de mantenimiento en los service workers más complejos:
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();
}
}
);
Como último paso, la página debe escuchar el evento message
y enviar el ping de estadísticas.
Una vez más, asegúrate de almacenar en búfer las solicitudes de estadísticas que se realizan sin conexión dentro del servicio de trabajo. Como se describió antes, inicializa el complemento workbox-google-analytics
para la compatibilidad integrada con Google Analytics.
En el siguiente ejemplo, se usa Google Analytics, pero se puede aplicar de la misma manera a otros proveedores de estadísticas.
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
});
}
});
}
De esta manera, se realizará un seguimiento de las cargas de recursos que fallaron en Google Analytics, donde se pueden analizar con los informes. Las estadísticas derivadas se pueden usar para mejorar el almacenamiento en caché y el manejo de errores de los service workers en general, de modo que la página sea más sólida y confiable en condiciones de red inestables.
Próximos pasos
En este artículo, se mostraron diferentes formas de hacer un seguimiento del uso sin conexión con sus ventajas y limitaciones. Si bien esto puede ayudar a cuantificar cuántos de tus usuarios se desconectan y tienen problemas debido a esto, es solo el comienzo. Mientras tu sitio web no ofrezca un modo sin conexión bien creado, obviamente no verás mucho uso sin conexión en las estadísticas.
Te recomendamos que implementes el seguimiento completo y, luego, que extiendan tus capacidades sin conexión en iteraciones con atención a los números de seguimiento. Comienza con una página de error sin conexión simple (con Workbox es muy fácil hacerlo) y, de todos modos, se debe considerar una práctica recomendada de UX similar a las páginas 404 personalizadas. Luego, avanza hacia resguardos sin conexión más avanzados y, por último, hacia contenido sin conexión real. Asegúrate de promocionar y explicar esto a tus usuarios de forma clara, y verás que el uso aumentará. Después de todo, todos se desconectan de vez en cuando.
Consulta Cómo informar métricas y crear una cultura de rendimiento y Cómo corregir la velocidad del sitio web de forma multifuncional para obtener sugerencias sobre cómo persuadir a las partes interesadas multifuncionales para que inviertan más en tu sitio web. Aunque esas publicaciones se enfocan en el rendimiento, deberían ayudarte a obtener ideas generales sobre cómo atraer a las partes interesadas.
Foto hero de JC Gellidon en Unsplash.