Latixo

Measurement methodology

How a Latixo test works.

Each test is one controlled browser run from the selected Latixo node. This page defines what is measured, how it is captured and where interpretation requires care.

Technical owner: Latixo TeamLast reviewed: September 6, 2026Applies to V1.10

Test environment

  • Browser: Chromium controlled by Playwright.
  • Location: Virginia, USA; Nuremberg, Germany; Tokyo, Japan; Seattle, USA; Singapore; São Paulo, Brazil; or Beijing, China, selected before the test. Latixo never silently moves a job to another location.
  • Capacity: each location has an independent worker pool and a bounded waiting queue. Beijing currently runs one worker; the other locations run two.
  • Desktop profile: 1366 × 768 CSS-pixel viewport, DPR 1, no touch emulation, native node CPU and native node network. Its 960 × 540 replay preserves the V1.7 baseline.
  • Mobile profile: 390 × 844 CSS-pixel viewport, DPR 3, mobile viewport behavior, touch enabled and a mobile Chromium user agent.
  • Mobile CPU: fixed 4× slowdown relative to the node CPU.
  • Mobile network: fixed 1600 Kbps download, 750 Kbps upload and 150 ms minimum latency. These numeric limits—not a connection-name claim—define the profile.
  • Mobile replay: the first viewport is recorded as a 390 × 844 WebM video.
  • Timeouts: Desktop retains its 40-second test and 30-second full-load navigation limits. Mobile uses a 70-second test limit, waits up to 50 seconds for DOMContentLoaded and then allows up to 12 additional seconds for the load event.
  • Browser state: service workers are blocked and each job receives a fresh isolated context.

Test sequence

  1. The submitted value is normalized to an HTTP or HTTPS URL.
  2. URLs containing credentials, non-standard ports or private and reserved destinations are rejected.
  3. The job enters the queue. One IP address may have only one queued or running job at a time.
  4. A worker opens a fresh browser context, starts network and video capture, and navigates to the page.
  5. Desktop navigation waits for the page load event. Mobile navigation first requires DOMContentLoaded, then waits up to 12 additional seconds for the load event so a slow or non-critical resource does not automatically discard the entire mobile run.
  6. Latixo then waits for network idle for up to four seconds and allows a short settling period before capture ends.
  7. The result is returned to the browser and the temporary capture directory is removed.

Metric definitions

Total load time
The browser navigation timing value at loadEventEnd. It describes the document load event in this run; it is not a Core Web Vital.
Time to first byte (TTFB)
The navigation timing value at responseStart, measured from the start of the navigation in this browser context.
Page weight
The sum of encoded response data lengths reported through Chromium's DevTools Protocol during the capture window. Caching, redirects and late activity can affect the value.
Requests
The number of network requests observed through Chromium's Network.requestWillBeSent events during the run.
Performance grade
A Latixo heuristic derived from measurements in this run. It is not a Lighthouse score, PageSpeed Insights score or official Core Web Vitals assessment.
Loading replay
A recording of the visible first viewport during the browser run, synchronized to Latixo's replay progress display.

Queue and result lifecycle

V1.10 runs seven independent Browser Nodes. Beijing has one browser worker and the other locations have two; every node accepts a maximum of 12 waiting jobs. Desktop and Mobile jobs selected for a location use only that location's queue and worker pool. Queue and test timeouts release worker capacity automatically. Completed results are held in that Browser Node's memory for short-term delivery: normally up to five minutes before retrieval and approximately 60 seconds after delivery.

Limitations

  • A single synthetic run does not represent real-user experience across devices, locations or network types.
  • The Mobile profile is a first-order browser emulation. It does not run on a physical phone and cannot reproduce a mobile CPU architecture or every device behavior.
  • Seven test locations are active. The location selector, rather than the decorative map, is the authoritative list of available nodes.
  • Dynamic content, consent interfaces, experiments, advertisements and third-party services may change between runs.
  • Authenticated pages, local/private destinations and non-standard ports are outside the current test scope.
  • The replay covers the first viewport and does not prove that all page content is usable or accessible.
  • Latixo is not a complete SEO, accessibility, privacy or security audit.

Recommended use: repeat important tests, compare like with like, and confirm findings with field data and specialist tools before making high-impact decisions.