Đo lường mức sử dụng ngoại tuyến

Cách theo dõi mức sử dụng ngoại tuyến của trang web để bạn có thể đưa ra lý do tại sao trang web của bạn cần có trải nghiệm ngoại tuyến tốt hơn.

Stephan Giesau
Stephan Giesau
Martin Schierle
Martin Schierle
X GitHub

Tìm hiểu cách theo dõi mức sử dụng trang web khi không có mạng để bạn có thể đưa ra lý do tại sao trang web của bạn cần có chế độ ngoại tuyến tốt hơn. Hiểu rõ những lỗi và vấn đề cần tránh khi triển khai số liệu phân tích về việc sử dụng khi không có mạng.

Những điểm hạn chế của sự kiện trình duyệt trực tuyến và ngoại tuyến

Giải pháp rõ ràng để theo dõi mức sử dụng khi không có mạng là tạo trình nghe sự kiện cho các sự kiện online và offline (được nhiều trình duyệt hỗ trợ) và đưa logic theo dõi số liệu phân tích vào các trình nghe đó. Rất tiếc, có một số vấn đề và hạn chế đối với phương pháp này:

  • Nhìn chung, việc theo dõi mọi sự kiện trạng thái kết nối mạng có thể là quá mức và phản tác dụng trong một thế giới lấy quyền riêng tư làm trung tâm, nơi cần thu thập càng ít dữ liệu càng tốt. Ngoài ra, các sự kiện online và offline có thể kích hoạt chỉ trong một giây mất mạng, điều mà người dùng có thể thậm chí không nhìn thấy hoặc nhận thấy.
  • Dữ liệu theo dõi hoạt động ngoại tuyến của Analytics không đến được máy chủ Analytics.
  • Việc theo dõi dấu thời gian trên thiết bị khi người dùng không có kết nối mạng và gửi hoạt động ngoại tuyến đến máy chủ phân tích khi người dùng có kết nối mạng trở lại phụ thuộc vào việc người dùng truy cập lại vào trang web của bạn. Nếu người dùng rời khỏi trang web của bạn do không có chế độ ngoại tuyến và không bao giờ truy cập lại, thì bạn không có cách nào để theo dõi điều đó. Khả năng theo dõi tỷ lệ bỏ ngang khi không có mạng là dữ liệu quan trọng để xây dựng một trường hợp về lý do trang web của bạn cần có chế độ ngoại tuyến tốt hơn.
  • Sự kiện online không đáng tin cậy lắm vì sự kiện này chỉ biết về quyền truy cập mạng chứ không biết về quyền truy cập Internet. Do đó, người dùng vẫn có thể không có mạng và việc gửi ping theo dõi vẫn có thể không thành công.
  • Ngay cả khi người dùng vẫn ở trên trang hiện tại khi không có mạng, thì không có sự kiện phân tích nào khác (ví dụ: sự kiện cuộn, lượt nhấp, v.v.) được theo dõi, đây có thể là thông tin phù hợp và hữu ích hơn.
  • Chỉ ngoại tuyến thôi thì không có ý nghĩa gì nhiều. Điều quan trọng nhất có lẽ là biết tài nguyên nào không tải được. Điều này đặc biệt phù hợp với các ứng dụng trang đơn (SPA), trong đó kết nối mạng bị rớt có thể không dẫn đến trang lỗi ngoại tuyến của trình duyệt mà người dùng hiểu. Thay vào đó, việc này có thể khiến các phần động, ngẫu nhiên của trang không hoạt động mà không có thông báo.

Bạn vẫn có thể sử dụng giải pháp này để hiểu cơ bản về cách sử dụng khi không có mạng, nhưng cần cân nhắc kỹ nhiều hạn chế và nhược điểm.

Cách tiếp cận hiệu quả hơn: Trình chạy dịch vụ

