Tableau Quiz: Performance Recorder
10 questions · exam conditions
0:00
Performance RecorderQuestion 1 of 10

An author starts Performance Recording, spends a minute reviewing an already loaded dashboard, clicks a filter, opens another sheet, and then stops the recording. The author wants to measure only the filter's response time.

What approach would produce the clearest output for that objective?

Use the existing recording's total duration because idle review time is assigned to the filter interaction.
Create a new recording that begins just before the filter action and ends immediately after the view stabilizes.
Keep recording longer because additional actions make Performance Recorder isolate the filter more accurately.
Select the longest event because it must have been triggered by the filter rather than by opening the sheet.
← Back to quizzes

Tableau Quiz

Tableau Quiz: Performance Recorder

Practice Performance Recorder in Tableau with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Performance Recorder, giving you a quick way to practice the rules, question types, and explanations that matter most for Tableau.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

An author starts Performance Recording, spends a minute reviewing an already loaded dashboard, clicks a filter, opens another sheet, and then stops the recording. The author wants to measure only the filter's response time.

What approach would produce the clearest output for that objective?

  1. Use the existing recording's total duration because idle review time is assigned to the filter interaction.
  2. Create a new recording that begins just before the filter action and ends immediately after the view stabilizes. (correct answer)
  3. Keep recording longer because additional actions make Performance Recorder isolate the filter more accurately.
  4. Select the longest event because it must have been triggered by the filter rather than by opening the sheet.
Explanation: When working with Tableau's Performance Recorder, the key principle to internalize is garbage in, garbage out — the recording captures everything between Start and Stop, so the quality of your insight depends entirely on how precisely you scope the recording window. If you want to isolate a single interaction like a filter click, the cleanest approach is to start a fresh recording immediately before that action and stop it as soon as the view finishes rendering. That tight window means the timeline contains almost exclusively filter-related events, giving you an unambiguous picture of what's slow. This is exactly what B describes, and it's the correct answer. A is wrong because Performance Recorder doesn't "assign" idle time to nearby interactions. If you spend a minute passively reviewing a dashboard, that time appears in the recording as its own events (or silence), not bundled into the filter click that comes later. Long idle gaps pollute the timeline and make it harder, not easier, to interpret results. C reflects a common misconception — that more data helps the tool "figure out" which event matters. Performance Recorder doesn't analyze intent; it simply logs what happens. Adding more actions adds more noise, not more clarity. D is a logical trap. The longest event in a busy recording could easily be the sheet-load or a slow query triggered by something else entirely. Duration alone tells you nothing about causation. Study tip: On Performance Recorder questions, always ask yourself what's in the recording window? Precision of scope = precision of output. When in doubt, start over with a tighter recording rather than trying to interpret a cluttered one.

Question 2

A dashboard contains twelve worksheets. Its Performance Summary shows that Executing Query has the largest total duration. Several query events overlap, and only one worksheet appears late on screen.

Which use of the Performance Recorder output would best identify whether that worksheet is actually on the critical path?

  1. Use only the category total because the worksheet associated with the largest event category must finish last.
  2. Count each worksheet's marks because the worksheet with the most marks must own the slowest query.
  3. Add every query duration because the worksheet owning the largest cumulative sum must control elapsed time.
  4. Correlate the worksheet's detailed events with their positions and dependencies on the event timeline. (correct answer)
