How to Optimize Dashboard Load Times in Looker

A slow-loading dashboard is more than a minor annoyance, it's a roadblock to data-driven decision-making. If your team has to wait minutes for insights, they'll stop looking for them altogether. This guide provides actionable, step-by-step strategies to diagnose and fix performance issues, ensuring your Looker dashboards are fast, responsive, and actually get used.

Why Slow Dashboards Are a Business Problem

Before diving into the "how," it's important to understand the "why." A dashboard's primary purpose is to deliver insights quickly. When it fails to do so, several problems arise:

• Low Adoption: Users will abandon tools that are slow and frustrating. If they can't get answers quickly, they'll revert to old habits, like asking a developer for a data pull or, worse, making decisions on gut instinct alone.
• Reduced Trust: A consistently slow dashboard can create a perception that the data or the platform itself is unreliable. This erodes trust and diminishes the value of your entire business intelligence investment.
• Wasted Time: Every minute your team waits for a dashboard to load is a minute not spent analyzing insights or taking action. This represents a significant and often overlooked productivity cost for the entire organization.

Step 1: Diagnose the Bottlenecks

You can't fix what you can't measure. The first step is to identify exactly which elements on your dashboard are causing the slowdown. Looker offers several built-in tools to help you investigate.

Check the Network Panel

The simplest way to see query times is right in your browser. Right-click anywhere on the dashboard, select "Inspect," and open the "Network" tab. Refresh the dashboard and watch the waterfall of requests. You can sort by time to quickly identify the individual tile queries (they usually start with query?) that are taking the longest to complete.

Review Your System Activity Dashboards

Looker's "System Activity" model, particularly the "Performance Recommendations" and "Dashboard Performance" dashboards, is a goldmine of information. These pre-built dashboards allow administrators to see performance metrics across the entire Looker instance. You can pinpoint:

• Which dashboards are loaded most frequently.
• The average load time for each dashboard.
• The specific tiles on each dashboard that contribute most to load time.

Filter these dashboards to find your slowest performers and use that as your starting point for optimization.

Deep Dive with SQL Runner

Once you've identified a slow tile, you need to understand why the query is slow. From the tile's menu, click "Explore from Here." From the Explore view, click the "SQL" tab to see the raw SQL Looker generates.

Copy this SQL and paste it into Looker's SQL Runner. Here, you can run the query directly against your database and use the EXPLAIN button. The EXPLAIN plan is your database’s execution strategy for the query. While it can be complex, you can often spot obvious issues like full table scans on large tables, which indicate missing database indexes.

Step 2: Implement a Solid Caching Strategy

Caching is your first and most effective defense against slow dashboards. Caching stores the results of a query for a period, so the next time a user loads the dashboard, Looker can retrieve the results from its cache in milliseconds instead of re-running the query against your database.

Use Datagroups with persist_with

The best practice for managing your cache is using datagroups. A datagroup allows you to define a caching policy that can be applied to multiple Explores.

A datagroup is typically defined in a model file and has two key parameters:

• sql_trigger_value: This runs a SQL query (e.g., select max(updated_at) from my_table) to check for new data. When the result of this query changes, the cache for any associated Explores is invalidated. This is the ideal method, as it ensures your dashboards update precisely when the underlying data does.
• max_cache_age: If a trigger isn't feasible, this sets a simple time-based policy, like "refresh the data every 6 hours."

Here's an example of a datagroup definition in a model file:

datagroup: orders_datagroup {
  # Invalidate the cache whenever a new order is added
  sql_trigger_value: SELECT MAX(id) FROM orders,
  # As a fallback, refresh at least every 6 hours
  max_cache_age: "6 hours"
}

You then apply this datagroup to your Explore using the persist_with parameter:

explore: orders {
  persist_with: orders_datagroup
}

By using caching effectively, you can give many of your users a near-instant load experience while still guaranteeing that the data is reasonably fresh.

Step 3: Optimize Your LookML Model

