Observers

Watchers, not loops

Many browser features are about noticing change. A card becomes visible. A third-party widget adds a node. A component grows wider. A performance measurement is recorded. You could check those things over and over in a timer, but that wastes work and often checks at the wrong time.

The browser gives you a better pattern: observers. You create an observer with a callback, tell it what to watch, and let the browser call you later with entries or records. Each observer specializes in one signal.

This lesson builds each one with a real lab. The key habit is simple: name the signal first, then choose the observer that watches that signal.

IntersectionObserver tells you when a target crosses visibility thresholds inside a root rectangle. With root: null, the root is the viewport. With root set to a scrollable element, the root is that element. This is the API behind many lazy images, scroll reveal effects, active table-of-contents markers, and infinite lists.

Three settings matter most. threshold is a number from 0 to 1, or an array like [0, 0.5, 1]. rootMargin expands or shrinks the root rectangle using px or %. And the first callback is queued soon after observe(), even before the user scrolls, so your code knows the current state.

1const observer = new IntersectionObserver(callback, {2  root: scrollBox,3  threshold: [0, 0.5, 1],4  rootMargin: "40px 0px",5});6observer.observe(card);7observer.observe(sentinel);

In the lab, each card starts as a placeholder. When a card intersects, the code swaps in an in-page colored block. The sentinel at the bottom appends more cards when it becomes visible. That is the infinite-list pattern: observe one tiny marker instead of calculating scroll positions yourself.

MutationObserver watches a DOM subtree for structural, attribute, and text changes. It is not a replacement for ordinary events. Use events when you control the user action. Use a mutation observer when code you do not directly control changes the DOM, or when a tool needs to audit changes after they happen.

The options object decides which records can appear: childList, attributes, subtree, characterData, and old-value flags such as attributeOldValue. At least one of child, attribute, or character data watching must be enabled.

1const log = [];Run2log.push("sync: start");3const records = [];4records.push("childList: added item");5records.push("attributes: data-state old=closed");6records.push("characterData: title changed");7log.push("sync: end");8log.push("callback: " + records.length + " records");9console.log(log.join(" | "));

1const log = [];2log.push("sync: start");3const records = [];4records.push("childList: added item");5records.push("attributes: data-state old=closed");6records.push("characterData: title changed");7log.push("sync: end");8log.push("callback: " + records.length + " records");9console.log(log.join(" | "));

Timing is the important professional detail. MutationObserver callbacks run as microtasks after the current script has finished, which connects directly to the Microtasks in depth lesson. If you need queued records immediately, call takeRecords(). When you are finished, call disconnect() so the observer stops holding onto targets.

A component can become narrow because a sidebar opened, text wrapped, a parent grid changed, or a font loaded. None of those necessarily fires window.resize. ResizeObserver watches the element itself and runs after layout, before paint.

1const observer = new ResizeObserver((entries) => {2  for (const entry of entries) {3    console.log(entry.contentRect.width);4    console.log(entry.borderBoxSize?.[0]?.inlineSize);5  }6});7observer.observe(panel, { box: "border-box" });

The default box is content-box. You can request border-box or device-pixel-content-box where supported. The older contentRect property is widely available; newer box sizes may be arrays. Read sizes in the callback, then update state or classes carefully. Do not resize the observed element inside its own callback.

The Performance Timeline records entries: marks, measures, resource timings, navigation timings, and some browser-specific metrics. PerformanceObserver lets you receive those entries as they are recorded. The safest beginner entry type is measure, because you create it yourself with performance.mark() and performance.measure().

1const observer = new PerformanceObserver((list) => {2  for (const entry of list.getEntries()) {3    console.log(entry.name + ": " + entry.duration.toFixed(2) + "ms");4  }5});6observer.observe({ entryTypes: ["measure"], buffered: true });7performance.mark("work:start");8// do a small task9performance.mark("work:end");10performance.measure("demo work", "work:start", "work:end");

Feature detection matters. Entry types such as longtask, layout-shift, and largest-contentful-paint are especially Chromium-oriented. Check PerformanceObserver.supportedEntryTypes after mount and observe only types this browser reports.

The names are long, but the decision is short: visible, changed, resized, or timed? Sort each realistic task by the signal it depends on.

Where you'll use this

Observers shine when the browser already knows the answer better than your code can guess it. Use IntersectionObserver to lazy-load media shortly before it appears, highlight a section link when a heading crosses the viewport, or append more rows when a sentinel appears. Pair it with cleanup: once a one-time image loads, unobserve(image) or disconnect().

Use MutationObserver at integration boundaries: a rich-text editor, a CMS embed, analytics that records when a third-party widget appears, or a migration script that repairs attributes after a library changes markup. Observe the smallest target and narrow the options. Observing the whole document with subtree: true can produce a noisy stream.

Use ResizeObserver for container-driven layout. It complements the Sizes, scrolling & coordinates lesson: geometry reads are still real layout facts, but the observer tells you when to read. Use PerformanceObserver for instrumentation: your own marks and measures first, advanced metrics only after feature detection.

Common misconceptions

• “Observers run synchronously.” They do not. Intersection callbacks are asynchronous, mutations are delivered in a microtask, ResizeObserver runs after layout, and PerformanceObserver follows the performance timeline.
• “Threshold 1 means visible at all.” It means the target is fully visible inside the root. Use 0 or a small threshold for “any part entered.”
• “MutationObserver is an event listener for clicks.” Use events for user actions. Use mutation records for DOM changes after they happen.
• “Window resize covers component resizing.” A card can resize while the window stays still.
• “All performance entry types work everywhere.” Some important types are browser-specific. Feature-detect.
• “Disconnect is optional cleanup.” In long-lived interfaces, missing cleanup can leave stale callbacks and retained targets.

Key takeaways

• Use observers when the browser can notify you about a change more efficiently than a polling loop.
• IntersectionObserver watches visibility inside a root; thresholds can be arrays and rootMargin can preload early.
• MutationObserver batches DOM change records and delivers them as a microtask after the current script.
• ResizeObserver watches element boxes after layout and before paint; avoid resize loops.
• PerformanceObserver watches timeline entries; feature-detect browser-specific entry types.

An observer is a focused browser watcher: configure what counts, observe targets, react to asynchronous entries, and disconnect when done.

Up next: Animation with JavaScript.