Why is Looker So Slow?

Nothing stalls your momentum like a dashboard that takes minutes to load. If you're constantly seeing that spinning wheel in Looker, you're not alone, and it's a fixable problem. This guide will walk you through the most common reasons why Looker feels slow and provide actionable steps to speed things up, from optimizing your data models to designing more efficient dashboards.

First Things First: It's Probably Your Database

Here’s the most important thing to understand about Looker's performance: Looker is not a database. It's an interface that sits on top of your existing database (like BigQuery, Redshift, Snowflake, or others). When you load a dashboard or an Explore in Looker, it generates SQL queries in the background and sends them to your database. Your database then runs those queries and sends the results back to Looker to be visualized.

This means that 90% of the time, "slow Looker" actually means "slow queries." The bottleneck is almost always the time it takes your database to process the request. Looker can only visualize data as fast as your database can return it. So, while we'll cover Looker-specific optimizations, your first point of investigation should always be the underlying database and the SQL that Looker generates.

Diagnosing the Slowdown: How to Find the Bottleneck

Before you can fix the problem, you need to identify where it's coming from. Looker has a few built-in tools that make this easier. Start by identifying a specific dashboard or Explore that is consistently slow.

1. Use the "Get LookML" Feature

When you're in an Explore, build out a query that's running slowly. Then, click on the SQL tab in the Data pane. This shows you the exact SQL query Looker just generated and sent to your database.

You can copy this query and run it directly in your database's own query editor. If it's slow there, too, you've confirmed the issue lies within the query processing on the database side, not Looker itself.

2. Analyze the Query Admin Panel

If you have admin permissions, you can get a bird's-eye view of all queries being run. Navigate to Admin > Query. Here you'll find a history of all queries, who ran them, how long they took, and which dashboard or Explore they came from.

Look for queries with a long "Runtime." Clicking on a query in this list and selecting "Details" will give you crucial information, including the "Time in Database" vs. "Time in Looker" breakdown and a link to the database's query execution plan (if supported).

3. Check the Dashboard's Network Requests

Another helpful method is to use your browser's developer tools. Go to your slow dashboard, open the developer tools (usually F12 key or right-click > Inspect), and go to the "Network" tab. Refresh the dashboard and watch what happens. You can filter the requests to see which dashboard tiles are taking the longest to load. This helps you pinpoint specific visualizations that might be based on an especially heavy query.

Common Causes for Slow Looker Dashboards (and How to Fix Them)

Once you've identified that certain queries are the problem, you can start digging into the "why." Here are the most frequent offenders.

1. Your LookML Model is Inefficient

A poorly structured LookML model is a primary cause of slow queries. The model is the blueprint for how Looker pieces together SQL from user-selected fields and filters.

Complicated or Too Many Joins: Every join adds complexity and processing time. If your Explore involves joining multiple large tables, things can slow down dramatically. Be critical about which joins are absolutely necessary for a given Explore. Avoid joining tables that aren't needed for the analysis at hand.
Incorrect Join Relationships (Fanouts): A "fanout" occurs when you join a table in a way that generates multiple rows in the result set for a single row in the original table (e.g., joining a users table to an orders table when a user can have many orders). Fanouts can cause symmetric aggregate functions to slow down significantly. Make sure your join relationships (one_to_one, one_to_many, many_to_one) are defined correctly in your model.
Lack of Persistent Derived Tables (PDTs): If you frequently rely on complex joins or heavy calculations, pre-aggregating your data using PDTs can be a lifesaver. A PDT is essentially a table that Looker creates and stores in your database's scratch schema on a schedule you define. When a user queries data from the PDT, they're querying a pre-built, optimized table instead of forcing the database to perform the complex joins and calculations on the fly. This is ideal for transforming raw, event-level data into a cleaner, summarized format.

How to fix an inefficient LookML model:

Review your Explores. Do they need all the joins currently defined? Remove any that are non-essential.
Create separate, leaner Explores for specific use cases rather than one giant "do-it-all" Explore.
Identify your most complex and frequently used calculations or joins and materialize them as a PDT. Set up a datagroup to refresh the PDT on a regular cadence (e.g., every hour or once a day).

