Web Workers vs Service Workers: chúng là gì và tại sao

Web Workers vs Service Workers: tổng quan nhanh

Trình duyệt chạy phần lớn JavaScript của bạn trên luồng chính—cùng nơi xử lý input người dùng, hoạt ảnh và vẽ trang. Khi có công việc nặng ở đó (phân tích dữ liệu lớn, xử lý ảnh, tính toán phức tạp), UI có thể giật hoặc “đứng yên”. Workers tồn tại để chuyển một số tác vụ ra khỏi luồng chính hoặc ra khỏi quyền điều khiển trực tiếp của trang, để app của bạn vẫn giữ được độ phản hồi.

Vấn đề mà workers giải quyết

Nếu trang của bạn đang bận thực hiện một phép tính 200ms, trình duyệt không thể cuộn mượt, phản hồi click, hoặc giữ animation ở 60fps. Workers giúp bằng cách cho phép bạn làm công việc nền trong khi luồng chính tập trung vào giao diện.

Định nghĩa nhanh

Một Web Worker là một thread JavaScript nền mà bạn tạo từ một trang. Nó phù hợp cho các tác vụ nặng CPU mà nếu chạy trên luồng chính sẽ chặn UI.

Một Service Worker là một loại worker đặc biệt nằm giữa web app và mạng. Nó có thể chặn request, cache response, và cho phép các tính năng như hỗ trợ offline và thông báo đẩy.

Mô hình tư duy đơn giản: “thread” vs “proxy mạng”

Hãy nghĩ Web Worker như một trợ lý làm phép tính ở phòng khác. Bạn gửi tin nhắn, nó làm việc, rồi trả kết quả.

Hãy nghĩ Service Worker như một bảo vệ ở cửa chính. Các request cho trang, script, và API đi qua nó, và nó có thể quyết định lấy từ mạng, phục vụ từ cache, hoặc trả về một phản hồi tùy chỉnh.

Bạn sẽ học gì trong bài này

Cuối bài, bạn sẽ biết:

• khi nào web worker là công cụ phù hợp cho hiệu năng (và những gì nó không thể truy cập)
• điều service worker mang lại cho caching offline, cập nhật và hành vi PWA
• cách messaging (như postMessage) phù hợp vào mô hình worker, và tại sao Cache Storage API quan trọng cho offline

Phần tổng quan này đặt ra “tại sao” và mô hình tư duy—tiếp theo chúng ta sẽ đi sâu vào cách từng loại worker hoạt động và vị trí của chúng trong dự án thực tế.

Tại sao trình duyệt có workers

Khi bạn mở một trang web, hầu hết những gì bạn “cảm nhận” xảy ra trên luồng chính. Nó chịu trách nhiệm vẽ pixel (rendering), phản ứng với thao tác chạm và click (input), và chạy nhiều JavaScript.

Luồng chính giống một hàng thanh toán chung

Bởi vì rendering, xử lý input và JavaScript thường luân phiên trên cùng một luồng, một tác vụ chậm có thể khiến mọi thứ khác phải chờ. Đó là lý do các vấn đề hiệu năng thường biểu hiện bằng vấn đề phản hồi, không chỉ “mã chạy chậm”.

Cảm giác khi bị “block” đối với người dùng:

• Cuộn bị giật (jank)
• Nút không phản hồi ngay khi bấm
• Gõ bị trễ so với bàn phím
• Hoạt ảnh bị đứng trong chốc lát

Async không đồng nghĩa với song song

JavaScript có nhiều API bất đồng bộ—fetch(), timers, events—giúp bạn tránh chờ vô ích. Nhưng async không khiến công việc nặng tự nhiên chạy cùng lúc với rendering.

Nếu bạn thực hiện tính toán tốn kém (xử lý ảnh, phân tích JSON lớn, crypto, lọc phức tạp) trên luồng chính, nó vẫn cạnh tranh với cập nhật UI. “Async” có thể trì hoãn khi nó chạy, nhưng có thể vẫn chạy trên cùng luồng chính và vẫn gây jank khi thực sự thực thi.

