The thing I check first on any backtest someone shows me is not the Sharpe or the drawdown. It is the gap between when the signal prints and when the fill lands. Most backtests quietly assume that gap is zero. The signal fires on the close of a bar and the engine fills you at that same close, as if you were standing next to the exchange with a finger on the button. Nobody trades like that. Your data feed has to arrive, your code has to evaluate, your order has to route and rest and get taken. By the time all of that happens the price has moved, sometimes in exactly the direction that made the trade look good in the first place.
So the honest question is not whether your strategy has an edge at zero lag. Of course it does, you optimized it that way. The question is how quickly that edge falls apart as the lag grows, and whether the amount of lag you can realistically remove is small enough to keep you in the green. A strategy that only works if you fill within milliseconds is a fine research finding and a terrible thing to trade from a laptop.
Why zero-lag backtests flatter you
There is a specific reason execution delay hurts more than people expect, and it has to do with what a signal actually is. A lot of retail signals are momentum-shaped. They fire because price just did something, a breakout, a cross, a volume spike. The bar that triggers the entry is often the same bar carrying most of the move you wanted to catch. Fill at that bar's close and you get the whole thing for free. Wait one bar and you have handed back the fastest, juiciest part of the move to whoever was quicker.
Mean-reversion signals have the opposite problem but end up in the same place. They fire when price has stretched too far, and the snap back is often quick. Delay the fill and you are entering after the rubber band has already started pulling you the wrong way. Either style, the first slice of time after the signal is where a disproportionate amount of the edge lives, and that is exactly the slice a zero-lag backtest hands you and real execution takes away.
The three-delay stress test
You do not need anything fancy to measure this. The idea is to re-run the same strategy, on the same data, with nothing changed except how long you wait after the signal before you fill. I usually run three settings and it is enough to see the shape.
- One bar. Fill at the open of the next bar instead of the close of the signal bar. This is the most honest minimum for any bar-based strategy. If your engine fills you on the signal bar's close, you are already cheating, because in real life you cannot act on a bar until it has closed.
- Five minutes. Fill at the price roughly five minutes after the signal. This approximates a human or a modestly slow bot: you saw it, you thought about it, you sent the order, it took a little while to fill. For most retail workflows this is closer to reality than the one-bar case.
- One hour. Fill an hour after the signal. This is the deliberately brutal one. You are not going to trade with an hour of lag on purpose, but if the strategy still holds up here, the edge is structural rather than a speed trick. If it collapses, you have learned that the whole thing was a race you were never going to win.
Run all four versions, zero lag included as the baseline, and record the same handful of metrics for each: total return, Sharpe, win rate, average trade. Then plot the metric you care about most against the delay on the x axis. That line is your decay curve, and its slope tells you almost everything.
Reading the decay curve
A robust strategy has a gentle slope. It gives up some return as lag grows, sure, but it degrades smoothly and is still clearly profitable at the five-minute mark. That is a strategy a normal person can trade, because the delay you cannot remove is small relative to the edge you have.
A fragile strategy falls off a cliff between zero and one bar. Half the return or more gone by the time you wait a single bar, negative by five minutes. When I see that shape I stop looking at everything else, because the backtest was measuring your data feed's clock, not a real market inefficiency. No amount of position sizing or risk management saves a strategy whose entire edge is standing in the queue ahead of you.
The middle case is the interesting one. The curve bends but does not break. It stays positive through five minutes and only dies somewhere past that. Here the practical move is to figure out where on that curve your actual execution lands and whether you have any honest way to move left. Faster data, a colocated bot, resting limit orders instead of chasing with market orders. If your real lag sits comfortably to the left of where the curve goes negative, you have margin. If it sits right on the edge, you are one bad fill from giving it all back.
Making the test honest
A few things that trip people up when they build this. First, delay the fill, not the decision. The signal should still be evaluated at the moment it fires. What moves is only the price you transact at. If you also shift the evaluation you are testing a different strategy, not the same one under stress.
Second, apply the delay to exits too, not just entries. A surprising amount of a strategy's paper edge is in exiting at a magic price the instant a condition flips. Delay the entry and leave the exit instantaneous and you have built a fantasy that flatters the downside. Same lag on both sides or the numbers lie to you.
Third, remember that spread and slippage stack on top of delay, they do not replace it. Delay measures how much the mid-price drifts against you while you wait. Slippage measures what you pay to cross the book once you act. A thorough stress test layers both, but even the delay curve alone will kill most of the strategies that deserve killing.
Here is the rule of thumb I keep coming back to. Before you fund anything, know the delay at which your strategy goes to zero, and know your real execution delay, and make sure there is a comfortable gap between them. If the two numbers are close, the strategy is not robust, it is just fast, and you are probably not. This is one of the checks we bake into the backtesting side of Blockcircle for exactly that reason, because a decay curve tends to end an argument that a Sharpe ratio only starts. Run the three delays, plot the line, and let the slope tell you whether you are looking at an edge or a reaction-time contest you have already lost.