Explanation: When analyzing Tableau's Performance Recorder, the key concept being tested is critical path analysis — understanding that total elapsed time is determined not by which event takes the longest in isolation, but by which sequence of dependent events controls the overall completion time. Overlapping events run concurrently, so simply finding the biggest number in one dimension doesn't tell you what's actually causing the delay. Answer D is correct because the Performance Recorder's event timeline shows you both timing and dependency. By mapping a specific worksheet's events — when they start, how long they run, and whether they block subsequent events — you can trace whether that worksheet's query sits on the sequential chain that determines when the dashboard finishes rendering. A worksheet that appears late on screen may be waiting on a dependency, not necessarily running the longest query itself. Answer A fails because the largest event category total is an aggregate across all worksheets. A category dominating total duration doesn't mean one particular worksheet is the bottleneck — that duration could be spread across many fast, parallel queries. Answer B is a distractor built on a false proxy: mark count reflects data density, not query complexity. A worksheet with ten marks could hit a slow, unoptimized data source while one with thousands runs instantly. Answer C is tempting because summing durations sounds rigorous, but adding durations ignores overlap. If two queries run simultaneously, their combined sum exceeds actual elapsed time — cumulative sums misrepresent wall-clock impact. As a study tip, whenever Tableau performance questions mention overlapping events, that's your signal to think about concurrency and critical path — the bottleneck lives in the sequence, not the largest single number.

Question 3

In a recording, the Events Sorted by Time view reports 1414 seconds for Executing Query. Detailed events show that one query took 1010 seconds, while eight other queries each took about half a second.

What is the best next step before redesigning the entire workbook?

  1. Remove all eight short queries because the number of query events is more important than their individual durations.
  2. Optimize dashboard layout first because the total query duration necessarily includes worksheet layout calculations.
  3. Replace the data source immediately because any double-digit query total proves the database is underpowered.
  4. Inspect the long event's worksheet and query details because one query accounts for most of the category total. (correct answer)
Explanation: When analyzing Tableau performance recordings, your goal is to isolate the bottleneck before taking action. The Events Sorted by Time view gives you category totals, but the real diagnostic power comes from drilling into individual events within each category. Here, the 1414-second "Executing Query" total breaks down as roughly 10+8(0.5)=1410 + 8(0.5) = 14 seconds. That single 1010-second query represents over 70%70\% of the category's total time. The smartest move is to inspect that specific query's worksheet and SQL details — which is exactly what D recommends. You can then target a real, measurable problem rather than guessing. A is wrong because query count is not the primary concern — duration is. Eight queries at half a second each contribute only 44 seconds combined. Removing them would barely improve performance and might break functionality. B is wrong because worksheet layout calculations are tracked in a separate event category (typically "Layout"). The query execution time reflects database round-trips, not layout rendering, so redesigning the dashboard layout won't address a slow SQL query. C is wrong because a double-digit total alone doesn't indict the database. The problem could be a poorly written query, a missing index, or a Tableau calculation that generates inefficient SQL — all fixable without replacing the data source. Strategy tip: On performance-related exam questions, always follow the data to the single largest contributor before prescribing a solution. Tableau's performance recording is designed for exactly this kind of drill-down — recognize the pattern of "total → category → individual event" as your diagnostic workflow.

Question 4

A dashboard's data queries complete quickly, but the Performance Recorder output contains several long Computing Layout events after the query activity. The dashboard includes many worksheets, containers, legends, and high-mark-density views.

Which conclusion and follow-up action are best supported by the recording?

  1. Client-side presentation work is a likely bottleneck, so simplify the dashboard structure and reduce unnecessary views or marks. (correct answer)
  2. Database execution is the likely bottleneck, so add indexes to the fields used by the dashboard filters.
  3. Query compilation is the likely bottleneck, so replace all calculated fields with source-system columns.
  4. Network transfer is the likely bottleneck, so publish the same dashboard to a geographically closer site.
