JavaScript Insights

🔬 Background Services Lab

Welcome to the Background Services lab! In this hands-on session you'll use the Application panel to inspect, debug, and interact with browser background services. Each exercise gives you a specific task — complete them all to master the Application panel's background services section.

⚙️ Setup

Open DevTools (F12) and go to the Application panel
In the sidebar, expand Background services
Start the record button (⏺) in each section before interacting with the exercises
Keep the Console open in a split view so you can see logs too

Exercise 1: Back/Forward Cache Detective 🔍

Easy

Goal: Understand which pages are bfcache-eligible and which aren't.

Tasks:

Open Application → Back/forward cache Click "Test back/forward cache" on this page Record the result — was it eligible? Write which reason(s) blocked it, if any Navigate to bfcache-good.html and test again Navigate to bfcache-bad.html and test again Compare the results — what makes a page bfcache-incompatible?

💡 Hint

The "bad" page uses beforeunload and an open WebSocket — both block bfcache. The test in DevTools lists each blocker individually.

✅ Expected Answer

bfcache-good.html: Should be eligible (no blockers). State (counter, timer) is preserved when navigating back.

bfcache-bad.html: Not eligible. Blockers include: beforeunload event listener, and (if toggled on) an active WebSocket connection.

Exercise 2: Background Sync Spy 🕵️

Medium

Goal: Register, observe, and manually trigger background sync events.

Tasks:

Go to Application → Background services → Background Sync Start recording (⏺) Type a message below and click "Queue & Sync" Observe the sync event in DevTools — note the tag and timestamp Go to Network panel, check "Offline", then queue another message Uncheck "Offline" — does the pending sync fire automatically? Go to Application → Service Workers and find the Sync input. Type a tag and trigger it manually

💡 Hint

When offline, sync.register() still succeeds — the browser stores the tag and fires the sync event as soon as connectivity returns. You can also fire it manually from the Service Workers section.

✅ Expected Answer

The Background Sync panel shows events with tags like sync-msg-{timestamp}. When offline, the sync is queued. When back online, the browser fires the sync event and you see the event appear in the timeline. Manual trigger from SW panel also fires the event.

Exercise 3: Notification Inspector 🔔

Medium

Goal: Send notifications, observe them in DevTools, and understand tags.

Tasks:

Go to Application → Background services → Notifications Start recording (⏺) Click "Grant Permission" below, then send a notification In DevTools, find the notification event — what data does it show? Send two notifications with the same tag — what happens? Send two notifications with different tags — what happens? Click on a notification and check if a notificationclick event appears Close a notification and check for a notificationclose event

unknown

💡 Hint

When two notifications share the same tag, the second one replaces the first. Different tags stack as separate notifications.

✅ Expected Answer

Same-tag notifications replace each other (only the latest is visible). Different-tag notifications all appear separately. DevTools Notifications panel shows notificationdisplay, notificationclick, and notificationclose events with their tags, titles, and timestamps.

Exercise 4: Push Messaging Lab 📬

Hard

Goal: Subscribe to push, examine the subscription, and simulate push messages from DevTools.

Tasks:

Go to Application → Background services → Push Messaging and start recording Click "Subscribe" below to create a push subscription Inspect the subscription details — find the endpoint and keys Go to Application → Service Workers Find the "Push" text input next to your service worker Type {"title":"Manual Push","body":"Sent from DevTools!"} and click Push Did a notification appear? Check the Push Messaging timeline for the event Unsubscribe and try pushing again — what happens?

No active subscription

💡 Hint

The Push input in the Service Workers section sends a simulated push event to the SW. The SW's push event handler receives the text you typed and can show a notification. After unsubscribing, pushing still works from DevTools (the push event goes to the SW regardless of subscription state).

✅ Expected Answer

