Lighthouse Advanced Mode: Settings, Modes, and a Reliable Testing Workflow

Lighthouse Advanced Mode is an editorial name for the advanced configuration controls in Chrome DevTools’ Lighthouse panel. It is not a separate Lighthouse product or paid tier. These controls let you choose the page state, device, audit categories, throttling model and trace detail used for a run.

Use Navigation for a repeatable page-load baseline, Timespan for a period containing interactions, and Snapshot for the page’s current state without reloading it. Clear storage when you need first-visit behavior; leave it intact when you need a repeat-visit measurement. Enable JavaScript sampling only when you need call-stack detail in the trace.

What Advanced Mode changes

Lighthouse remains the same open-source automated auditing tool. Advanced settings change the conditions under which it runs, so scores and opportunities are meaningful only when you record and repeat those conditions.

Control	What it changes	Use it when
Clear storage	Removes existing cookies, local storage, IndexedDB and related site data before the run.	You want a first-visit or cold-start measurement.
Storage retained	Preserves the browser’s existing site data.	You want repeat-visit behavior, cached state or an authenticated flow.
JavaScript sampling	Adds JavaScript call-stack detail to the performance trace.	You are diagnosing script execution and long tasks.
Throttling	Chooses simulated network/CPU conditions or actual DevTools limits.	You need either fast repeatable estimates or a test that experiences the limits directly.
Device	Selects mobile or desktop emulation, viewport and device characteristics.	You are comparing the experience for a target device class.
Categories	Selects audits such as Performance, Accessibility, Best Practices and SEO.	You want a focused report or a complete quality review.

Official reference: Chrome for Developers’ Lighthouse introduction.

Open and configure Lighthouse Advanced Mode in DevTools

Open the page you want to inspect in Chrome.
Open DevTools with Ctrl+Shift+I (Windows/Linux) or Cmd+Option+I (macOS).
Select the Lighthouse panel. If it is hidden, open the panel menu and choose Lighthouse.
Choose the device profile and the audit categories.
Expand the settings control to expose storage, throttling and JavaScript-sampling options.
Choose the Lighthouse mode: Navigation, Timespan or Snapshot.
Run the audit and save the report or export its JSON when you need to compare runs.

Choose the correct Lighthouse mode

Navigation measures one page load. Lighthouse reloads the page, follows the selected storage and throttling settings, records the load and runs audits. Start with Navigation when establishing a baseline for a URL.

Navigation is the right choice for questions such as:

How fast is the landing page for a new visitor?
Which render-blocking resources delay the first view?
Did a deployment change Core Web Vitals or loading opportunities?

Timespan

Timespan measures a period that can contain interactions. Start the timespan, perform the action, then end it. Use it for opening a menu, adding an item to a cart, filtering a table or completing a multi-step interaction without treating every action as a fresh navigation.

Snapshot

Snapshot audits the current page state without reloading. Use it when the state you need already exists and a reload would destroy it, such as an expanded dialog, a validation error, a logged-in dashboard or a populated results panel.

Question	Mode	Reason
Is the initial page load fast?	Navigation	Measures a controlled reload.
What happens while a user interacts?	Timespan	Captures a bounded interaction period.
Is this already-open state accessible and valid?	Snapshot	Audits without destroying the state.

Storage: first visit versus repeat visit

Clear storage approximates a first visit. It removes site data before Lighthouse starts, so login state, consent choices and application caches may disappear. This is useful for measuring onboarding and cold-start behavior, but it can make a report unlike what returning users experience.

With storage retained, Lighthouse can measure a repeat visit. Keep the exact starting state documented: cookies, authentication, service-worker state and any seeded application data. A retained-storage report is not comparable with a cleared-storage report unless that difference is intentional.

JavaScript sampling

JavaScript sampling adds call-stack information to the performance trace. That detail helps identify which scripts consume CPU or create long tasks. Report generation can take longer, so leave it off for routine baselines and enable it for a focused JavaScript investigation.

Simulated versus DevTools throttling

Throttling choice	How it works	Trade-off
Simulated throttling	Lighthouse records the run and extrapolates mobile results from the trace.	Faster and convenient for repeatable comparisons, but it is an estimate.
DevTools throttling	Chrome actually limits CPU and network while the page runs.	Closer to the selected limits, but the run takes longer and can be more sensitive to local conditions.

Use one choice consistently for before-and-after comparisons. Do not compare a simulated run with a DevTools-throttled run and attribute every score change to your code.

Device and category selection

Choose mobile when you are optimizing a constrained viewport and device class; choose desktop when that is the audience or deployment target. Record the selected device because it affects layout, CPU assumptions and the audits that run.

Performance, Accessibility, Best Practices and SEO are separate categories. Run only the categories relevant to a quick iteration, then run the full set before release. A Lighthouse score is an audit result, not a guarantee of search ranking or real-user experience.

