Trang này được dịch bởi Cloud Translation API.

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

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 mình cần có trải nghiệm ngoại tuyến tốt hơn.

Stephan Giesau

Martin Schierle

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

Những sai lầm 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 ngoại tuyến là tạo trình nghe sự kiện cho các sự kiện online và offline (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 online và offline 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 kết nối mạng trở lại tuỳ thuộc vào việc người dùng truy cập lại 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ờ 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 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. Đó 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 cần biết những loại tài nguyên không tải được. Điều này đặc biệt cần thiết trong bối cảnh SPA, trong đó kết nối mạng bị gián đoạn 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 được) nhưng có nhiều khả năng khiến các phần động ngẫu nhiên của trang không thành công.

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

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 hoá ra là giải pháp tốt 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 có sẵn thông qua mô-đun Workbox, nhưng lưu ý rằng các lượt truy cập được gửi trễ hơn 4 giờ 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 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). Để thực hiện 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ù điều này thường đặt trình chạy dịch vụ vào chế độ 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 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 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 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 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 việc theo dõi chúng là hợp lý. Worker là nơi lý tưởng để 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, giúp dễ bảo trì 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 theo dõi sự kiện message và gửi ping số liệu 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
      });
    }
  });
}

Tính năng 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, đồng thời có thể phân tích các tài nguyên đó 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 bạn định lượng số lượng người dùng không có kết nối mạng 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 hướng đến các tính năng 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. 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 tham khảo bài viết Cách báo cáo chỉ số và xây dựng văn hoá hiệu suất cũng như Khắc phục tốc độ của 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 liên chức năng đầu tư thêm 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.