Giải pháp hỗ trợ chế độ ngoại tuyến cũng là giải pháp tốt hơn để theo dõi mức sử dụng khi không có mạng. Bạn có thể lưu trữ các ping phân tích trong IndexedDB miễn là người dùng ngoại tuyến và gửi lại khi người dùng kết nối mạng trở lại. Đối với Google Analytics, tính năng này đã có sẵn trong mô-đun Workbox, nhưng hãy lưu ý rằng các lượt truy cập được gửi sau bốn giờ trì hoãn có thể không được xử lý.

Ở dạng đơn giản nhất, bạn có thể kích hoạt tính năng này trong một trình chạy dịch vụ dựa trên Workbox bằng hai dòng sau:

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

googleAnalytics.initialize();

Thao tác này theo dõi tất cả sự kiện hiện có và ping lượt xem trang khi không có mạng, nhưng bạn sẽ không biết rằng các sự kiện đó đã xảy ra khi không có mạng vì chúng chỉ được phát lại nguyên trạng. Bạn có thể thao tác với các yêu cầu theo dõi bằng Workbox bằng cách thêm cờ offline vào ping phân tích, sử dụng phương diện tuỳ chỉnh:

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

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

Điều gì sẽ xảy ra nếu người dùng rời khỏi trang do không có mạng, trước khi có kết nối Internet trở lại? Mặc dù điều này thường khiến trình chạy dịch vụ ở trạng thái ngủ, vì trình chạy dịch vụ không thể gửi dữ liệu khi kết nối trở lại, nhưng mô-đun Google Analytics của Workbox sử dụng API Đồng bộ hoá trong nền. Tính năng Đồng bộ hoá trong nền sẽ gửi dữ liệu phân tích khi có kết nối trở lại, ngay cả khi người dùng đóng thẻ hoặc trình duyệt.

Tuy nhiên, vẫn có một nhược điểm: mặc dù điều này giúp cho việc theo dõi hiện tại có thể hoạt động khi không có mạng, nhưng bạn có thể sẽ không thấy nhiều dữ liệu liên quan cho đến khi triển khai chế độ ngoại tuyến cơ bản. Người dùng vẫn sẽ nhanh chóng rời khỏi trang web của bạn khi kết nối bị ngắt. Nhưng giờ đây, ít nhất bạn có thể đo lường và định lượng điều này bằng cách so sánh thời lượng phiên trung bình và mức độ tương tác của người dùng đối với những người dùng đã áp dụng phương diện ngoại tuyến so với người dùng thông thường.

SPA và tải chậm

Nếu người dùng truy cập vào một trang được xây dựng dưới dạng trang web nhiều trang chuyển sang chế độ ngoại tuyến và cố gắng điều hướng, thì trang ngoại tuyến mặc định của trình duyệt sẽ xuất hiện, giúp người dùng hiểu được điều gì đang xảy ra. Tuy nhiên, các trang được xây dựng dưới dạng ứng dụng trang đơn lại hoạt động theo cách khác. Người dùng vẫn ở trên cùng một trang và nội dung mới được tải linh động thông qua AJAX mà không cần thao tác điều hướng trên trình duyệt. Người dùng không thấy trang lỗi của trình duyệt khi chuyển sang chế độ ngoại tuyến. Thay vào đó, các phần động của trang sẽ hiển thị kèm theo lỗi, chuyển sang trạng thái không xác định hoặc chỉ dừng ở trạng thái động.

Hiệu ứng tương tự có thể xảy ra trong các trang web nhiều trang do tải chậm. Ví dụ: có thể lần tải ban đầu diễn ra khi có mạng, nhưng người dùng đã chuyển sang chế độ không có mạng trước khi cuộn. Tất cả nội dung tải chậm bên dưới màn hình đầu tiên sẽ không tải được và bị thiếu.

Vì những trường hợp này thực sự gây khó chịu cho người dùng, nên việc theo dõi chúng là hợp lý. Trình chạy dịch vụ là nơi hoàn hảo để phát hiện lỗi mạng và cuối cùng là theo dõi lỗi bằng số liệu phân tích. Với Workbox, bạn có thể định cấu hình trình xử lý lỗi chung để thông báo cho trang về các yêu cầu không thành công bằng cách gửi một sự kiện thông báo:

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();

  }());
});