Explanation: When analyzing Performance Recorder output, your job is to match the type of slow event to its root cause. Tableau's recorder breaks performance into distinct phases: query execution, data retrieval, layout computation, and rendering. Each phase points to a different bottleneck and a different fix. Here, the clue is that queries complete quickly but Computing Layout events are long. Computing Layout is a client-side process where Tableau calculates how to arrange and render dashboard objects — containers, worksheets, legends, and marks. When a dashboard is structurally complex (many nested containers, numerous sheets, dense mark counts), this layout phase becomes expensive, and it shows up exactly as described in the passage. Answer A correctly identifies this as a client-side presentation bottleneck and recommends the logical fix: simplify the dashboard structure and reduce unnecessary views or marks. Answer B points to database indexing, which would address slow query execution events — but the passage explicitly says queries are fast, so the database isn't the bottleneck. Answer C targets calculated fields and query compilation, which again would appear as slow query or compilation events in the recorder, not layout events. Answer D frames the problem as network latency, which would manifest as slow data transfer events, not Computing Layout events — and publishing to a closer site wouldn't touch rendering complexity at all. The key study habit here: always match the Performance Recorder event type to its cause before choosing a remedy. Computing Layout → simplify dashboard structure. Slow queries → optimize data source. This event-to-cause mapping is a reliable pattern on Tableau performance questions.

Question 5

A Performance Recorder output shows one query taking 1111 seconds during a Monday morning test. A database monitoring tool also reports unusually high concurrent workload at that time.

Which statement is the most defensible conclusion from this evidence?

  1. The workbook's query design is defective because any query exceeding 1010 seconds indicates a workbook-level problem.
  2. Query execution dominated this run, but the high concurrent workload means retesting under controlled conditions is needed before attributing the delay to workbook design. (correct answer)
  3. Concurrent workload can be ignored because Performance Recorder only captures time caused by workbook design choices, not external database conditions.
  4. The database is defective because recorded query duration reflects only database processing and cannot be influenced by workbook calculations or filters.
Explanation: When interpreting Performance Recorder data, you must distinguish between what the tool measures and what that measurement means. Performance Recorder captures elapsed time for each phase — including query execution — but elapsed time is influenced by both workbook design and external conditions like server load, concurrent users, and network latency. A single timed run under unusual conditions is a data point, not a verdict. That's why B is the most defensible conclusion. The 1111-second query execution time is real, but the simultaneous report of high concurrent workload introduces a confounding variable. You cannot isolate workbook design as the cause without retesting under controlled, low-load conditions. B acknowledges what the data shows while correctly flagging what it cannot yet prove. A is wrong because no universal threshold like 1010 seconds defines a "defective" workbook design. Query duration depends on data volume, complexity, and environment — a blanket cutoff is not a Tableau diagnostic standard, and the evidence doesn't support that leap. C is wrong in the opposite direction: it dismisses the concurrent workload entirely, claiming Performance Recorder only captures workbook-caused delays. That's false. Performance Recorder measures wall-clock elapsed time, which absolutely includes delays caused by external database pressure. D is wrong because it swings too far toward blaming the database, and it mischaracterizes what query duration reflects. Workbook choices — like poorly written calculations pushed into the query or unfiltered extracts — absolutely influence query execution time. Your study tip: when a Tableau question involves performance data plus an external variable, the correct answer almost always calls for controlled retesting before drawing conclusions.

Question 6

An analyst records the same dashboard interaction twice. On the first run, Executing Query takes 99 seconds. Without changing the workbook, the analyst immediately repeats the interaction, and Executing Query takes 22 seconds.

How should the analyst interpret this comparison?

  1. The second result proves that the workbook permanently optimized its generated queries after the first recording.
  2. The first result should be discarded because Performance Recorder intentionally slows only the first interaction.
  3. Caching or warmed resources may explain the improvement, so tests should use controlled and representative starting conditions. (correct answer)
  4. The difference proves that Computing Layout was incorrectly classified as Executing Query during the first run.
