In the usual browsing situation, it also doesn't have to be a blocking verification before displaying the first bytes from a site (requiring subsecond checking). It could load the page but continue verification in the background, only becoming a blocking warning some number of seconds later, when the user enters form data or attempts other navigation.
In fact, even minutes into a session, the information that either – (a) it took a while but we now see that this certificate is definitely bad; or (b) you are currently so cut-off from the real "Internet" that suspicion towards all sites is justified – is useful.
That is, even a "delayed hard fail" would still be useful.
The alternative is that people chat, transact, etc. indefinitely at the mercy of attackers, because the browser isn't even trying to acquire good data via censor-resistant channels.
While sitting in a meeting I realized there is one situation that online revocation helps: someone steals bank.com's DNS record. They can't necessarily MITM anyone with that.
But, TACK is probably a better countermeasure there.
A service with a clear single point to DDoS is obviously the wrong choice.
What if services all over the net could tell you the latest (<5 minutes old) root/summary-hash of the shared dataset? And, there are many places to either update yourself to that version, or receive a trustworthy proof a certificate is/isn't in that dataset?
If they're all blocked, an alarm should go off, letting the user know it's dangerous to proceed. The failure shouldn't be secret, with the confidence-inspiring lock icon still appearing, for indefinitely long periods.
"If the bad guy can MITM your browser going to www.bank.com, they can break your browser going to the online revocation list."
(Implicit: the browser will fail open to connect to the website anyway in case it can't connect to the revocation list.)