Argon2id internal iterations vs multiple Argon2id calls ? TLDR; 
Is there a security risk if rather than setting the iteration parameter to 12 (for example), we set it to 3 but call the function 4 times?

I'm asking that for 2 reasons:

Firstly, we use SRP protocol where the deprecated SHA1 is replaced by Argon2id inside our PWA (Progressive Web App, so in JavaScript) but Firefox and Google currently discuss to inform user when an operation take too much CPU or RAM. Their goal is to fight against website that doing bitcoin's mining in the background. I don't want this require user's confirmation each time we use Argon2.

Secondly, as we can't known which CPU/RAM are available for the smartphone in JavaScript, we can't known the ideal number of iterations to ideally doing, so we need to find this with the help of a chronometer, we can call Argon2id as many time as possible until 3 seconds elapsed. Of course, we also keep in memory the number of calls used the first time, to do the exact same number of calls the next time we want to compare. 

BTW, the last RFC 8018 of January 2017 still recommend PBKDF2 and this KDF is natively supported in browser (WebCrypto API) and faster than any external library, so may be the solution is to not use Argon2 and to use WebCrypto PBKDF2, with the same method of multiple calls until 3 seconds elapsed?
I'm adding my solution here for the record. 

Rather than calling multiple times the Argon2d function when the user sign in, we can do something smarter, with a research of the best settings when the user sign up. 

We can inform him we will take few seconds to adjust the security while 5 ~ 10 seconds. So if the browser block the process and warn the user, he's already informed and can let continue the process. 

Technically, we trying different settings from the lower values (1MB / 1 iteration) until the delay measured require at least 1 second. Then, we could save the settings to use for this user's device. When the user sign in, we simply use the associated settings, and this will not take more than 1 ~ 2 seconds. So in theory this shouldn't be blocked by the browser, and we increase security in following the device's capabilities.

Some real tests:


Apple iPhone 4S (512MB - 1Ghz): ~1.7s ==> m=1MB,t=1
Apple iPhone 5 (1GB - 1.3Ghz dual-core): ~1.2s ==> m=4MB,t=1
Samsung S8 (4 GB, 2.3GHz / 1.7GHz quad-core each): ~1.4s ==> m=24MB,t=2
NUC i3 (8GB - 1.7Ghz quad-core): ~1.4s ==> m=24MB,t=2


Any feedback are welcome.