ABC Tools

Critical Swim Speed and SWOLF, Explained

After reading this you can turn a 400 m and a 200 m time trial into a threshold pace per 100 m, build five training zones around it, and read a SWOLF score without fooling yourself.

What critical swim speed measures

Critical swim speed (CSS) is an estimate of the fastest pace you can hold for a long time without your effort creeping upward. Think of it as the swimming version of a running threshold. It is the pace where energy supply and energy clearance roughly balance, so you can sit there for maybe 30 to 60 minutes rather than a few hard minutes.

The method behind it is simple. Swim two efforts at different distances, both all-out. The longer effort is slower per 100 m because you had to ration your energy. The shorter effort is faster because you could spend freely. The rate at which extra distance costs extra time is your sustainable speed. Everything faster than that is borrowing against a fixed reserve.

Here is the hook. Suppose your 400 m takes 6:40 (400 seconds) and your 200 m takes 3:10 (190 seconds). The extra 200 m of the longer swim cost you 400 - 190 = 210 seconds. That is 210 seconds for 200 m, or 105 seconds per 100 m. That single number, 1:45 per 100 m, is your CSS pace. The rest of this article is about trusting it and using it.

When to use it, and when not

Use CSS when you want a training anchor that does not need a lab or a heart rate strap. Pool swimming makes heart rate awkward to read, and perceived effort drifts as you fatigue. A pace in seconds per 100 m is objective: the clock does not lie. CSS gives you one number to build sets around, and it responds to fitness, so you retest every 4 to 6 weeks and watch it move.

Do not use CSS to compare yourself to other swimmers with different technique, and do not treat it as a race predictor for events far from 200 to 400 m. The two-distance model is a straight line fitted through two points. Extrapolate it to 1500 m and the error grows. It also assumes both trials were genuinely maximal. If you paced the 400 like a workout, your CSS comes out too fast and every zone below it inherits the error.

The single biggest source of a wrong CSS is a soft 400 m. If the 200 m and the 400 m per-100 paces are almost identical, one of the swims was not all-out. A real gap of 3 to 8 seconds per 100 m between them is normal.

The formula and why it works

Model the time t for a distance d as a straight line: a fixed cost plus a steady cost per meter.

t = t_0 + \frac{d}{v}

Here v is critical swim speed in meters per second, and t_0 is the offset that captures the fast start and any anaerobic reserve. With two trials, (d_1, t_1) and (d_2, t_2), the slope between them gives the speed directly.

v = \frac{d_2 - d_1}{t_2 - t_1}

The denominator is the extra time, the numerator is the extra distance. For the standard test, d_2 = 400 and d_1 = 200, so the numerator is always 200 m. To convert speed into a pace per 100 m, which is how swimmers actually think, invert and scale.

P_{100} = \frac{100 \cdot (t_2 - t_1)}{d_2 - d_1}

P_{100} is your CSS pace in seconds per 100 m. Because d_2 - d_1 = 200 for the classic test, this reduces to (t400 - t200) / 2 in seconds. That is the whole calculation. Everything else is dividing that pace into zones.

A worked example with the demo numbers

400 m in 6:40, 200 m in 3:10

  1. Convert to seconds: t400 = 6:40 = 400 s, t200 = 3:10 = 190 s.
  2. Extra time for the extra 200 m: 400 - 190 = 210 s.
  3. CSS pace per 100 m: 210 / 2 = 105 s, which is 1:45 per 100 m.
  4. CSS speed: 100 / 105 = 0.952 m/s, or v = 200 / 210 = 0.952 m/s from the two points directly.
  5. Sanity check the two trial paces. The 400 ran at 400/4 = 100 s per 100 m. The 200 ran at 190/2 = 95 s per 100 m. Both are faster than 105? No: the 400 pace (100 s) is faster than CSS (105 s), which tells you the offset t_0 is negative in this fit.

That last point matters. With these particular demo times the 400 m pace (100 s per 100 m) is actually quicker than the computed CSS (105 s per 100 m), which is physically odd for a truly maximal 400. It is a sign the 200 was not much faster per 100 than the 400. In real testing you want the 200 clearly faster, say 90 s per 100, which would push the gap wider and give a more believable CSS. Treat the demo as a button you can click, not as a model of a well-run test.

Building the five training zones

Once you have CSS pace, zones are simple multipliers on that pace per 100 m. Slower zones add seconds, faster zones subtract them. The table uses a CSS of 105 s per 100 m and the offsets ABC Tools applies.

Zones around a CSS of 1:45 per 100 m
ZonePurposeOffset vs CSSPace /100 m
1 EasyRecovery, warm-up+10 to +14 s1:55 to 1:59
2 AerobicEndurance base+6 to +9 s1:51 to 1:54
3 ThresholdAt and around CSS-2 to +5 s1:43 to 1:50
4 VO2Hard intervals-6 to -3 s1:39 to 1:42
5 SpeedShort, near maxfaster than -6 s1:38 and under

