Keep units visible in the code
Choose one time unit and use it consistently. If velocity is expressed in pixels per second and delta is in seconds, position advances by velocity multiplied by delta. A useful manual check is a ten-second movement: a marker configured for 80 pixels per second should travel about 800 world pixels, independent of the number of renders.
Avoid mixing milliseconds from performance.now() with a per-second velocity unless you divide by 1,000. Name values with their units, such as deltaSeconds or speedPixelsPerSecond, so a later tuning change does not quietly turn a small movement into a thousandfold one.
Bound the effect of a hitch
For a simple action game, cap delta at a deliberately chosen maximum and accept that simulation slows briefly under severe load. For a physics simulation that needs repeatable steps, accumulate time and advance in fixed increments; cap the number of catch-up updates so recovery itself cannot monopolize the page. These approaches make different tradeoffs, so choose from the feel and rules your game needs.
Test with an artificial pause between updates, then compare a straight-line movement and a collision at the end of the path. If the object tunnels through a thin obstacle, smaller substeps or a swept collision test may be needed; changing the render rate alone will not fix that rule-level problem.
Questions about delta time in games
Does delta time make physics deterministic?
No. Variable update intervals can still produce different integration results. A fixed simulation step improves repeatability, though input timing and floating-point details still matter.
Which clock should supply elapsed time?
Use the animation callback timestamp or performance.now(), both high-resolution timing sources described by MDN. Do not use wall-clock dates for short frame intervals because system clock adjustments are unrelated to simulation time.