오프라인 사용 측정

사이트에 더 나은 오프라인 환경이 필요한 이유를 설명할 수 있도록 사이트의 오프라인 사용을 추적하는 방법

스테판 지사우
스테판 지사우
마틴 쉴레
마틴 쉴레

이 도움말에서는 사이트의 오프라인 사용량을 추적하여 사이트에 더 나은 오프라인 모드가 필요한 이유를 확인하는 방법을 설명합니다. 또한 오프라인 사용 분석을 구현할 때 피해야 할 함정과 문제도 설명합니다.

온라인 및 오프라인 브라우저 이벤트의 함정

오프라인 사용을 추적하는 가장 확실한 솔루션은 onlineoffline 이벤트 (많은 브라우저에서 지원)의 이벤트 리스너를 만들고 이 리스너에 애널리틱스 추적 로직을 넣는 것입니다. 하지만 이 방법에는 다음과 같은 몇 가지 문제와 한계가 있습니다.

  • 일반적으로 모든 네트워크 연결 상태 이벤트를 추적하는 것은 과도할 수 있으며, 가능한 한 적은 데이터를 수집해야 하는 개인 정보 보호 중심의 환경에서는 비생산적입니다. 또한 onlineoffline 이벤트는 1초의 네트워크 손실로 실행될 수 있으며, 이 경우 사용자는 보지 못하거나 알아차리지 못할 수 있습니다.
  • 사용자가 오프라인 상태이므로 오프라인 활동의 애널리틱스 추적이 애널리틱스 서버에 도달하지 않습니다.
  • 사용자가 오프라인 상태가 될 때 로컬에서 타임스탬프를 추적하고 사용자가 온라인 상태가 되었을 때 오프라인 활동을 분석 서버로 전송하는 것은 사용자가 사이트를 다시 방문하느냐에 따라 달라집니다. 사용자가 오프라인 모드가 부족하여 사이트를 이탈하고 다시 방문하지 않는 경우 이를 추적할 방법이 없습니다. 오프라인 중단을 추적하는 기능은 사이트에 더 나은 오프라인 모드가 필요한 이유에 관한 사례를 구축하는 데 중요한 데이터입니다.
  • online 이벤트는 인터넷 액세스가 아닌 네트워크 액세스만 알고 있으므로 안정성이 떨어집니다. 따라서 사용자가 여전히 오프라인 상태일 수 있으며 추적 핑 전송이 여전히 실패할 수 있습니다.
  • 사용자가 오프라인 상태에서 계속 현재 페이지에 머무르더라도 다른 애널리틱스 이벤트 (예: 스크롤 이벤트, 클릭 등)도 추적되지 않으므로 더 관련성 높고 유용한 정보가 될 수 있습니다.
  • 오프라인 상태 자체도 일반적으로 그다지 의미가 없습니다. 웹사이트 개발자는 로드하지 못한 리소스의 종류를 아는 것이 더 중요할 수 있습니다. 이는 특히 SPA와 관련이 있습니다. 네트워크 연결이 끊겨도 사용자가 이해할 수 있는 브라우저 오프라인 오류 페이지로 이어지지 않지만 페이지에서 임의의 동적 부분이 자동으로 실패할 가능성이 높습니다.

이 솔루션을 사용하여 오프라인 사용에 관한 기본적인 내용을 파악할 수는 있지만, 여러 가지 단점과 제한 사항을 신중하게 고려해야 합니다.

더 나은 접근 방식: 서비스 워커

오프라인 모드를 사용 설정하는 솔루션이 오프라인 사용량을 추적하는 더 나은 솔루션으로 확인되었습니다. 기본 개념은 사용자가 오프라인 상태인 동안 IndexedDB에 분석 핑을 저장하고 사용자가 다시 온라인 상태가 되면 다시 전송하는 것입니다. Google 애널리틱스의 경우 워크박스 모듈을 통해 바로 사용 가능하지만 4시간 넘게 지연된 조회는 처리되지 않을 수 있습니다. 가장 간단한 형태로는 Workbox 기반 서비스 워커 내에서 다음 두 줄을 사용하여 활성화할 수 있습니다.