Explanation: Whenever you see a question about Tableau Performance Recorder results, think about testing validity — specifically, what outside factors might make two measurements of the same workbook look different even when nothing actually changed. Caching is the key concept here. After the first interaction, Tableau (and the underlying database) may store query results, data extracts, or other resources in memory. When you repeat the same interaction immediately, those cached resources are already "warm," so the query completes much faster. The drop from 99 seconds to 22 seconds is a textbook caching effect, not evidence that the workbook itself changed. This makes C correct: you should account for caching and starting conditions before drawing any conclusions from a performance comparison. A is wrong because Tableau does not permanently rewrite or optimize its generated SQL between runs automatically — the workbook is unchanged, and no lasting optimization occurred. The speed improvement is environmental, not structural. B is wrong because Performance Recorder does not artificially throttle the first run; it simply measures what actually happens, which naturally includes cold-start overhead like cache misses. This is a trap that conflates "slower first result" with "intentional interference." D is wrong because event misclassification between Computing Layout and Executing Query is unrelated to the timing difference observed here — there is no evidence of mislabeling, and this explanation is invented without basis. As a study strategy, remember: always consider cache state when comparing performance recordings. Valid performance testing requires a controlled, consistent starting state — typically a cleared cache — so that both measurements reflect the same conditions.

Question 7

A workbook uses data blending. Performance Recorder shows short Executing Query events for both the primary and secondary data sources, followed by a long Blending Data event.

Which interpretation is most consistent with this event sequence?

  1. Retrieval is relatively fast, but combining results from the separate sources is consuming substantial time after the queries return. (correct answer)
  2. The database is spending substantial time executing a physical join before returning rows to Tableau.
  3. Tableau is spending substantial time generating an extract before either data-source query can begin.
  4. The dashboard is spending substantial time positioning objects after all blended marks have been rendered.
Explanation: When reading Performance Recorder output, your job is to match each event type to its corresponding Tableau process. The three key phases in data blending are: querying each source independently, then combining those results inside Tableau's engine. The timing of each event tells you exactly where time is being spent. Here, both data source queries return quickly (short Executing Query events), but the Blending Data event is long. This directly points to A — retrieval is fast, but the post-query combination step is the bottleneck. Data blending works by executing separate queries and then joining the results in Tableau's local memory using a linking field. When that in-memory merge is slow, the Blending Data event is where you'll see it. B describes a physical join happening inside the database — but blending never pushes a join to the database. Each source is queried independently, so a slow database join would show up as a long Executing Query event, not a long Blending Data event. C is wrong because extract generation is a separate, one-time process that would appear as its own distinct event before any query execution — it wouldn't surface during a normal blending workflow. D refers to layout rendering, which would appear as a rendering or layout event after marks are drawn, not as a Blending Data event at all. A useful pattern to internalize: in Performance Recorder, the event name tells you the process, and the event duration tells you the bottleneck. When troubleshooting blending slowness, always check whether the delay lives in the queries or in the blend itself — they have very different fixes.

Question 8

A Performance Recorder timeline shows Query A from 00 to 66 seconds, Query B from 22 to 77 seconds, and a Computing Layout event from 77 to 88 seconds.

Which interpretation of the recorded dashboard load is most accurate?

  1. The load took about 1212 seconds because the durations of all three events should be added.
  2. The load took about 88 seconds because the two query events overlapped for part of the timeline. (correct answer)
  3. The load took about 77 seconds because layout computation is not included in recorded load time.
  4. The load took about 66 seconds because only the longest individual event determines elapsed time.
Explanation: When reading a Performance Recorder timeline in Tableau, the key is understanding that elapsed wall-clock time — not the sum of individual durations — determines how long a dashboard load actually took. Think of it like watching a stopwatch: it starts when the first event begins and stops when the last event ends, regardless of how many things happen in between. In this scenario, Query A starts at 00 seconds and Query B starts at 22 seconds, meaning they run concurrently for four seconds (from 22 to 66 seconds). After Query A finishes at 66 seconds, Query B completes at 77 seconds, and then Computing Layout runs from 77 to 88 seconds. The timeline begins at 00 and ends at 88, making the total recorded load time approximately 88 seconds — which is why B is correct. Answer A incorrectly adds the individual durations (6+5+1=126 + 5 + 1 = 12 seconds), treating overlapping parallel events as sequential. This is a classic trap: summing durations ignores concurrency entirely. Answer C suggests excluding the Computing Layout event, but the Performance Recorder captures all events contributing to the load experience — layout computation is part of the recorded timeline and counts toward total elapsed time. Answer D claims only the longest single event (Query A at 66 seconds) matters, which would only be true if no events extended beyond it — but Query B and the layout event both push the timeline further. Your study tip: always trace the timeline endpoints in Performance Recorder questions — find when the first event starts and when the last event ends, and subtract. Never add durations when events overlap.