A repeatable optimization workflow

Define the question. Write down whether you are measuring a navigation, interaction or current state.
Record conditions. Save the URL, device, categories, storage choice, throttling choice and whether JavaScript sampling was enabled.
Run a baseline. Export the report or JSON and note failed audits and opportunities.
Change one thing. Keep the test conditions fixed so the result has a clear cause.
Repeat the same mode. Use the same URL and configuration, then compare the new report with the baseline.
Validate in the real flow. For interaction changes, use Timespan or Snapshot rather than assuming a Navigation score captures the work.

Automate a comparable run with Lighthouse CLI

The DevTools panel is useful for exploration. The CLI is useful when you need a command that can run in CI or be repeated by a team. Install Lighthouse with npm, then run a mobile-style navigation audit:

npm install --save-dev lighthouse
npx lighthouse https://example.com \
  --output html \
  --output-path ./reports/example.html \
  --preset=perf \
  --quiet

For a machine-readable result, request JSON:

npx lighthouse https://example.com \
  --output=json \
  --output-path=./reports/example.json \
  --quiet

Keep the environment and command stable when comparing reports. CLI flags and Chrome versions can change results, so record the Lighthouse and Chrome versions with your artifact.

Common errors and fixes

Symptom	Likely cause	Fix
The report starts from a login page.	Storage was cleared or authentication was not established.	Retain storage or authenticate before Snapshot/Timespan; document the starting state.
Scores vary widely between identical runs.	Different throttling, device, cache state, background activity or server response.	Repeat the same configuration, close competing tabs, and compare several runs instead of one outlier.
The interaction disappeared after starting the audit.	Navigation mode reloaded the page.	Use Timespan for the interaction or Snapshot after reaching the desired state.
The audit takes much longer after a setting change.	JavaScript sampling or actual DevTools throttling is enabled.	Disable sampling for routine runs; use simulated throttling when an estimate is sufficient.
A third-party widget dominates the trace.	External scripts load during the run.	Keep the result as a production finding, or isolate the dependency in a separate diagnostic run; do not remove it from the baseline without recording that change.
Accessibility or SEO results are missing.	The category was not selected.	Enable the category and rerun; category selection is independent of the performance mode.
CLI output cannot be written.	The report directory does not exist or the process lacks permission.	Create the directory, choose a writable path and rerun.

Performance, reliability and cost notes

Performance: Simulated throttling and disabled JavaScript sampling generally make iteration faster. DevTools throttling and sampling provide different evidence but increase run time.
Reliability: A single Lighthouse run is sensitive to server timing, third-party requests and local contention. Use the same conditions and look for consistent changes across repeated runs.
Comparability: Storage state, mode and throttling are measurement inputs. Store them with the report so a future run can reproduce the question.
Cost: Lighthouse is open source and runs locally. Your practical costs are compute, CI minutes and any hosted browser infrastructure you choose; Lighthouse itself does not create a per-report service charge.

Or skip the browser setup

If your goal is a clean image or PDF of a page after you finish diagnosing it, ScreenshotNeo provides a single screenshot API call. It accepts the consent banner like a visitor, removes more than 60 known consent platforms plus newsletter popups and chat widgets, and lets you turn each cleanup step off. Bot checks, CAPTCHAs, blank pages, timeouts, failed loads and cache hits are not billed; the response identifies the result with X-Page-Verdict and X-Billed headers. It also includes an MCP server for Claude, Cursor and other MCP clients, with take_screenshot, get_page_info and capture_pdf tools.

See the ScreenshotNeo documentation for all options. The same request works from cURL:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

Python:

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

Node.js:

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

ScreenshotNeo includes full-page and element capture, device and viewport controls, retina scale, custom CSS and JavaScript, waits, request blocking, headers, cookies, user-agent and authorization controls, timezone and geolocation, resizing, caching, signed links, asynchronous jobs, webhooks, bulk capture and a usage API. 1,000 screenshots per month are free with no card; paid plans start at $5 for 3,000. Create a free ScreenshotNeo account.

FAQ

Is Lighthouse Advanced Mode a separate download?

No. The phrase describes advanced controls in the Lighthouse panel and related workflows.

Should I always clear storage?

No. Clear it for first-visit behavior; retain it for repeat visits or authenticated states. Choose based on the question you are measuring.

Use Timespan while performing the click, or Snapshot after opening the modal if you need to preserve that exact state.

Does a higher Lighthouse score guarantee better rankings?

No. Lighthouse identifies technical findings under defined conditions. Search visibility and real-user outcomes depend on many other factors.

When is JavaScript sampling worth enabling?

Enable it when the performance trace lacks enough call-stack detail to explain script CPU time or long tasks. Leave it off for faster routine baselines.