2. Your Dashboard Design is Too Heavy

Even with an efficient LookML model, a poorly designed dashboard can crush your database with requests.

Too Many Tiles: Remember that every tile (chart, graph, number card) on a dashboard initiates at least one query to your database. A dashboard with 25+ tiles is sending 25+ queries every time it refreshes. This can overwhelm the database, especially if multiple people are loading it simultaneously.
Slow-Running Filters: Filters that allow open text input on a massive field (like a user_id or product_name field in a multi-million-row table) can be disastrous. The query has to scan a huge amount of data to find matches. Similarly, using a large number of filters can create an overly complex query.
Run on Load is Always On: By default, Looker dashboards run every query as soon as the page loads. For very large or complex dashboards, this initial query surge can be slow.

How to fix a heavy dashboard design:

Consolidate tiles where possible. Ask yourself, "Can I communicate this information with fewer visuals?" Sometimes, a single, more focused dashboard is better than one monolithic dashboard.
For filters, use suggestions backed by a leaner dimension, or use a dropdown menu instead of open text. This pre-filters the options and prevents users from running wild-card queries. You can also implement a sql_always_where condition on your Explores to force a date range or other filter, preventing users from accidentally querying your entire history.
Disable "Run on page load" in the dashboard settings. Users can then adjust filters first before clicking a "run" button to execute the queries, preventing unnecessary runs.
Check your merge queries. Often a single 'merged results' query might be bringing in many multiple queries which adds extra load time before it's visually rendered. Make sure these queries are necessary and as simple as they can be.

3. Your Database Lacks Proper Indexing

Indexes are like the index at the back of a book. Instead of scanning every page (every row) to find what you're looking for, the database can use the index to jump directly to the relevant data.

If your queries frequently filter or join on columns that are not indexed, your database is forced to do a "full table scan," which is extremely inefficient on large tables. This is purely a database-level configuration and has nothing to do with Looker itself.

How to investigate and fix indexing:

Collaborate with a database administrator (DBA) or data engineer. Show them the slow-running SQL from Looker.
Using your database's native tools, run an EXPLAIN plan on the query. This command shows the database's step-by-step plan for executing the query, often revealing if it's using an index or resorting to a full table scan.
Add indexes to the columns commonly used in WHERE clauses (filters) and JOIN ON clauses in your slow queries. The impact can be dramatic, turning multi-minute queries into sub-second ones.

A Quick Performance Checklist

Feeling overwhelmed? Here's a quick checklist to run through when you encounter a slow Looker asset:

Isolate the Problem: Is it one tile, one dashboard, or everything?
Test the SQL Directly: Copy the query from the SQL tab and run it in your database's console. Is it still slow? (The answer is almost always yes).
Review the Joins: Are there unnecessary joins in the Explore that powers the report?
Check the Filters: Are you filtering on unindexed columns? Can you implement more efficient filter types?
Consider Consolidation: Can you reduce the number of tiles on your dashboard?
Think About Pre-Aggregation: Is this a use case for a Persistent Derived Table (PDT) to do the heavy lifting in advance?
Consult a DBA: Ask a data engineer to check indexing on the underlying tables.

Final Thoughts

Optimizing Looker's speed is a process of systematic troubleshooting, starting from the dashboard tiles and working your way back to the database itself. By understanding that Looker is a window into your database, you can focus your efforts on writing efficient SQL through cleaner LookML models and asking for better-indexed tables, leading to a much smoother experience for everyone.

While tweaking technical tools is a critical skill, sometimes the biggest slowdown is simply the time it takes to get from a business question to a final, actionable chart. At Graphed, we help you skip the technical hurdles entirely. After a one-click connection to your data sources like Google Analytics, Salesforce, or Shopify, you can just ask what you want to see - "Show me a dashboard comparing Facebook Ads spend vs. revenue by week for this quarter" - and our AI analyst builds it for you in real-time. No LookML modeling, no BI tool learning curves, just instant dashboards that are always up-to-date.