A well-structured LookML model is the foundation of a performant Looker instance. Poorly written LookML can generate inefficient SQL, leading to slow queries no matter how aggressive your caching is.

Create Aggregate Tables for Summaries

Does your dashboard show high-level metrics like daily sales, weekly traffic, or monthly user counts? If so, you should be using aggregate tables. An aggregate table is a type of Persistent Derived Table (PDT) that pre-aggregates your data into a summary table.

Instead of querying a raw events table with millions or billions of rows every time the dashboard loads, Looker can query a much smaller, pre-calculated summary table. This can reduce query times from minutes to seconds. You define an aggregate table within its corresponding explore definition in LookML.

Looker's logic is smart enough to use this table automatically whenever a user's query can be answered by it, a feature known as "aggregate awareness."

Reduce Join Complexity

Unnecessary joins are a common performance killer. Review your LookML model and ask yourself:

• Are you joining large tables that aren't needed for most queries? Use the required_joins parameter in your explore to only include a join when a user specifically selects a field from that joined-in view.
• Are your join relationships defined correctly? Ensure you're using one_to_many and many_to_one appropriately. Misconfigured joins can cause fanouts, which result in incorrect calculations and slow performance.

Filter an Explore by Default

To prevent users (and your dashboard) from accidentally querying your entire history, you can set default filters at the Explore level. This ensures every query from that Explore has a foundational WHERE clause.

Use always_filter to suggest a filter to the user, who can then change it. Or, for a stricter rule, use sql_always_where to enforce a filter that cannot be removed.

explore: tickets {
  # Strongly recommend users filter by a date range, defaulting to 90 days
  always_filter: {
    filters: [ticket_date: "90 days"]
  }

  # Or, an even stricter approach for performance:
  sql_always_where: ${ticket_date} >= DATE_SUB(CURRENT_DATE(), INTERVAL 90 DAY),
}

Step 4: Streamline Your Dashboard Design

Even with a perfectly optimized backend, poor dashboard design can still lead to a sluggish experience. Think of your dashboard as a highly focused report, not a data dump.

Limit the Number of Tiles

This is the simplest advice: use fewer tiles. Each tile on a dashboard typically issues a single, complex query. A dashboard with 30 tiles is running at least 30 separate queries every time it refreshes. Ask yourself:

• Could you combine multiple tiles into one?
• Can this one dashboard be split into two or three more focused dashboards?
• Are all of these tiles truly necessary for the story this dashboard is telling?

Use Dashboard Filters Wisely

Make sure your dashboard filters have sensible defaults. A dashboard that defaults to showing data for "the last 2 years" will be incredibly slow on first load. Change the default to a more reasonable timeframe, like "the last 30 days," and let users expand the window if they need to. Avoid using filters with high cardinality fields - like user_id or email - as these are difficult for databases to process.

Merge Repetitive Queries

Do you have several tiles that use the same explore, the same filters, but visualize different metrics? For example, one tile shows "Total Orders by Day," and another shows "Total Revenue by Day."

Instead of running two separate queries, you can merge them into one. From a tile's menu, select "Edit" to choose the "Merge" feature and combine its query with another one that relies on the same Explore. This instructs Looker to run a single, more efficient database query to populate both tiles, reducing the load on your database.

Final Thoughts

Optimizing Looker dashboard speed is a process of systematic investigation and refinement. By diagnosing slow queries, implementing smart caching, cleaning up your LookML, and applying thoughtful dashboard design principles, you can transform sluggish dashboards into responsive tools that empower your team to make better, faster decisions.

Of course, the need for technical deep-dives into caching policies, LookML, and SQL is exactly why many teams struggle to get value from traditional BI tools. We felt this pain ourselves, which is why we built Graphed. Our platform bypasses this entire lengthy process by allowing anyone to connect their data sources and simply ask for a dashboard in plain English. No SQL, no LookML, and no weeks of learning a complex new tool - just answers and insights in seconds.