Thay vì theo dõi tất cả các yêu cầu không thành công, bạn có thể chỉ phát hiện lỗi trên các tuyến cụ thể. Ví dụ: nếu chỉ muốn báo cáo lỗi xảy ra trên các tuyến đến /products/*, chúng ta có thể thêm một quy trình kiểm tra trong setCatchHandler để lọc URI bằng biểu thức chính quy.

Một giải pháp rõ ràng hơn là triển khai registerRoute bằng một trình xử lý tuỳ chỉnh. Điều này đóng gói logic nghiệp vụ vào một tuyến riêng biệt, với khả năng bảo trì tốt hơn trong các trình chạy dịch vụ phức tạp hơn:

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();
    }
  }
);

Bước cuối cùng là trang cần theo dõi sự kiện message và gửi ping phân tích. Xin nhắc lại, hãy nhớ lưu vào vùng đệm các yêu cầu phân tích xảy ra khi không có mạng trong trình chạy dịch vụ. Như đã mô tả trước đó, hãy khởi chạy trình bổ trợ workbox-google-analytics để được hỗ trợ Google Analytics tích hợp sẵn.

Ví dụ sau đây sử dụng Google Analytics, nhưng bạn có thể áp dụng theo cách tương tự cho các nhà cung cấp dịch vụ phân tích khác.

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
      });
    }
  });
}

Thao tác này sẽ theo dõi các lượt tải tài nguyên không thành công trong Google Analytics, nơi bạn có thể phân tích các lượt tải đó bằng tính năng báo cáo. Bạn có thể sử dụng thông tin chi tiết thu được để cải thiện khả năng lưu vào bộ nhớ đệm của trình chạy dịch vụ và xử lý lỗi nói chung, giúp trang hoạt động hiệu quả và đáng tin cậy hơn trong điều kiện mạng không ổn định.

Các bước tiếp theo

Bạn đã tìm hiểu các cách theo dõi mức sử dụng ngoại tuyến cùng với ưu và nhược điểm của từng cách. Mặc dù điều này có thể giúp định lượng số người dùng ngoại tuyến và gặp sự cố do việc này, nhưng đây vẫn chỉ là bước khởi đầu. Miễn là trang web của bạn không cung cấp chế độ ngoại tuyến được xây dựng tốt, bạn rõ ràng sẽ không thấy nhiều mức sử dụng ngoại tuyến trong số liệu phân tích.

Bạn nên thiết lập tính năng theo dõi đầy đủ, sau đó mở rộng khả năng ngoại tuyến theo các lần lặp lại, tập trung vào việc theo dõi. Bắt đầu bằng một trang lỗi ngoại tuyến. Bạn có thể dễ dàng tạo trang này bằng Workbox và đây là một phương pháp hay nhất về trải nghiệm người dùng, tương tự như các trang 404 tuỳ chỉnh. Sau đó, hãy nỗ lực hướng tới các phương án dự phòng ngoại tuyến nâng cao hơn và cuối cùng là hướng tới nội dung ngoại tuyến thực sự. Hãy đảm bảo bạn quảng cáo và giải thích rõ điều này cho người dùng, nhờ đó bạn sẽ thấy mức sử dụng tăng lên. Sau cùng, ai cũng có lúc không kết nối mạng.

Hãy xem bài viết Cách báo cáo chỉ số và xây dựng văn hoá hiệu suất và Khắc phục tốc độ trang web theo cách liên chức năng để biết các mẹo thuyết phục các bên liên quan liên chức năng đầu tư nhiều hơn vào trang web của bạn. Mặc dù những bài đăng đó tập trung vào hiệu suất, nhưng chúng sẽ giúp bạn có được ý tưởng chung về cách thu hút các bên liên quan.