Question 9

While recording a dashboard-opening test, an author also triggers an extract refresh. The output shows a long Generating Extract event, while the dashboard's Executing Query and Computing Layout events are comparatively short.

What should the author conclude about the dashboard-opening performance?

  1. The dashboard's visual layout is slow because extract generation is included within Computing Layout.
  2. The dashboard's database queries are slow because extract generation is another name for Executing Query.
  3. The dashboard is inherently slow because the longest event in any recording defines its normal opening time.
  4. The recording is dominated by the refresh activity, so opening performance should be tested separately without that action. (correct answer)
Explanation: When using Tableau's Performance Recorder, understanding what you actually recorded is just as important as reading the output. The recorder captures every event that occurs during your session — not just the actions you intended to test. This means unrelated activity can skew your results dramatically. In this scenario, the Generating Extract event dominates the recording because an extract refresh was triggered alongside the dashboard open. That refresh is a completely separate process from the dashboard's rendering pipeline. The long duration reflects the cost of rebuilding the extract, not anything about how the dashboard loads. D is correct: because the recording is contaminated by refresh activity, you cannot draw valid conclusions about dashboard-opening performance. You need a clean recording that isolates only the dashboard open. A is wrong because Computing Layout covers how Tableau arranges visual elements on screen — it has nothing to do with extract generation. These are distinct event types in the Performance Recorder output. B is wrong because Executing Query refers to database or data source queries that power the viz, not extract generation. The two are separate events with separate meanings. C is wrong because the longest event in a recording does not define the dashboard's "normal" opening time — it only tells you what took the most time in that specific session, which may include irrelevant actions entirely outside the dashboard's load process. The key study tip here: always evaluate whether your Performance Recorder session is clean. If you accidentally triggered other workflows — refreshes, navigation, filters — during recording, those events will appear in the timeline and mislead your analysis. Isolate the action you want to measure.

Question 10

A recording contains repeated long Compiling Query events, but the corresponding Executing Query events are short. The data source administrator reports that each submitted statement finishes quickly.

Where does the recording most strongly suggest the delay occurs?

  1. In database processing after the completed statement has been submitted to the data source.
  2. In dashboard layout after the marks have already been returned and displayed to the user.
  3. In Tableau's preparation or generation of queries before the data source executes them. (correct answer)
  4. In blending returned results from multiple sources after all database work has completed.
Explanation: When analyzing Tableau performance recordings, the key is to match where time is actually being spent based on the event durations you observe. Each phase of query execution has its own event: Compiling Query covers Tableau's internal work of building and preparing the query, while Executing Query covers the time the data source spends running it. Here, the recording shows long Compiling Query events paired with short Executing Query events — and the database administrator confirms the submitted statements finish quickly. That combination points directly to C: the bottleneck is in Tableau's own query preparation before anything reaches the database. The data source isn't the culprit; Tableau is spending excessive time generating or optimizing queries internally. A is incorrect because "database processing after submission" would show up as long Executing Query events, not long Compiling Query events. The scenario explicitly tells you execution is fast. B is wrong because dashboard layout and mark rendering happen after query results are returned — those delays would appear in rendering-related events, not query compilation. D is a tempting distractor if you think about data blending, but blend-related delays occur during result processing after data returns from multiple sources, not during the compilation phase described here. A useful rule of thumb: always match the delay to the specific event where time accumulates. Long Compiling Query = Tableau-side query generation problem. Long Executing Query = data source problem. Keeping this mapping clear will help you quickly eliminate distractors that misattribute delays to the wrong phase of the pipeline.