How to Build an F1 Strategy Simulator with a JavaScript Spreadsheet and OpenF1

Follow Along, Access the Demo Sample Applications GitHub Repository

Bundle OpenF1 Observations and Calculations in a JS Spreadsheet

The app uses Vite, TypeScript, HTML, CSS, and SpreadJS, with no framework or backend. A development-only script requests historical OpenF1 data, including sessions, drivers, results, laps, stints, pit stops, positions, race-control messages, and weather. It joins those responses by session and driver, validates them, and writes one normalized bahrain-race.json file. The browser loads that bundled file; it never calls OpenF1 while the workbook opens or recalculates.

OpenF1 → development-time download and normalization → bundled JSON
       → SpreadJS observation tables → formulas, charts, and What-If results

The current snapshot covers 20 drivers, 1,129 lap observations, 62 stints, 42 pit stops, and 93 race-control events. Those counts describe source observations, including incomplete records; they are not precomputed pace statistics. The JSON preserves lap and sector times, compounds, starting tire ages, pit information, timestamps, and official results. Average pace, stint trends, degradation estimates, projected times, and sensitivity grids are calculated in the workbook.

Build an Analysis Path Across Different Worksheets

The Race Dashboard starts with classification, grid-to-finish movement, pit counts, gaps, and representative pace. A pace chart compares drivers, while a second chart follows the selected driver's position at the end of each lap. Selecting a driver in the small header control updates the relevant workbook views.

Lap Analysis makes the pace calculation inspectable. It shows each recorded lap for that driver in a heatmap, then reports the clean-lap average, median, standard deviation, and count. The clean-lap mask excludes lap one, pit entry and exit, the post-pit warm-up lap, caution and restart periods, deleted laps, and unusually slow within-stint outliers. The exclusion logic is implemented with worksheet formulas, so a reader can inspect why a lap was omitted. Yellow lap numbers mark Safety Car and restart-adjacent laps, and cell notes show the corresponding race-control messages without assigning an unconfirmed cause.

Tire Strategy turns stints into a horizontal compound timeline. A driver occupies one row and race laps run across the columns; colored cells and letter labels show Soft, Medium, and Hard tires, with pit boundaries marked in place. The observed-stints table adds clean pace, best lap, wear slope, pit-lane duration, and sparklines. Its calibration cells derive default degradation and compound offsets from clean observations where the sample supports them, with visible fallbacks where it does not.

Strategy Simulator is the working model. Blue cells contain the editable assumptions: compounds, pit laps, one or two-stop strategy, starting tire age, base pace, degradation rates, compound offsets, estimated net pit loss, and fuel effect. Two per-lap ledgers appear below the results: one for the proposed strategy and one for the observed stint schedule under the same physical assumptions. A compact formula displayed above the workbook lets users inspect the selected cell instead of treating the output as a black box.

The fifth worksheet, Data, is hidden from the normal demonstration but retains the normalized observations in SpreadJS tables alongside the formula helper columns. TypeScript populates and lays out the workbook; the significant analytical calculations remain in spreadsheet cells.

Anchor a Simple Model to the Official Result

The simulator estimates every lap in seconds. Its basic calculation is:

estimated lap time = base pace
                   + compound pace offset
                   + tire age × compound degradation rate
                   − (race lap − 1) × fuel gain
                   + pit loss, when the lap ends in a stop

The positive degradation term increases with tire age. The fuel term can offset some of that increase as the car gets lighter. Neither coefficient is a claim that the workbook has recovered a team's private performance model; these are understandable, editable assumptions calibrated from limited public observations where practical.

For a full-distance classified driver, the result uses the official race duration as its anchor:

projected race time = official actual time
                    + (candidate modeled time − actual-schedule modeled time)

This matters because the two modeled totals use the same assumptions. The workbook asks how a proposed schedule differs from the observed schedule under that model, then applies the difference to the historical result. It keeps the raw modeled totals and adjustments visible. Drivers without a comparable full-distance official time can still be explored, but they do not receive an official-time projection or Goal Seek target.

Use Three Kinds of What-If Analysis

The first sensitivity grid crosses possible first-pit laps, 14 through 22, with starting-compound degradation rates ranging from 0.03 to 0.08 seconds per tire-age lap. SpreadJS evaluates the grid with the native SJS.TABLE function, and conditional formatting colors the resulting strategy delta. The formula is generated for the selected starting compound; for Medium, it is:

=SJS.TABLE($G$13,$D$32:$L$32,$C$9,$C$33:$C$38,$C$19)

Here, G13 is the strategy delta, C9 is the first pit lap, and C19 is Medium degradation. The two input ranges supply the column and row values of the sensitivity grid.

The cells show candidate time minus modeled actual time, so negative, green values favor the candidate. The same degradation input affects both ledgers. A greener cell at a higher rate does not mean tires improve with age; it can mean the modeled actual schedule is penalized more heavily than the candidate schedule. The grid also tests its fixed 14–22 pit window, even if the active scenario pits later. Reading the cell value and the two ledgers together is more informative than reading the color alone.

With Goal Seek, a user can ask how fast the base pace must be to finish five seconds ahead of the driver's official result under the currently selected strategy. SpreadJS changes the Base Pace input until the projected-time formula reaches that target. The result dialog lets the user keep the solved pace or restore the previous value.

The native Scenario Manager stores named sets of simulator inputs. The sample opens with Actual Strategy, Aggressive One-Stop, Conservative One-Stop, and Two-Stop Attack. Users can apply a scenario, save their own assumptions for the current workbook session, open the Scenario Panel, and compare formula-output snapshots. Scenario values remain in SpreadJS; the app code only coordinates driver selection and the controls around them.

What the Conservative One Stop Projection Means

Oscar Piastri is the opening driver. His observed 2025 schedule was Soft through lap 14, Medium through lap 32, then another Medium stint to lap 57; his official winning time was 1:35:39.435. The named Conservative One-Stop instead uses Medium through lap 28 and Hard for the remaining 29 laps. Under the bundled model defaults, it projects 25.44 seconds faster than his actual time.

The two ledgers show where that number comes from. One fewer modeled stop saves about 23.83 seconds. The compound pace offsets contribute about 31.07 seconds of advantage, while additional modeled tire degradation costs about 29.45 seconds. Those terms sum to a 25.44-second improvement after rounding. It is a useful demonstration of transparent sensitivity analysis, not evidence that the alternative would have won a real race. The model does not account for traffic, overtaking, altered Safety Car exposure, or uncertainty from extending a stint beyond its observed tire-age range.

Try the JavaScript Workbook and Inspect the Source Code

Open the live workbook, select a driver, and start on the Race Dashboard. Follow a slow or pit-affected lap in Lap Analysis, trace the compounds in Tire Strategy, then change a pit lap or apply a named scenario in Strategy Simulator. Select a projected result to inspect its formula, and compare it with the two per-lap ledgers before drawing a conclusion.

The source repository includes the Vite app, data-generation script, and normalized snapshot. Developers can download and run it locally using the instructions in its README.

Why F1 Data and What-If Analysis Fit Together

Formula 1 provides a rich record of what happened lap by lap, yet race strategy is about choices that could have gone another way. SpreadJS keeps both sides in one place: observed laps and stints provide the baseline, formulas expose the assumptions, and Data Tables, Goal Seek, and scenarios test alternatives. The estimates are deliberately simple, but every projected gain or loss can be traced back to a choice the reader can change.

Download a Trial of the Industry Leafing JavaScript Spreadsheet Component, SpreadJS, Today!