It’s the latter, but I would describe it less as Firefox not “keeping up”, and more as Google deploying
pre-standard protocols (like SPDY) into Chrome
first,
before ever documenting the protocol; let alone trying to get it turned into a standard (like HTTP/2.)
Chrome had SPDY support not just before any other web browser did, but before any open web server did—because Chrome had SPDY support before Google ever documented that there was such as thing as “SPDY.” It was, at first, just turned on as a special Chrome-to-Google.com accelerator, spoken only between that browser and that server, because only they knew it.
I don’t fault Google for this: they’re doing “internal” R&D with protocols, and then RFCing them if-and-when they turn out to have been a good design for at least their use-case with plenty of experimental data to confirm that. Which is exactly how the RFC process is intended to be used: spreading things that are known to work.
It’s just kind of surprising that “internal” R&D, in their case, means “billions of devices running their software are all auto-updated to speak the protocol, and start speaking it—at least to Google’s own servers—making it immediately become a non-negligible percentage of Internet packet throughput.” (Which is a troubling thing to have happen, if you’re a network equipment mfgr, and you expected to have some time while new protocols are still “nascent” to tune your switches for them.)