The subscription shows an endpoint URL (e.g., https://fcm.googleapis.com/...) and encryption keys (p256dh, auth). Simulating a push from DevTools Service Workers panel fires the push event and shows a notification. Even after unsubscribing, the DevTools push button still fires the event because it bypasses the push service.

Exercise 5: Speculative Loads Inspector 🔮

Medium

Goal: Add speculation rules and observe them in the Application panel.

Tasks:

Go to Application → Background services → Speculative loads Note the current speculation rules on this page (there should be one for prefetch) Click "Add Prefetch Rule" — does a new rule appear in DevTools? Click "Add Prerender Rule" — how does prerender differ from prefetch in the panel? Hover over the links below — do any speculation events trigger? Check the Network panel — can you find prefetched resources? Click "Remove Rules" and verify they disappear from the panel

Links for speculation:

bfcache-good.html bfcache-bad.html Application Home

💡 Hint

In the Speculative Loads panel, each rule shows its type (prefetch/prerender), the URLs it applies to, and the current status (Not triggered, Running, Ready, or Failure). Prefetched resources appear in the Network panel with a special Purpose: prefetch header.

✅ Expected Answer

The panel lists each speculation rule with its type and target URLs. Dynamic rules appear when added and disappear when removed. Prerender rules show a full page load in a hidden renderer, while prefetch only downloads HTML. In the Network panel, prefetched requests have the type "prefetch".

Exercise 6: Reporting API Observer 📊

Easy

Goal: Trigger browser reports and observe them in the Application panel.

Tasks:

Open Application → Background services → Reporting API Click "Trigger Deprecation" below Check both the Application panel and the Console — where do reports appear? How many reports were generated? What type are they? Click "Check Captured Reports" to see what ReportingObserver caught

0 reports

💡 Hint

Deprecation reports are generated when using APIs the browser considers deprecated. ReportingObserver captures these in JavaScript. The Console also shows deprecation warnings separately.

✅ Expected Answer

Clicking "Trigger Deprecation" uses deprecated APIs (synchronous XHR, etc.) which generate deprecation reports. These appear in the Console as warnings and are captured by ReportingObserver. The Application panel's Reporting API section shows the collected reports with type, URL, and body details.

Exercise 7: Service Worker Lifecycle Master 🎓

Hard

Goal: Understand the SW lifecycle using the Application panel's Service Workers section.

Tasks:

Go to Application → Service Workers Find the registered service worker — what is its status? (installing/waiting/activated) Click "Update" — what happens to the version number and status? Check "Update on reload" — how does this change the behavior? Click "Unregister" — then refresh the page. Does it re-register? Click "Network requests" to see what the service worker is fetching Use the Push, Sync, and Periodic Sync inputs to manually trigger events

💡 Hint

The service worker on this page uses skipWaiting() and clients.claim(), so it activates immediately without waiting. "Update on reload" forces a SW update on every page refresh — useful for development but not for production.

✅ Expected Answer

Status is "activated and is running". Clicking Update installs a new version (if the file changed). skipWaiting() causes immediate activation. Unregister removes the SW but it re-registers on refresh because the page script calls navigator.serviceWorker.register(). Push/Sync/Periodic Sync inputs let you manually fire corresponding events on the SW.

🏆 Bonus Challenge: Full Investigation

Hard

Combine everything you've learned! Perform a full background services investigation:

Tasks:

Start recording in ALL background service panels simultaneously Queue a sync, send a notification, and add speculation rules — all at once Go offline (Network → Offline), try syncing, then go back online Test bfcache on both the good and bad pages Navigate through the speculation links — which pages load faster? Take a screenshot of each panel showing recorded events Write a one-paragraph summary of what you observed

💡 Pro Tips

Recording: Background service events are only captured when the record button is active
Service Workers → Push/Sync/Periodic Sync inputs: The most powerful debugging tool! You can manually fire events without a real server
Offline simulation: Use Network panel's "Offline" checkbox to test background sync retry behavior
"Update on reload": Essential during development to force SW updates
"Bypass for network": Skip the SW cache entirely — useful when debugging
Clear site data: Application → Storage → "Clear site data" resets everything

Application Hands-On 5

🔬 Background Services Lab

⚙️ Setup

Exercise 1: Back/Forward Cache Detective 🔍

Tasks:

Exercise 2: Background Sync Spy 🕵️

Tasks:

Exercise 3: Notification Inspector 🔔

Tasks:

Exercise 4: Push Messaging Lab 📬

Tasks:

Exercise 5: Speculative Loads Inspector 🔮

Tasks:

Exercise 6: Reporting API Observer 📊

Tasks:

Exercise 7: Service Worker Lifecycle Master 🎓

Tasks:

🏆 Bonus Challenge: Full Investigation

Tasks:

💡 Pro Tips