Workers nằm ở đâu trong kiến trúc trình duyệt

Workers tồn tại để trình duyệt giữ trang phản hồi trong khi vẫn làm công việc có ý nghĩa.

• Web Workers cho phép bạn chạy JavaScript trên một thread nền cho các tác vụ nặng CPU.\n- Service Workers chạy tách biệt khỏi bất kỳ trang nào, đóng vai trò như lớp mạng và caching có thể hoạt động ngay cả khi trang không mở.

Tóm lại: workers là cách bảo vệ luồng chính để app của bạn giữ tương tác trong khi thực hiện công việc nền thực thụ.

Web Worker là gì?

Một Web Worker là cách để chạy JavaScript ra khỏi luồng chính. Thay vì cạnh tranh với công việc UI (rendering, cuộn, phản hồi click), một worker chạy trên thread nền riêng để các tác vụ nặng có thể hoàn thành mà không làm trang cảm thấy “kẹt”.

Hãy coi nó như: trang giữ nhiệm vụ tương tác người dùng, trong khi worker xử lý công việc nặng về CPU như phân tích file lớn, tính toán số liệu, hoặc chuẩn bị dữ liệu cho biểu đồ.

Chạy ở đâu

Web Worker chạy trong một thread riêng với global scope riêng. Nó vẫn có quyền truy cập vào nhiều web API (timers, fetch trên nhiều trình duyệt, crypto, v.v.), nhưng được tách biệt chủ ý khỏi trang.

Dedicated Worker vs Shared Worker

Có vài biến thể phổ biến:

• Dedicated Worker: kết nối với một trang/tab duy nhất. Khi trang đó đóng, worker thường bị kết thúc.\n- Shared Worker: có thể được chia sẻ bởi nhiều trang/tab cùng origin, hữu ích để điều phối công việc giữa các tab (ví dụ dùng chung một connection hoặc đồng bộ trạng thái).

Nếu bạn chưa từng dùng workers, hầu hết ví dụ bạn thấy sẽ là dedicated workers.

Web Workers giao tiếp như thế nào

Workers không gọi trực tiếp hàm trong trang. Thay vào đó, giao tiếp diễn ra bằng gửi tin nhắn:

• Trang gửi dữ liệu tới worker bằng postMessage().\n- Worker trả lời cũng bằng postMessage().\n- Dữ liệu được truyền theo structured clone algorithm, hỗ trợ nhiều kiểu (objects, arrays, strings, numbers, Maps/Sets, ArrayBuffers, v.v.).

Với dữ liệu nhị phân lớn, bạn có thể cải thiện hiệu năng bằng cách chuyển quyền sở hữu một ArrayBuffer (để nó không bị sao chép), giúp truyền tin vẫn nhanh.

Những giới hạn phổ biến (vì thiết kế)

Do worker bị cô lập, có vài ràng buộc chính:

• Không truy cập DOM trực tiếp: worker không thể đọc hoặc thay đổi HTML, CSS hay layout của trang.\n- Global khác nhau: bạn không có window hay document. Workers chạy dưới self (worker global scope), và các API có mặt có thể khác so với luồng chính.\n- Tư duy bất đồng bộ: vì mọi thứ dựa trên message, bạn cấu trúc mã theo kiểu gửi công việc vào và nhận kết quả trả về.

Dùng đúng cách, Web Worker là một trong những cách đơn giản nhất để cải thiện hiệu năng luồng chính mà không thay đổi hành vi app—chỉ là thay đổi chỗ thực hiện công việc nặng.

Khi nào nên dùng Web Workers (và khi nào không)

Web Workers phù hợp khi trang cảm thấy “kẹt” vì JavaScript đang làm quá nhiều việc trên luồng chính. Luồng chính cũng chịu trách nhiệm tương tác người dùng và rendering, nên các tác vụ nặng ở đó có thể gây jank, click trễ và cuộn bị đóng băng.

Những trường hợp phù hợp với Web Workers

Dùng Web Worker khi bạn có công việc nặng CPU và không cần truy cập DOM:

