Looker Dashboard Tabs: How We Cut Load Times from 2 Minutes to Under 10 Seconds

You have a dashboard with 40 tiles. Finance wants their P&L metrics. Sales wants pipeline numbers. Operations wants fulfillment data. So you put everything on one dashboard because "everyone needs to see everything."

The result: a dashboard that takes 1-2 minutes to load because it fires 40 queries simultaneously, most of which the user doesn't even look at. Users open it, wait, get frustrated, and go back to asking analysts for screenshots in Slack.

Looker's tabbed dashboard components fix this. We've used them to take dashboards from 90+ second load times to under 10 seconds — without removing a single tile, changing a single query, or restructuring a single Explore.

Here's how.

---

The Problem: Every Tile Fires on Load

When a Looker dashboard loads, every visible tile fires its query. A 40-tile dashboard means 40 concurrent queries hitting your warehouse. Even if BigQuery handles each query in 2-3 seconds, the dashboard needs to wait for the slowest one, render all the visualizations, and then display. Combined with Looker's rendering overhead, you're looking at 60-120 seconds for a complex dashboard.

The users only care about 8-10 of those tiles at any given time. But the dashboard doesn't know that.

The Fix: Tabbed Components

Looker's component framework includes a tabs feature that lets you organize dashboard tiles into tabbed sections. The critical behavior: only the active tab's queries fire on load. The other tabs' queries don't execute until the user clicks on them.

This means a 40-tile dashboard organized into 4 tabs of 10 tiles each now only fires 10 queries on initial load. Load time drops by 60-75% immediately.

Implementation

Tabs work in both User-Defined Dashboards (UI-built) and LookML Dashboards (code-defined).

In the UI dashboard editor:

1. Open the dashboard in edit mode
2. Add a Tabs component from the component library
3. Drag existing tiles into each tab
4. Name the tabs by business domain (e.g., "Revenue," "Pipeline," "Operations," "Finance")
5. Set the default tab to the most-used section
6. Save and publish

In LookML dashboards:

- dashboard: executive_summary
  title: "Executive Summary"
  layout: newspaper

  filters:
    - name: date_range
      title: "Date Range"
      type: date_filter
      default_value: "30 days"

  tabs:
    - tab: revenue
      title: "Revenue"
      elements: [revenue_summary, revenue_trend, arpu, mrr_growth]
    - tab: pipeline
      title: "Pipeline"
      elements: [pipeline_value, deal_velocity, win_rate, forecast]
    - tab: operations
      title: "Operations"
      elements: [fulfillment_rate, nps_score, ticket_volume, sla_compliance]
    - tab: finance
      title: "Finance"
      elements: [pl_summary, burn_rate, runway, budget_variance]

Filters Across Tabs

Dashboard filters can be global (apply to all tabs) or tab-specific:

• Global filters like date range, region, or business unit should apply across all tabs. Set them at the dashboard level, outside the tab definitions.
• Tab-specific filters should be placed inside the relevant tab. For example, a "Product Category" filter only makes sense on the Revenue tab.

This keeps the filter bar clean — users only see filters relevant to the tab they're viewing.

Real Performance Results

Here's what we've seen across multiple client implementations:

Metric	Before Tabs	After Tabs	Improvement
Initial load time	90-120 seconds	8-12 seconds	~90% faster
Queries on load	35-50	8-12	~75% fewer
Warehouse cost per load	High (40 concurrent queries)	Low (10 queries)	~70% reduction
User engagement	Low (users avoided dashboard)	High (opens in seconds)	Measurable in analytics

The warehouse cost reduction is often overlooked. If a dashboard is loaded 50 times per day and each load fires 40 BigQuery queries, that's 2,000 queries/day. Tabs reduce that to 500 queries/day (assuming most users only visit 1 tab). At BigQuery's on-demand pricing, the savings are material.

Best Practices

1. Organize by audience, not by data source. Don't create tabs based on your data model ("Orders Tab," "Users Tab"). Create them based on who's looking ("Sales Tab," "Finance Tab," "Ops Tab"). This maps to how people actually use dashboards.

2. Put the most-used tab first. The default tab loads immediately. Make it the one that 60%+ of users need. For most executive dashboards, that's Revenue or a high-level summary.

3. Keep each tab under 12 tiles. Tabs solve the "too many queries" problem, but a tab with 25 tiles still loads slowly. If a tab needs more than 12 tiles, consider splitting it further.

4. Use cross-filtering within tabs. Tiles within a tab can cross-filter each other (click a bar in one chart to filter the others). This works the same way within tabs as it does on a flat dashboard.

5. Don't use tabs as a crutch for bad queries. If a single tile takes 30 seconds to load, tabs won't save you — that query is slow regardless. Fix slow queries first (materialized views, table partitioning, aggregate awareness), then use tabs to parallelize the remaining load.

When Not to Use Tabs

• Single-purpose dashboards with fewer than 15 tiles that load in under 15 seconds don't need tabs. Don't add complexity for no benefit.
• Embedded dashboards where the embedding context controls which content to show. Tabs may conflict with your application's own navigation.
• Mobile dashboards where horizontal tab navigation can be awkward on small screens. Consider separate dashboards instead.

The Bigger Picture

Tabs are the single highest-ROI dashboard optimization in Looker. No model changes, no query rewriting, no Explore restructuring. Just reorganize existing tiles into tabs and your 2-minute dashboard loads in 10 seconds.

If your dashboards are slow and you haven't implemented tabs yet, start there. It's a 30-minute change that will have more impact than weeks of query optimization.

---

Labs4Change optimizes Looker dashboards and LookML models for enterprise teams. Book a free strategy call if your dashboards need a performance overhaul.