import * as googleAnalytics from 'workbox-google-analytics';

googleAnalytics.initialize();

이렇게 하면 오프라인 상태일 때 모든 기존 이벤트 및 페이지 조회 핑을 추적하지만 그대로 재생되기 때문에 오프라인에서 발생했다는 사실은 알 수 없습니다. 이를 위해 맞춤 측정기준 (아래 코드 샘플에서 cd1)을 사용하여 애널리틱스 핑에 offline 플래그를 추가하여 Workbox로 추적 요청을 조작할 수 있습니다.

import * as googleAnalytics from 'workbox-google-analytics';

googleAnalytics.initialize({
  parameterOverrides: {
    cd1: 'offline',
  },
});

인터넷이 다시 연결되기 전에 사용자가 오프라인 상태로 인해 페이지에서 나가면 어떻게 될까요? 이렇게 하면 일반적으로 서비스 워커가 절전 모드로 전환되지만 (연결이 다시 시작될 때 데이터를 전송할 수 없기 때문) Workbox Google 애널리틱스 모듈은 사용자가 탭이나 브라우저를 닫더라도 나중에 다시 연결이 복구되면 분석 데이터를 전송하는 Background Sync 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 이벤트를 수신 대기하고 분석 핑을 전송해야 합니다. 다시 말하지만, 서비스 워커 내에서 오프라인으로 발생하는 분석 요청을 버퍼링해야 합니다. 앞에서 설명한 대로 기본 제공되는 Google 애널리틱스 지원을 위해 workbox-google-analytics 플러그인을 초기화합니다.

다음 예에서는 Google 애널리틱스를 사용하지만 다른 분석 공급업체에 동일한 방식으로 적용할 수 있습니다.

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 애널리틱스에서 실패한 리소스 로드를 추적하며, 보고를 통해 분석할 수 있습니다. 파생된 통계는 일반적으로 서비스 워커 캐싱 및 오류 처리를 개선하여 불안정한 네트워크 조건에서 페이지를 더 강력하고 안정적으로 만드는 데 사용할 수 있습니다.

다음 단계

이 도움말에서는 오프라인 사용을 추적하는 다양한 방법과 각각의 장단점을 설명했습니다. 이렇게 하면 얼마나 많은 사용자가 오프라인으로 전환하고 이로 인해 문제를 겪는지 수치화할 수 있지만 아직 시작에 불과합니다. 웹사이트에서 잘 구축된 오프라인 모드를 제공하지 않는 한 애널리틱스에서 오프라인 사용량이 많지 않을 것입니다.

전체 추적을 설정한 다음 추적 번호를 확인하여 오프라인 기능을 반복적으로 확장하는 것이 좋습니다. 먼저 간단한 오프라인 오류 페이지로 시작하고(Workbox는 간단함), 어차피 맞춤 404 페이지와 유사한 UX 권장사항으로 간주해야 합니다. 그런 다음 고급 오프라인 대체를 향해 나아가고 마지막으로 실제 오프라인 콘텐츠를 향해 나아가세요. 이를 광고하고 사용자에게 잘 설명해야 사용이 늘어날 것입니다 누구나 가끔씩 오프라인 상태가 됩니다.

측정항목을 보고하고 성능 문화를 구축하는 방법여러 부서 간 웹사이트 속도 수정에서 다기능 이해관계자가 웹사이트에 더 많이 투자하도록 설득하는 방법을 알아보세요. 이러한 게시물은 성능에 중점을 두지만 이해관계자의 참여를 유도하는 방법에 대한 일반적인 아이디어를 얻는 데 도움이 될 것입니다.

히어로 사진: JC Gellidon, Unsplash