• Tính toán nặng: mô phỏng, tính toán, xử lý số liệu.\n- Phân tích và biến đổi: parse JSON lớn, parse CSV, validation schema.\n- Nén / giải nén: công việc kiểu zip/gzip, mã hóa/giải mã.\n- Xử lý ảnh: thay đổi kích thước, filter, tạo thumbnail (thường kết hợp với OffscreenCanvas trên các trình duyệt hỗ trợ).

Ví dụ thực tế: nếu bạn nhận một payload JSON lớn và việc parse khiến UI giật, hãy chuyển việc parse vào worker rồi gửi kết quả về.

Mẹo xử lý dữ liệu (để nhanh)

Giao tiếp với worker qua postMessage. Với dữ liệu nhị phân lớn, ưu tiên transferable objects (như ArrayBuffer) để trình duyệt có thể chuyển quyền sở hữu bộ nhớ cho worker thay vì sao chép:

// main thread
worker.postMessage(buffer, [buffer]); // transfers the ArrayBuffer

Điều này đặc biệt hữu ích cho audio buffers, bytes ảnh, hoặc khối dữ liệu lớn khác.

Khi không nên dùng Web Workers

Workers có chi phí: file bổ sung, truyền thông tin qua message, và luồng debug khác. Không dùng khi:

• Tác vụ rất nhỏ (vài ms) và không thường xuyên.\n- Công việc cần đọc/ghi DOM thường xuyên (workers không thể chạm DOM).\n- Bạn cần độ trễ hai chiều cực thấp; ping-pong postMessage liên tục có thể xóa lợi ích.

Quy tắc đơn giản

Nếu một tác vụ có thể gây pause có thể nhận ra (thường ~50ms+) và có thể biểu diễn như “input → compute → output” mà không cần DOM, Web Worker thường đáng dùng. Nếu chủ yếu là cập nhật UI, giữ trên luồng chính và tối ưu ở đó.

Service Worker là gì?

Một Service Worker là một file JavaScript đặc biệt chạy trong nền của trình duyệt và hoạt động như một lớp mạng có thể lập trình cho site của bạn. Thay vì chạy trong trang, nó nằm giữa web app và mạng, cho phép bạn quyết định gì xảy ra khi app yêu cầu tài nguyên (HTML, CSS, API, ảnh).

Vòng đời cơ bản (register → install → activate → control)

Service Worker có vòng đời tách biệt khỏi bất kỳ tab nào:

• Register: trang báo cho trình duyệt “site này có service worker” (thường từ JS chính).\n- Install: trình duyệt tải xuống và chạy bước install, thường dùng để pre-cache file quan trọng.\n- Activate: worker mới tiếp quản, thường sau khi đóng các tab cũ hoặc khi an toàn để thay thế phiên bản cũ.\n- Control: khi active, nó có thể “control” các trang trong scope của nó và bắt đầu chặn request.

Bởi vì nó có thể bị dừng và khởi động lại bất kỳ lúc nào, hãy coi nó như một script sự kiện: làm việc nhanh, lưu trạng thái vào bộ nhớ bền, và tránh giả định rằng nó luôn chạy.

Scope và quy tắc origin (ở mức cao)

Service Workers bị giới hạn cùng origin (cùng domain/protocol/port) và chỉ điều khiển các trang trong scope của nó—thường là thư mục nơi file worker được phục vụ (và các đường dẫn con). Chúng cũng yêu cầu HTTPS (trừ localhost) vì chúng có thể ảnh hưởng tới request mạng.

Các API hay dùng

• Fetch event: chặn các request và quyết định lấy từ mạng, cache, hoặc trả phản hồi tùy chỉnh.\n- Cache Storage API: lưu và lấy các response để sử dụng offline và tăng tốc.\n- Clients API: giao tiếp với và quản lý các tab/window mà worker điều khiển.

Service Worker được dùng để làm gì

Service Worker chủ yếu dùng để đứng giữa app và mạng. Nó có thể quyết định khi nào dùng mạng, khi nào dùng dữ liệu cache, và thực hiện chút công việc nền—không chặn trang.

