> ## Documentation Index > Fetch the complete documentation index at: https://autorender.io/docs/llms.txt > Use this file to discover all available pages before exploring further. # Configuration > Configure Autorender Native from the script URL — workspace, device pixel ratio, resize request volume, lazy-load lookahead, and debug logging. Autorender Native reads all of its configuration from the script URL query string. There is no config file — change a value by changing the ` ``` Every parameter except `ws` is optional. A typo in an optional parameter falls back to its default rather than disabling the runtime. `ws` is the exception: a missing or malformed `ws` logs a fatal error and disables the runtime. ## What are the parameters? | Parameter | Default | Description | | -------------- | ------------ | ------------------------------------------------------------------------------ | | `ws` | — (required) | Workspace ID, matching `[A-Za-z0-9_-]{1,64}` | | `max-dpr` | **2** | Upper clamp for `devicePixelRatio` (**1**–**4**) | | `step` | **10** | Width rounding step in pixels — controls resize request volume (**1**–**512**) | | `anticipation` | **20%** | Lazy-load lookahead: `20%`, `300px`, or `0.2` | | `class-prefix` | **ar** | Prefix for the lifecycle CSS classes, e.g. `ar-loading` | | `debug` | off | `debug=1` enables console diagnostics | ## How does `ws` work? `ws` is your workspace ID — the same public routing segment that appears in every Autorender delivery URL. It is **required**, and without a valid value the runtime logs a fatal error and stays disabled. It is a public routing identifier, not a secret. Do not put an API key on the page; Autorender Native performs client-side delivery only. ## How does `max-dpr` cap resolution? `max-dpr` clamps the device pixel ratio the runtime multiplies into each requested width, so a **3×** phone still requests at most **2×** by default. The clamp trades a small amount of sharpness on very high-density screens for smaller files and higher cache reuse. We recommend the default of **2** for most sites, because the visual gain from **3×** is marginal while the file is roughly twice the bytes. Raise it to **3** only for detail-critical imagery such as product zoom. ## How does `step` reduce requests? `step` is the rounding increment for requested widths. The runtime multiplies each measured CSS width by the device pixel ratio, then rounds the result **up** to the next multiple of `step`. On a **2×** screen a **396 px** box needs **792 device px**, which rounds up to `w_800`; a **398 px** box needs **796 px** and also requests `w_800` — one variant, one request, instead of two. This matters most while an element resizes. As a box grows during a window drag or a layout shift, the runtime fetches a new variant only when the width crosses a `step` boundary, so a larger `step` crosses fewer boundaries and fires fewer requests — raising `step` from **10 px** to **50 px** cuts resize requests by about **5×**. The runtime never re-fetches when a box shrinks. `step` accepts any integer from **1** to **512**, and does not have to be a multiple of **10**. Most sites never change it — the default of **10 px** suits most layouts. Raise it to **50** on image-dense grids to cap the requests a resize can generate. `step` and [width bucketing](/docs/optimization/automatic) act on two different layers, so one does not replace the other. `step` is **request-side**: it decides how many distinct widths the *browser* asks for as a box resizes. Width bucketing is **cache-side**: the delivery layer rounds each requested width up to a shared bucket so nearby widths reuse one cached file. Bucketing happens *after* the request leaves the browser, so it cannot remove the requests `step` prevents. Set `step` to **1** and the browser fires a new request on nearly every pixel of a resize, even when the delivery layer returns the same cached image each time. ## How does `anticipation` set the lazy-load lookahead? `anticipation` is how far ahead of the viewport the runtime starts loading an image. It accepts three forms: * a percentage of the viewport — `20%` (the default) * an absolute pixel distance — `300px` * a bare ratio — `0.2`, equivalent to `20%` A larger lookahead loads images earlier, so they are more likely to be ready before the visitor scrolls to them, at the cost of loading some images the visitor never reaches. The default **20%** balances the two for typical scroll speeds. A percentage value uses the `%` character, which must be percent-encoded as `%25` in the script URL: `anticipation=20%25`. An unencoded `%` is dropped by the browser and the value falls back to the default. ## How do I avoid CSS class name clashes? The runtime marks every element it manages with a lifecycle class — `ar-loading`, `ar-done`, and `ar-error` on images, and `ar-background-loading`, `ar-background-done`, and `ar-background-error` on backgrounds. If your site already uses `ar-` class names for something else, set `class-prefix` to rename them: ```html wrap theme={null} ``` The classes now become `acme-loading`, `acme-done`, `acme-error`, and `acme-background-*`, leaving your own `ar-` styles untouched. `class-prefix` must start with a lowercase letter and contain only lowercase letters, digits, and single hyphens, **up to 32 characters** — for example `acme` or `acme-img`. An invalid value falls back to the default `ar`. Only the CSS classes change; the `data-ar-*` attributes are fixed. See [Events and classes](/docs/native/events) for the full class list and how to style each state. ## How do I turn on debug logging? Add `debug=1` to log diagnostics to the browser console: missing or invalid configuration, invalid intrinsic values, rejected transform tokens, zero-size elements, and eager images with no parse-time `src`. ```html wrap theme={null} ``` Production mode is silent except for a single fatal error when `ws` is missing. Leave `debug` off in production. ## How do I tear down the runtime? Call `window.__AR_NATIVE__.destroy()` to shut the runtime down completely — for example when a test harness tears down between cases, or when an embedded widget that started the runtime is removed and you are handing the page to another tool. It disconnects the three observers (`IntersectionObserver`, `ResizeObserver`, `MutationObserver`), so no further elements are measured, loaded, or upgraded. `destroy()` stops future work only. It does not undo what already loaded: every processed element keeps its variant `src` and its lifecycle class (`ar-done` and the rest), and no original `src` is restored. There is no re-initialize or rescan — once destroyed, the runtime stays down for the life of the page, and re-adding the script tag does not restart it. There is no way to restart the runtime after `destroy()`. Call it only when you want image loading to stop for the rest of the page's life. For ordinary single-page-app navigation you do not need it, and calling it will kill image loading for every route that follows. `window.__AR_NATIVE__` is a minimal handle — `version`, the parsed `config`, and `destroy()` — not a full public API. There is no method to add, refresh, or re-scan elements. While the runtime is running, its `MutationObserver` discovers new nodes on its own, so a single-page app that swaps content into the live document is picked up automatically, with no call needed. ## Next steps Mark images, backgrounds, transforms, and view containers. What Autorender Native does and when to use it. How the delivery layer picks format, width, and quality. Style load states and hook into the image lifecycle.