Measure Loading and Responsiveness Locally

Create the diagnostic fixture in a new folder on your own computer. It has fixed local data and one local SVG, so it does not need an API, downloaded teaching asset, or deployment.

In a terminal, create the familiar Vite React–TypeScript scaffold, then install its dependencies:

1. npm create vite@latest local-catalog -- --template react-ts
2. cd local-catalog
3. npm install

Keep the scaffold configuration and src/main.tsx unchanged. Replace the four files supplied in this step exactly. This fixture intentionally contains diagnostic defects for later measurement; they are not production patterns.

Create public/catalog-hero.svg with these complete contents:

Replace src/index.css with these complete contents:

Replace src/App.tsx with these complete contents:

Replace src/App.css with these complete contents:

The fixture has two intentional artificial diagnostic defects. After a nominal 1000 ms, the local SVG is inserted with no space reserved in advance. During filtering, simulateFilterWork() runs synchronously for approximately 180 ms.

Both behaviors are deliberately repeatable for diagnosis. Do not copy them as production patterns or fix them yet.

Build this application before measuring it. An optimized build is not the same thing as the development server: development transformations and development-only checks can change the work you observe.

From local-catalog, run the build. Then start the preview server and open the exact local address that Vite prints. This serves the generated optimized files only on your computer; it does not deploy anything.

If you change any source file later, run the build again before using the preview server. A running preview server does not automatically rebuild your source.

Run this command first:

After the build succeeds, start the local preview server:

At the preview server address, check the visible behavior before recording anything:

• The page title is Local Catalog.
• Wait for the delayed illustration to appear.
• Before filtering, the status reports all products.
• Select Apply filter once; only even-numbered products remain and the status changes.

Use desktop Chrome DevTools later, but remember that DevTools and browser extensions can add measurement overhead. For now, simply confirm the fixture works. The next step will define consistent measurement conditions.

A comparable baseline starts with two deliberately separate scenarios.

Load scenario: reload the optimized local app and make no input until the delayed hero content has settled.

Interaction scenario: return the app to its initial state, wait until the page has settled, then activate Apply filter exactly once. The status should change from “Showing 24 of 24 products” to “Showing 12 of 24 products.”

Do not mix these scenarios in one run. An early click changes the page state and can also change the work visible during loading. The delayed image insertion and bounded filtering work are artificial diagnostic defects in this fixture, not production patterns.

Keep the build and conditions fixed across comparable runs. Use the optimized local build and preview server; if source changes, run npm run build again before using npm run preview and reopen the local address printed by Vite.

For a straightforward baseline, select No throttling for both CPU and Network and record those exact settings. A simulated throttling preset can still be useful for a controlled experiment, but it is not an exact physical device. If you choose one, keep it unchanged for every comparable run.

For cold-cache loads, open DevTools, open Network, enable Disable cache, and keep DevTools open while reloading. That checkbox applies only while DevTools is open. Keep extensions, DevTools configuration, activation method, and major background activity as consistent as practical.

With the optimized application open through the preview server address printed by Vite, open Chrome DevTools Network. Keep the measurement conditions from your protocol, clear prior entries, reload, and locate catalog-hero.svg.

This local SVG is inserted only after a nominal 1000 ms timer. That delay is an artificial diagnostic defect, so its request can begin after the initial document and other assets. For the request row or its details, inspect its relative start time, duration, Initiator information when available, and Size/Transferred or cache evidence.

Initiator labels vary by Chrome version and build output. Record what the tool actually shows rather than assuming a particular initiator.

Now create a separate Performance recording. Enable screenshots in the recording settings, start recording, reload the preview page, and stop only after the delayed hero content has appeared and the page has settled.

Within this one trace, align the Performance network track, the main-thread track, and the screenshot strip on their common time axis. A request that starts late is evidence about discovery timing. A request that lasts a long time after it starts is evidence about loading or transfer duration. They are different observations.

Because this fixture is local, a late hero request does not by itself demonstrate a slow server or connection. Likewise, a completed request can precede the screenshot that visibly contains the hero because browser rendering work may still occur afterward.

Largest Contentful Paint (LCP) is the time, measured from the start of a page load, when the largest eligible content element visible in the viewport is rendered.

It describes a visible rendering milestone—not the time when every request ends and not simply the largest element in the DOM. As the page changes during loading, a later, larger eligible element can replace an earlier candidate.