Hỗ trợ offline (caching thông minh)

Nhiệm vụ phổ biến nhất là hỗ trợ offline hoặc trải nghiệm khi kết nối yếu bằng cách cache tài nguyên và response.

Một vài chiến lược caching thực tế:

• Cache-first: tốt cho file tĩnh (CSS, JS, logo). Nhanh, hoạt động offline.\n- Network-first: phù hợp cho nội dung thay đổi thường xuyên (tin tức, feed). Dự phòng cache khi offline.\n- Stale-while-revalidate: hiển thị nội dung cache ngay, rồi làm mới trong nền cho lần tới.

Điều này thường được triển khai bằng Cache Storage API và xử lý sự kiện fetch.

Tăng tốc lần truy cập lặp lại

Service Workers cải thiện cảm nhận tốc độ khi quay lại bằng cách:

• Precaching: lưu các file “cần có” trong quá trình cài đặt (thường gọi là app shell).\n- Runtime caching: cache các trang hoặc response API khi người dùng điều hướng.

Kết quả là ít request mạng hơn, khởi động nhanh hơn và hiệu năng ổn định trên kết nối yếu.

Tính năng nền (khi được hỗ trợ)

Service Workers có thể cung cấp tính năng nền như push notifications và background sync (sự hỗ trợ khác nhau tùy trình duyệt). Điều đó có nghĩa bạn có thể thông báo người dùng hoặc thử lại request thất bại sau—even nếu trang không mở.

Những thành phần xây dựng PWA

Nếu bạn xây progressive web app, Service Workers là phần cốt lõi cho:

• Khả năng cài đặt (kết hợp với web app manifest)\n- Trang offline tin cậy (ví dụ fallback thân thiện)\n- Mô hình app shell cho điều hướng nhanh

Khác biệt chính: Web Worker vs Service Worker

Nếu chỉ nhớ một điều: Web Workers giúp trang làm việc nặng mà không làm đóng băng UI, trong khi Service Workers giúp app kiểm soát request mạng và hoạt động như một app có thể cài đặt (PWA).

Chạy ở đâu (và để làm gì)

Web Worker dành cho tác vụ nặng CPU—phân tích dữ liệu lớn, tạo thumbnail, tính toán—để luồng chính vẫn phản hồi.

Service Worker dành cho xử lý request và nhiệm vụ vòng đời app—hỗ trợ offline, chiến lược cache, background sync, push notifications. Nó có thể đứng giữa app và mạng.

Vòng đời và “ai quản lý”

Web Worker thường liên kết với một trang/tab. Khi trang đóng, worker thường kết thúc (trừ các trường hợp đặc biệt như SharedWorker).

Service Worker là event-driven. Trình duyệt có thể khởi động nó để xử lý một sự kiện (ví dụ fetch hoặc push), rồi dừng khi rảnh. Điều đó có nghĩa nó có thể chạy ngay cả khi không có tab nào mở, miễn là có sự kiện kích hoạt.

Quyền kiểm soát mạng

Web Worker không thể chặn request mà trang thực hiện. Nó có thể fetch() dữ liệu, nhưng không thể ghi đè, cache, hoặc phục vụ phản hồi cho phần khác của site.

Service Worker có thể chặn request mạng (qua sự kiện fetch), quyết định đi ra mạng, trả từ cache, hoặc trả fallback.

Lưu trữ và caching

Web Worker không quản lý cache HTTP cho app của bạn.

Service Worker thường dùng Cache Storage API để lưu và phục vụ cặp request/response—đây là nền tảng cho caching offline và tải lại nhanh.

Cách thiết lập (ở mức cao)

Chạy một worker chủ yếu liên quan đến nó chạy ở đâu và nó được tải như thế nào. Web Workers được tạo trực tiếp bởi script trang. Service Workers được trình duyệt cài đặt và đứng “trước” các request mạng của site.

Web Worker: tạo từ trang

Web Worker được khởi tạo khi trang tạo một worker. Bạn chỉ định tới một file JS riêng, rồi giao tiếp qua postMessage.

