Yes, in fact it was already on the to-do list. The XenForo version of this plugin already had it implemented:
Although it was more about preventing API request limits than it was about making editing a post faster (the API request is done in a fraction of a second).
The reason it wasn’t already done is we ran we’re seeing situations where some WordPress installations had the normal cron system disabled for whatever reason. So instead of the cron/job system, we’d instead make the underlying API request run in parallel to other items rather than sequentially. Then it’s still done in real-time, not relying on WP cron system to be enabled/working, but also decoupling the API calls from needing to wait to finish.
Thread Starter
net
(@krstarica)
You could check if the cron job is disabled, display a warning about it in the settings, and deactivate the purge on cron mechanism.
Probably just going to do a check if cron is disabled or not, but rather than presenting a message about it, just do it one way or the other (if cron is disabled, do it in realtime/inline like it’s done now). The end result is that it works either way. If someone chooses to disable cron, there’s probably a reason, we don’t need to tell them to enable it.
It’s implemented and tested at this point and will be part of the next release.