Đo lường mức sử dụng khi không có mạng

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

Stephan Giesau
Stephan Giesau
Martin Schierle
Martin Schierle

Bài viết này hướng dẫn bạn cách theo dõi mức sử dụng ngoại tuyến của trang web để giúp bạn đư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. Tài liệu này cũng giải thích các vấn đề và cạm bẫy cần tránh khi triển khai số liệu phân tích về mức sử dụng ngoại tuyến.

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

  • 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 tập trung vào quyền riêng tư, nơi bạn nên thu thập ít dữ liệu nhất có thể. Ngoài ra, các sự kiện onlineoffline có thể kích hoạt chỉ trong một phần giây khi mất mạng, điều mà người dùng có thể sẽ không thấy hoặc không nhận thấy.
  • Tính năng theo dõi phân tích hoạt động ngoại tuyến sẽ không bao giờ đến được máy chủ phân tích vì người dùng đang… ngoại tuyến.
  • Việc theo dõi dấu thời gian cục 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 có truy cập lại trang web của bạn hay không. 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ờ quay lại, thì bạn không có cách nào để theo dõi điều đó. Khả năng theo dõi lượt thoát ngoại tuyến là dữ liệu quan trọng để xây dựng 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ì chỉ biết về quyền truy cập mạng chứ không phải 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ó kết nối 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.
  • Nhìn chung, việc không có mạng cũng không có ý nghĩa gì. Là nhà phát triển trang web, bạn nên biết những loại tài nguyên nào không tải được. Điều này đặc biệt phù hợp trong bối cảnh của SPA, trong đó việc mất kết nối mạng có thể không dẫn đến trang lỗi khi không có mạng của trình duyệt (mà người dùng hiểu được) mà nhiều khả năng là các phần động ngẫu nhiên của trang sẽ bị lỗi một cách thầm lặng.

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

Một phương pháp hiệu quả hơn: worker dịch vụ

Giải pháp bật chế độ ngoại tuyến lại là giải pháp hiệu quả hơn để theo dõi mức sử dụng ngoại tuyến. Ý tưởng cơ bản là lưu trữ ping phân tích vào IndexedDB miễn là người dùng đang ngoại tuyến và chỉ gửi lại ping khi người dùng kết nối lại mạng. Đối với Google Analytics, tính năng này đã có sẵn thông qua mô-đun Workbox, nhưng xin lưu ý rằng các lượt truy cập được gửi sau 4 giờ bị trì hoãn có thể sẽ 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 worker dịch vụ dựa trên Workbox bằng hai dòng sau:

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

googleAnalytics.initialize();

Tính năng 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). Để làm việc này, 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 (cd1 trong mã mẫu bên dưới):

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

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

Nếu người dùng rời khỏi trang do đang ngoại tuyến, trước khi kết nối Internet trở lại thì sao? Mặc dù việc này thường khiến worker dịch vụ chuyển sang trạng thái ngủ (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 để gửi dữ liệu phân tích sau khi 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 hạn chế: mặc dù tính năng này giúp tính năng theo dõi hiện có có thể hoạt động ngoại tuyến, nhưng rất có thể bạn 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 ít nhất thì giờ đây, bạn có thể đo lường và định lượng được đ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ính năng tải từng phần

Nếu người dùng truy cập vào một trang được tạo dưới dạng trang web nhiều trang và chuyển sang chế độ ngoại tuyến rồi 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 tạo dưới dạng ứng dụng một trang 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 độ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 trình duyệt khi không có kết nối mạng. Thay vào đó, các phần động của trang sẽ hiển thị lỗi, chuyển sang trạng thái không xác định hoặc chỉ ngừng hoạt động động.

Các hiệu ứng tương tự có thể xảy ra trong các trang web nhiều trang do tính năng tải từng phần. Ví dụ: có thể quá trình tải ban đầu diễn ra khi có kết nối mạng, nhưng người dùng đã chuyển sang trạng thái ngoại tuyến trước khi cuộn. Tất cả nội dung tải từng phần bên dưới màn hình 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 bạn nên theo dõi chúng. Worker là nơi hoàn hảo để phát hiện lỗi mạng và cuối cùng là theo dõi các lỗi đó bằng số liệu phân tích. Với Workbox, bạn có thể định cấu hình một trình xử lý tổng quát để 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 một số tuyến đường 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 bước kiểm tra trong setCatchHandler để lọc URI bằng một biểu thức chính quy. Giải pháp gọn gàng hơn là triển khai registerRoute bằng một trình xử lý tuỳ chỉnh. Thao tác này đóng gói logic nghiệp vụ vào một tuyến riêng biệt, có khả năng bảo trì tốt hơn trong các worker 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, trang cần nghe sự kiện message và gửi ping phân tích. Xin nhắc lại, hãy nhớ lưu vào bộ đệm các yêu cầu phân tích xảy ra khi không có mạng trong worker dịch vụ. Như mô tả trước đó, hãy khởi chạy trình bổ trợ workbox-google-analytics để hỗ trợ Google Analytics tích hợp.

Ví dụ sau đây sử dụng Google Analytics, nhưng bạn cũng có thể áp dụng tương tự cho các nhà cung cấp 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 báo cáo. Thông tin chi tiết phái sinh có thể được dùng để cải thiện việc lưu vào bộ nhớ đệm và xử lý lỗi của trình chạy dịch vụ nói chung, giúp trang hoạt động mạnh mẽ 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ài viết này đã trình bày các cách theo dõi hoạt động sử dụng ngoại tuyến cùng với ưu và khuyết điểm của từng cách. Mặc dù điều này có thể giúp định lượng số lượng người dùng của bạn bị ngắt kết nối và gặp sự cố do đó, nhưng đây mới 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, thì rõ ràng là bạn sẽ không thấy nhiều dữ liệu về lượt sử dụng ngoại tuyến trong số liệu phân tích.

Bạn nên triển khai tính năng theo dõi đầy đủ, sau đó mở rộng các tính năng ngoại tuyến trong các lần lặp lại, đồng thời chú ý đến số liệu theo dõi. Trước tiên, hãy bắt đầu với một trang lỗi ngoại tuyến đơn giản – với Workbox, việc này rất đơn giản – và nên được coi 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 tìm cách hướng đến 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 đến nội dung ngoại tuyến thực sự. Hãy nhớ quảng cáo và giải thích rõ ràng điều này cho người dùng, bạn sẽ thấy mức sử dụng tăng lên. Rốt cuộc, thỉnh thoảng mọi người cũng sẽ không có 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ấtKhắc phục tốc độ trang web trên nhiều chức năng để biết các mẹo thuyết phục các bên liên quan trên nhiều chức năng đầu tư nhiều hơn vào trang web của bạn. Mặc dù các bài đăng đó tập trung vào hiệu suất, nhưng chúng sẽ giúp bạn có ý tưởng chung về cách thu hút các bên liên quan.

Ảnh chính do JC Gellidon chụp trên Unsplash.