Timer - Liquid Tag Reference

The timer block tag measures how long its enclosed content takes to render and reports the duration to the web console, StoreConnect’s own developer console rather than the browser’s. Use it to profile template performance during development and identify which sections are slow.

Timers are recorded only during an active console session. Outside one the tag has no effect.

:::warning Always remove timer tags before shipping templates to production. While timing data does not affect page rendering or appear on the page, it contributes to console noise and may clutter logs. :::

Syntax

```liquid

{% timer %} {% endtimer %} ```

Or with an optional label:

```liquid

{% timer “my_section” %} {% endtimer %} ```

Property	Value
Tag Name	timer
Type	Block tag
Source	StoreConnect
Output	The web console only, never the page or the browser’s console

Parameters

Parameter	Required	Type	Description
Label	No	String	An optional name for the timer. If omitted, a generic label is used. Helps identify which timer produced the output.

Description

The timer block runs its content and measures the wall-clock time taken to render. When the block finishes, the elapsed time is reported to the web console. The measurement includes everything inside the block: Liquid logic, variable assignments, nested loops, query tags, and template rendering.

Interpreting timer output

Timer values are in milliseconds (ms). As a rough guideline: - Under 10ms: Fast; no optimization needed. - 10–50ms: Acceptable for most use cases. - 50–100ms: Consider optimization if this section is on every page load. - Over 100ms: Investigate for slow database queries, large loops, or expensive operations. Consider caching, pagination, or breaking the work into smaller pieces.

Remember that timer values vary depending on: - Database load at the time of rendering - Network latency for external API calls - Server CPU load - Cache hit/miss (especially for external services)

Run the timer multiple times to get a sense of typical and worst-case performance.

Examples

Time a slow query section

```liquid

{% timer “fetch_products” %} {% query ‘Product2’ as products, s_c__store_id__c: current_store.id %} {% for product in products %} <div class="product">{{ product.name }}</div> {% endfor %} {% endtimer %} ```

Console output (example): Timer "fetch_products": 127.45ms

This tells you that querying and rendering all products together takes about 127 milliseconds. If this exceeds acceptable page load time, consider caching the output or paginating the results.

Measure render time of a complex component

```liquid

{% timer “header_render” %} {% render “header” %} {% endtimer %} ```

Console output: Timer "header_render": 34.12ms

Use this to track whether a shared component (like a header or navigation) is becoming slower as you add features to it.

Compare performance with and without caching

Wrap the same section in a timer block before and after adding a cache block:

Without cache:

```liquid

{% timer “uncached_products” %} {% query ‘Product2’ as products limit: 50 %} {% for product in products %} {% render “product_card”, product: product %} {% endfor %} {% endtimer %} ```

With cache:

```liquid

{% timer “cached_products” %} {% cache “products_section”, items: [current_store] %} {% query ‘Product2’ as products limit: 50 %} {% for product in products %} {% render “product_card”, product: product %} {% endfor %} {% endcache %} {% endtimer %} ```

On the first page load, both timers show similar times. On subsequent loads (before cache expires), the cached version is much faster because the database query and rendering are skipped.

Best practices

• Narrow your scope. Wrap the smallest interesting section to isolate the problem. Timing the entire page does not tell you which part is slow.
• Use descriptive labels. A label like "fetch_related_products" is more useful than "section" when reviewing many timer logs.
• Pair with caching. If a timer shows high values, investigate whether caching (with the cache tag) can reduce the load.
• Remove before commit. Use your code editor’s Find function to locate all timer tags and remove them before pushing theme changes.
• Test in production-like conditions. Development servers are often faster than production. If a section times well locally but feels slow on the live store, add a timer on staging to measure real-world performance.