The logic is that pace changes little for large changes in effort in the water, because drag rises with the square of speed. Cutting your 100 pace by 6 seconds is a big jump in cost. That is why the zone bands are only a few seconds wide, not the 30-second-per-mile bands runners are used to.

The bars sit within a narrow band, about 20 seconds from easiest to fastest. Swimming pace compresses because drag grows with speed squared.

Without JavaScript: try changing the 200 m time in the calculator. Every second you shave off the 200 m widens the gap to the 400 m by one second, which lowers CSS pace by half a second per 100 m. A 200 of 3:00 (180 s) against a 400 of 6:40 gives a gap of 220 s and a CSS of 110 s per 100 m.

Reading a SWOLF score

SWOLF (swim + golf) is an efficiency score for one length. Add the seconds you took to the strokes you took. Lower is better, like golf.

\text{SWOLF} = t_{\text{length}} + s_{\text{length}}

With the demo values, one 25 m length at 30 seconds and 22 strokes gives 30 + 22 = 52. On its own that number means nothing. SWOLF is only useful as a trend for one swimmer, in one pool length, with one stroke. A 52 in a 25 m pool cannot be compared to a 52 in a 50 m pool, because the longer pool packs more distance into fewer wall pushes.

The trap is that you can lower SWOLF two opposite ways: swim faster (fewer seconds) or glide more per stroke (fewer strokes). A great score at a crawling pace is not the goal. Watch SWOLF at a fixed pace. If you hold 30 seconds per length and drop from 22 strokes to 20, that is real efficiency: 52 becomes 50 for the same speed.

Track SWOLF at your CSS pace, not at your easiest pace. Efficiency that survives at threshold speed is the efficiency that helps you race.

Common mistakes that skew the numbers

Pacing the 400 like a set
If the 400 is not maximal, the gap between the two trials shrinks and CSS comes out too fast. Rest fully between the swims, and go first with the 400 while fresh.
Rounding times to the nearest 5 seconds
A 5-second error in either trial moves CSS by 2.5 seconds per 100 m, which shifts every zone. Record to the whole second.
Comparing SWOLF across pools
25 m and 50 m pools give different scores for the same swimmer. So do freestyle and breaststroke. Compare like with like only.
Extrapolating CSS to a 1500 m race
The two-point line is fitted near 200 to 400 m. Predicted 1500 m pace from it can be off by several seconds per 100 m. Treat far-out predictions as loose.

Related tools

If you swim as part of a triathlon, feed your CSS pace into the Triathlon Time Calculator to estimate a full race time with bike and run legs and transitions. Runners looking for the equivalent threshold logic on land can use the VDOT Running Calculator for paces from a race result, or the Race Time Predictor to project longer distances. To plan hydration for long pool or open-water sessions, the Sweat Rate Calculator turns a weigh-in into a drinking plan.

Frequently asked questions

Why 400 and 200 metres specifically?

Those distances are far enough apart to give a clean slope but both short enough to swim near maximum. A 50 m sprint is too dominated by the start, and a 1500 m adds too much pacing noise. Some coaches use 400 and 100; the math is the same, just change the distances in the slope formula.

How often should I retest CSS?

Every 4 to 6 weeks. Fitness changes slowly enough that weekly testing mostly measures how tired you are, not how fit. If your CSS pace drops from 1:45 to 1:42 per 100 m over a block, that is a real 3-second gain.

My 400 pace was faster than my computed CSS. What went wrong?

Your 200 was not much faster per 100 than your 400, so the slope came out shallow. Repeat the test with a genuinely all-out 200. You want the 200 pace roughly 3 to 8 seconds per 100 quicker than the 400.

Is a lower SWOLF always better?

No. A low SWOLF at very slow speed just means long glides, not race fitness. Compare SWOLF at the same pace across weeks. Fewer strokes for the same seconds is the win.

Can I use CSS zones for open water?

The pace targets carry over, but open water adds sighting, chop and no wall push, so expect your effective pace to be 3 to 6 seconds per 100 m slower than in the pool for the same effort.

Try it yourself in the tool

Related tools

Race Time Predictor

Predict your 10K, half and marathon time from any recent race result.

VDOT Running Calculator

Daniels VDOT and easy/marathon/threshold/interval training paces from a race result.

Age Grading Calculator

Compare race times across ages: age-graded percentage and open-class equivalent.

Heat & Altitude Pace Adjuster

Adjust your goal pace for hot weather and race altitude.

Marathon Fueling Calculator

Carbs per hour, total gels and a fueling schedule for your race duration.

Race Split Calculator

Per-km or per-mile split table for a goal time, with even or negative split pacing.