For this fixture, the delayed hero image is worth investigating, but do not assume it is the LCP element. The trace identifies the candidate.

Open a preserved local load recording, such as Load 1, in Chrome DevTools Performance. Locate the page-load metric or LCP event available in your Chrome version and select it. Its details can identify the candidate element and its time relative to navigation start.

Then inspect the screenshot near that time. Does the selected element appear in the viewport then? This checks the observed candidate instead of inferring one from the fixture design.

Keep this an initial-load scenario: reload, make no early input, and wait until the delayed content settles. An early interaction can change page state or visible content, making the recording less useful for describing the initial load.

Compare three kinds of evidence in the same Performance recording:

1. Request timing — In the Network track or request details, note when the candidate resource starts and completes, plus initiator and cache/transfer evidence when available.
2. Main-thread activity — After completion, look for script, style, layout, paint, or other work before the visible update.
3. Screenshots and LCP — Check when the selected candidate actually appears and when the LCP event is recorded.

A late request start can contribute to a late presentation. A request that completes earlier than LCP suggests there was still time before presentation, but it does not by itself prove which later work caused that delay.

Cumulative Layout Shift (CLS) describes unexpected visual movement during a page visit. It is a unitless score—not a duration and not a count of elements that moved.

Chrome groups qualifying shifts into session windows. A window can include shifts that are less than 1 s apart, and it can last no longer than 5 s. The reported CLS is the score of the highest-scoring such window, rather than a sum across every shift on the page.

Do not calculate scores manually here. Your task is to find the recorded movement and inspect its visual evidence.

A shift that follows qualifying recent user input is generally excluded from CLS when it occurs within 500 ms of that input. This avoids penalizing an expected response to an action such as a click or key press.

Scrolling is not qualifying input for this exclusion. Therefore, movement during scrolling can still be relevant. The timing and input context in the recording matter; do not decide from the page appearance alone.

Open one of your load recordings in Chrome DevTools Performance. Find a Layout Shift event or cluster; track and event labels can vary by Chrome version. Select it, then inspect the screenshots immediately before and after the event.

Record three separate observations:

1. The event or cluster time and its displayed score.
2. An element whose position changed—for example, the status line or product grid.
3. What appeared, resized, or changed above that element.

The moved node is evidence of impact. It is not, by itself, proof of the cause.

In this diagnostic fixture, an image referencing /catalog-hero.svg is inserted after a nominal 1000 ms timer. The page initially reserves no space for it. That artificial setup is a useful hypothesis to investigate: an insertion above existing content can displace content below it.

Treat it as an intentional diagnostic defect, not a production pattern. At this stage, locate and describe the evidence only—do not implement a layout fix.

Record this interaction separately from a load recording. Reset the previewed app, then wait until the page has settled. In Chrome DevTools, open Performance and keep the conditions from your documented protocol unchanged.

Start a recording, activate Apply filter once, and stop after the status and product list have updated. Name this trace Interaction 1. The recording should focus on the activation, not on startup work or the delayed image insertion.

In the main-thread track, look for the task that covers the filter activation. A main-thread task lasting more than 50 ms is a long task. That threshold describes one contiguous period of main-thread work—not the duration of the whole recording and not a Network request duration.

Zoom into the task that contains the filter event. Expand its work in the available Call tree and inspect Bottom-up to find substantial JavaScript or rendering contributors. Select a frame to follow a source or stack location when DevTools offers one.

The fixture deliberately runs simulateFilterWork() for approximately 180 ms while filtering. It is an artificial diagnostic defect, not a production pattern. Trace or stack evidence may connect the task to that workload; an optimized bundle may instead show generated or shortened function names. In that case, record the generated location and correlate it carefully with the local source.

A task's total duration includes its nested work. Do not add an ancestor's inclusive time to the time of frames inside it: that would count the same elapsed time twice.

An interaction duration runs from a user action until the browser presents the next frame that reflects it. It has three phases:

• Input delay: the input waits before its event processing can begin.
• Event-processing time: the browser runs the event callbacks and their synchronous work.
• Presentation delay: processing has ended, but the visible result has not yet been presented.

Measuring only a click handler omits any earlier waiting and any work needed before the next paint. A responsive-looking result depends on the whole path, not just JavaScript inside the handler.

In Chrome DevTools Performance, record the settled-page filter action and locate the click or interaction event. Select its details when available, then zoom into the surrounding main-thread and rendering activity.

