For the longest time I didn’t really get the heartbeat API. I get the very basics of it, but it took me a while to understand what it was really doing.
We’re used to interacting with our websites in a very one-directional way. I click a link, I go to a page. Heartbeat API is a bi-directional communication, which can best be translated as ‘shit happens without you having to click.’ The browser and the server are happily chatting to each other all the time, without me having to do anything.
If you’ve ever used Google Docs or MS Word or Apple Pages and noticed you don’t have to press ‘save’ all the time, that’s the idea of a Heartbeat API. It does the background things for you. That thing you should do (save often). In WordPress, the most obvious thing that Heartbeat does is it saves your posts as revisions.
That doesn’t stop neurotics like me from pressing ‘save’ all the time.
Of course, this can get a little expensive, checking all the time, so the Heartbeat API is smart. It only checks every 15 seconds by default (you can change this), and it only checks when you’re on a page doing something. If you just leave a page open, it slows down and, after an hour, turns off.
But besides saving, the Heartbeat API can share information between the systems. For example, it can ping out to Jetpack and check if it’s up and everything’s working, or if you have to reconnect your LinkedIn settings. And since it’s javascript based, it doesn’t reload the page.
You can use it to alert logged in users to new content. Imagine a post that suddenly had an overlay of ‘This post has been updated…’ Doing that requires two parts:
- Hook into the send call and add your data
- Hook into the receive call and show the data
Pippin has a great heartbeat API example but he also warns people:
I’ve managed to bring down server servers by using the Heartbeat API on the frontend.
If you trigger things to be called too often, you can totally crash a server.
The Heartbeat API is a step towards making our sites really responsive and modular. Instead of statically checking via PHP if someone’s logged in and changing display based on that, Heartbeat can dynamically change on the fly. This would allow caching systems like Varnish or static-file caches like WP Super Cache, to save the cache and speed up your site while still being dynamic. It lessens the weight on wp_ajax_ and makes things work with caches, rather than bypass them.
And that will make our sites beat faster for everyone.
Comments
3 responses to “Heartbeat API”
Heartbeat definitely can be a good thing. But sometimes it can be a bit of too much of a good thing, I’m afraid.
I have a number of WordPress sites on a shared server account, so right there resources are a concern.
I found that while Heartbeat didn’t have a huge impact on my server usage, turning it off on all of my sites lowered my usage a noticeable amount.
@Ken: I wonder if that had more to do with the plugins running on the shared host or just the host in general. There is a real problem with people setting the pulse too fast that can kill things.
Is there a good way to check the various plugin pulses? That would be an interesting exercise of discovery!