// main.js (chạy trên trang)
const worker = new Worker('/workers/resize-worker.js', { type: 'module' });

worker.postMessage({ action: 'start', payload: { /* ... */ } });

worker.onmessage = (event) => {
  console.log('From worker:', event.data);
};

Mô hình tư duy tốt: file worker chỉ là một URL script khác mà trang có thể fetch, nhưng nó chạy ngoài luồng chính.

Service Worker: đăng ký (một lần) và để trình duyệt cài đặt

Service Workers phải được đăng ký từ một trang mà người dùng truy cập:

// main.js
if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js');
}

Sau khi đăng ký, trình duyệt xử lý vòng đời install/activate. sw.js có thể lắng nghe event như install, activate, và fetch.

Tại sao Service Workers yêu cầu HTTPS

Service Workers có thể chặn request mạng và cache response. Nếu đăng ký được cho phép qua HTTP, kẻ tấn công có thể thay thế sw.js độc hại và kiểm soát các lần truy cập sau. HTTPS (hoặc http://localhost khi dev) bảo vệ script và traffic mà nó có thể ảnh hưởng.

Tư duy phiên bản: coi file worker như “release” deploy

Trình duyệt cache và cập nhật workers khác với script trang bình thường. Lên kế hoạch cập nhật:

• Thay file khi hành vi thay đổi (thường bằng cách deploy sw.js/bundle worker mới).\n- Với Service Workers, mong có flow “update”: worker mới cài rồi activate khi an toàn.\n- Khi thay đổi quy tắc caching, thêm logic cleanup trong activation để cache cũ không tồn đọng.

Nếu bạn muốn rollout mượt hơn, xem /blog/debugging-workers cho thói quen test bắt sớm các edge case cập nhật.

Debug và test workers trong trình duyệt

Workers lỗi theo cách khác với JavaScript trang: chúng chạy trong context riêng, có console riêng, và có thể bị trình duyệt khởi động lại. Một quy trình debug tốt sẽ cứu bạn hàng giờ làm việc.

Debug Web Worker (DevTools)

Mở DevTools và tìm target worker. Trong Chrome/Edge, bạn thường thấy workers liệt kê dưới Sources (hoặc qua “Dedicated worker”) và trong bộ chọn context của Console.

Dùng cùng công cụ như trên luồng chính:

• Console logging: log từ Web Worker xuất hiện trong DevTools, nhưng đảm bảo bạn đang xem đúng context.\n- Breakpoints: đặt breakpoint trong script worker; từng bước qua onmessage và các hàm chạy dài.\n- Profiling hiệu năng: ghi trace Performance và xác nhận luồng chính vẫn phản hồi trong khi worker làm việc.

Nếu tin nhắn có vẻ “mất”, kiểm tra cả hai phía: xác minh bạn gọi worker.postMessage(...), worker có self.onmessage = ..., và cấu trúc tin nhắn khớp.

Debug Service Worker (Application panel)

Service Workers debug tốt nhất trong Application panel:

• Kiểm tra registration status, scope, và các phiên bản active/waiting/installed.\n- Dùng controls như Skip waiting và Unregister để reset trạng thái.\n- Bật Update on reload để tránh đuổi theo code cũ khi lặp.

Cũng xem Console cho lỗi install/activate/fetch—chúng thường giải thích tại sao caching hoặc offline không hoạt động.

Những lỗi thường gặp và mẹo test

Vấn đề cache là nguyên nhân tốn thời gian nhất: cache sai file (hoặc quá mạnh tay) có thể giữ HTML/JS cũ. Khi test, thử hard reload và xác nhận điều gì thực sự được phục vụ từ cache.

Để test thực tế, dùng DevTools để:

• mô phỏng Offline và xác minh trang fallback\n- bật network throttling\n- reload nhiều lần để kiểm tra cập nhật Service Worker và xử lý message

Nếu bạn lặp nhanh trên một PWA, tạo một app baseline sạch (với Service Worker và output build dự đoán) rồi tinh chỉnh chiến lược cache từ đó sẽ giúp. Platforms like Koder.ai có thể hữu ích cho việc này: bạn có thể prototype một React-based web app từ prompt chat, xuất source, rồi tinh chỉnh worker và quy tắc cache với vòng phản hồi chặt hơn.

Bảo mật, quyền riêng tư và cân nhắc hiệu năng

Workers có thể làm app mượt và mạnh hơn, nhưng chúng cũng thay đổi nơi mã chạy và những gì nó có thể truy cập. Một kiểm tra nhanh về bảo mật, quyền riêng tư và hiệu năng sẽ tránh bug bất ngờ—và người dùng khó chịu.

Ranh giới bảo mật (và tại sao cùng-origin quan trọng)

Cả Web Workers và Service Workers bị giới hạn bởi same-origin policy: chúng chỉ tương tác trực tiếp với tài nguyên cùng scheme/host/port (trừ khi server cho phép cross-origin qua CORS). Điều này ngăn worker lặng lẽ lấy dữ liệu từ site khác rồi trộn vào app của bạn.

Service Workers có thêm biện pháp bảo vệ: thường yêu cầu HTTPS (hoặc localhost khi dev) vì chúng có thể chặn request mạng. Đối xử chúng như mã có đặc quyền: giữ dependencies tối thiểu, tránh tải mã động, và version logic caching cẩn thận để cache cũ không tiếp tục phục vụ file lỗi thời.

Quyền riêng tư và kỳ vọng người dùng

Các tính năng nền nên cảm thấy dễ đoán. Push notifications rất mạnh, nhưng hộp thoại cấp phép dễ bị lạm dụng.

Hãy hỏi phép chỉ khi có lợi rõ ràng (ví dụ sau khi người dùng bật cảnh báo trong cài đặt), và giải thích họ sẽ nhận gì. Nếu bạn sync hoặc prefetch dữ liệu nền, nói rõ bằng ngôn ngữ đơn giản—người dùng để ý hoạt động mạng bất ngờ hoặc thông báo.

Rủi ro hiệu năng cần theo dõi

Workers không miễn phí về hiệu năng. Dùng quá tay có thể phản tác dụng:

• Chi phí message: gọi postMessage thường xuyên (đặc biệt với object lớn) có thể là cổ chai. Ưu tiên gom lô và dùng transferables khi phù hợp.\n- Chi phí bộ nhớ: mỗi worker có bộ nhớ và chi phí khởi tạo; quá nhiều worker tăng RAM và tiêu pin.\n- Tăng trưởng cache: Service Worker cache quá mạnh có thể làm đầy bộ nhớ. Thêm giới hạn cache và cleanup khi cập nhật.

Fallback nhẹ nhàng

Không mọi trình duyệt đều hỗ trợ mọi khả năng (hoặc người dùng chặn quyền). Kiểm tra tính năng và degrade mượt:

if ('serviceWorker' in navigator) {
  // register service worker
} else {
  // continue without offline features
}

Mục tiêu: chức năng cốt lõi vẫn hoạt động, với các “nice-to-have” (offline, push, tính toán nặng) thêm vào khi có sẵn.

Mẫu phổ biến dùng cả hai cùng nhau

Web Workers và Service Workers giải quyết các vấn đề khác nhau, nên chúng kết hợp tốt khi app cần cả tính toán nặng và tải nhanh, tin cậy. Mô hình tư duy: Web Worker = compute, Service Worker = mạng + caching, luồng chính = UI.

Mẫu 1: Xử lý ảnh + gallery offline

Giả sử app cho phép người dùng chỉnh sửa ảnh (resize, filter, xóa nền) và xem gallery sau khi offline.

• Web Worker làm công việc nặng CPU (decode, transform, tạo thumbnails) để cuộn và tương tác vẫn mượt.\n- Service Worker cache các thumbnail và file gốc trong Cache Storage (hoặc metadata trong IndexedDB) và phục vụ chúng ngay lập tức khi truy cập lại hoặc khi offline.

Cách tiếp cận “compute rồi cache” giữ trách nhiệm rõ ràng: worker tạo ra đầu ra, service worker quyết định lưu và phục vụ.

Mẫu 2: Đồng bộ dữ liệu + caching nền

Với app có feed, form, hoặc dữ liệu trường:

• Web Worker có thể chuẩn hóa payload JSON lớn, thực hiện diffing, hoặc validate dữ liệu mà không chặn UI.\n- Service Worker cache response API để khởi động nhanh và cho phép đọc khi offline. Khi có kết nối, nó có thể làm mới cache và (nếu có hỗ trợ) phối hợp background sync.

Ngay cả khi không có full background sync, service worker vẫn cải thiện cảm nhận bằng cách phục vụ response cache trong khi app cập nhật nền.

Giữ trách nhiệm tách bạch

Tránh trộn vai trò:

• Luồng UI: rendering, input người dùng, accessibility, wiring state tối thiểu.\n- Web Worker: tính toán thuần túy và chuẩn bị dữ liệu (thường qua postMessage).\n- Service Worker: định tuyến request, chiến lược caching, fallback offline.

Checklist nhanh: cần cái nào?

• Tác vụ có nặng CPU (parse, encode, crypto, xử lý ảnh/âm thanh)? Dùng Web Worker.\n- Tác vụ liên quan chặn fetch, offline, hoặc caching? Dùng Service Worker.\n- Cần cả UI mượt và tải/offline nhanh? Dùng cả hai, nhưng giữ ranh giới rõ: compute trong web worker, lưu/phục vụ qua service worker.

FAQ: các câu hỏi thực tiễn hay gặp

Service Worker có truy cập DOM được không?

Không. Service Worker chạy trong nền, tách biệt khỏi bất kỳ tab trang nào, và không có quyền truy cập DOM (các phần tử HTML của trang).

Sự tách biệt này có chủ ý: Service Workers được thiết kế để vẫn hoạt động ngay cả khi không có trang mở (ví dụ phản hồi một sự kiện push hoặc phục vụ file cache). Vì có thể không có document đang hoạt động để thao tác, trình duyệt giữ nó cô lập.

Nếu Service Worker cần ảnh hưởng tới giao diện người dùng, nó giao tiếp với trang qua messaging (ví dụ postMessage) để trang cập nhật UI.

Tôi có cần Service Worker để dùng Web Worker không?

Không. Web Workers và Service Workers độc lập.

• Web Worker: dùng để chuyển công việc nặng khỏi luồng chính (parse, tính toán, xử lý ảnh) nhằm giữ UI phản hồi.\n- Service Worker: dùng cho tính năng mạng (offline, caching, intercept request, background sync, push).

Bạn có thể dùng riêng từng loại, hoặc cả hai nếu app cần cả tính toán nền và tính năng mạng/offline.

Workers được hỗ trợ ở mọi nơi không?

Trong các trình duyệt hiện đại, Web Workers được hỗ trợ rộng rãi và thường là lựa chọn nền tảng an toàn hơn.

Service Workers cũng được hỗ trợ rộng rãi trên các trình duyệt chính hiện nay, nhưng có thêm yêu cầu và trường hợp biên:

• Yêu cầu HTTPS (trừ localhost khi phát triển).\n- Một số tính năng (như push notifications) khác nhau theo trình duyệt và nền tảng.

Nếu cần tương thích rộng, coi Service Worker như nâng cấp tiến bộ: xây trải nghiệm lõi tốt trước, rồi thêm offline/push khi có thể.

Điều này có tự động làm site tôi nhanh hơn không?

Không tự động.

• Web Worker hữu ích khi site của bạn chậm do JavaScript nặng trên luồng chính. Chuyển công việc đó có thể giảm jank và cải thiện phản hồi—nhưng bạn vẫn phải trả chi phí truyền dữ liệu qua message.\n- Service Worker hữu ích khi site chậm do request mạng. Caching và xử lý fetch thông minh có thể làm cảm giác lần truy cập sau nhanh ngay lập tức—nhưng cache sai có thể gây nội dung lỗi thời.

Lợi ích thực sự đến từ dùng đúng worker cho nút cổ chai đúng, và đo lường trước/sau.