Use the event boundaries to connect the phase breakdown to the trace. The task containing the filter action can include the deliberately bounded simulateFilterWork() workload, but inspect the event boundaries rather than treating every nearby task as handler time. Panel labels and available details can vary by Chrome version; navigate by the event, main-thread work, and next presented frame.

Create two more comparable local recordings.

1. Reset the application to its fixed starting state and wait for the delayed content to settle.
2. Keep the same preview build, Browser, Viewport, DPR, Cache, CPU, Network, activation method, extensions, and tool configuration used for Interaction 1.
3. In Performance, record one activation of Apply filter. Save notes or trace evidence locally as Interaction 2.
4. Reset again and repeat once as Interaction 3.

For each run, retain the shared labels: Build, Browser, Viewport, DPR, Cache, CPU, Network, Scenario, Run, Observation, and Evidence. Record the interaction duration and available phase evidence; do not invent a phase value that the tool does not expose.

INP summarizes eligible click, tap, and keyboard interactions across a page visit. It uses a near-worst interaction with outlier handling, not an arithmetic average. Scrolling and hovering are not INP interactions.

Therefore, each filter trace here is a local interaction duration sample. One click—and especially one handler duration—does not establish the page's lifecycle INP.

Reference thresholds are interpretation guides, not a verdict about users. A value is in the good range when it is at or below its boundary—equality counts.

Keep the unit with every value. LCP is a duration, CLS is unitless, and INP is a duration that summarizes eligible interactions across a page visit. These boundaries help you describe a measurement consistently; they do not change what that measurement represents.

A local measurement diagnoses one defined situation: your current build, machine, Browser version, Viewport, DPR, state, scenario, and tool configuration. It is valuable evidence about that situation, but it is not a sample of everyone who uses the site.

A simulated CPU or Network setting can make a scenario repeatable. It remains a simulation, not an exact physical device or a population of users. A local tool’s displayed metrics do not establish real-user Core Web Vitals performance.

A field assessment uses field data: measurements from real users. It evaluates the p75 value—the value at or below which 75% of the relevant real-user measurements fall. Mobile and desktop are considered separately.

Three local recordings, even with carefully fixed conditions, cannot establish either a mobile or desktop p75. They do not contain a distribution of real devices, networks, content states, and interactions.

A baseline is a preserved snapshot, not a single “best” trace. Keep the six recordings comparable: Load 1–Load 3 use the initial-load scenario, and Interaction 1–Interaction 3 use the settled-page filter scenario.

Create one local baseline log beside the current local-catalog source. Record the shared conditions once, then give every run its own observation and evidence location. Preserve the current source snapshot and its optimized baseline build identifier before any future change.

Use these exact labels:

Build: baseline source/build identifier
Browser: Chrome version
Viewport: for example, 1280 × 800 CSS px
DPR: device pixel ratio
Cache: cold-cache procedure
CPU: selected setting
Network: selected setting
Scenario: load or filter procedure

For each recording, add Run:, Observation:, and Evidence:. Evidence can be a locally saved Performance trace, a screenshot, or a precise note naming the panel, track, and event.

Do not merge different scenarios into one number. Summarize the three comparable load readings separately from the three comparable interaction readings.

For a small repeated sample, report:

• Median: the middle value after ordering three comparable readings.
• Range: the highest reading minus the lowest reading.
• All runs: retain every run, including an unusual one.

An unusual run is evidence to investigate, not permission to delete it. Check whether Cache, CPU, Network, background activity, extensions, reset state, or procedure changed. If conditions changed, mark that run as non-comparable rather than quietly treating it as the same experiment.

A single event-to-next-paint result is an interaction duration. Do not label one recorded interaction as INP.

Choose one bottleneck to investigate later; do not turn every observed issue into one vague target.

Write two separate statements:

1. Observation: what the recordings show, including the user-visible outcome and evidence location.
2. Causal hypothesis: the suspected contributor and one measurable outcome expected after a future targeted change.

A hypothesis is testable, not a conclusion already proven by a trace. Preserve alternative explanations as uncertainty.

Keep the baseline Build: identifier in its evidence log. If you later change source code, that creates a candidate build with a different Build: identifier. Rebuild it with npm run build and inspect it through the local preview server address printed by Vite. For a like-for-like comparison, keep Browser, Viewport, DPR, Cache, CPU, Network, Scenario, activation method, reset procedure, and tool configuration fixed. The intended source/build change is the experimental variable.