Say a server wants to hash a password $p$. It would use a secure hash function $H$ and a unique salt $s$ to hash the password as $H(p,s)$. If one has access to the salt, each password candidate requires one run of the hash function to be ruled out; the same amount of time it would take for the server to verify a password candidate.
If, on the other hand, the password was hashed as $H'(p,s+r)$, where $r$ is a random integer in the range $[0,n]$ and that is not stored anywhere. Verifying a correct password would require on average $n/2$ runs of $H'$, whereas ruling out an incorrect password candidate would require $n$ runs of $H'$, i.e. twice as slow for the attacker than for the server.
I'm thinking that this means that if $H'$ is $n$ times faster than $H$, this yields up to twice as fast password validation for the server but equally slow password testing for an attacker as before. And one could then use this either to make the sign-in quicker for users or the hash function slower for an attacker.
Are there any obvious issues with this approach or ways to improve it?
The idea here is for there to be many different options for what is stored in the database and that more of these options need to be tried for an attacker than for the server. This could also be implemented in ways that don't use it as a salt. E.g. password hash $=H_r(p,s)$, where $H_r$ denotes the number of iterations of the hash, i.e. $r=3\rightarrow H_r=H'(H'(H'(p,s)))$.
An attacker would need to calculate $n$ hashes for each password but the server only needs to calculate $r$ hashes to validate a correct password (and $n$ hashes to reject an incorrect password).