We recently published an introduction to HTTP/2 and how it’s likely to change our approach to web performance optimisation. In this post, we look at a very specific aspect of HTTP/2: server push.
Imagine you’re a browser looking for a web page. You trawl the worldwide web for the right address, and eventually you find it. Think of it as a small shop among billions of others – a shop you decide to enter…
Loading a web page with an external CSS file
The bell rings as you walk through the door. A shopkeeper emerges from behind the counter and greets you with a cheerful, “Good morning. How can I help you today?”
“I’d like this web page please.” You hand him a piece of paper.
“Certainly. Just a moment.” He hunts the shelves at the back of the shop and locates a small box, which he hands to you. “There you are.”
“Thank you.” You can’t resist peeking inside the box before leaving. And it’s just as well you did. You call the shopkeeper just as he’s about to disappear into a back room, “Excuse me!”
“It says here I need a CSS file to go with this page before I can start to display it.”
“Well, could I have it please?”
The conversation is starting to feel a little one-sided, but the shopkeeper is as good as his word and produces another small box.
“Not at all. Please call again.”
When you visit a web page, multiple requests/responses for different resources on that page can slow it down. In particular, external CSS files have to be downloaded and parsed before the page can begin to display.
Figure 1 – A web page with an external CSS file
Loading a web page with inlined CSS
A few weeks pass, and you’ve lost your copy of the web page (although you’ve held on to the CSS file). You go to the shop again.
“Hello again. I’d like this web page please.”
“Yes, of course.” Again, you’re given a box. It seems bigger and heavier this time. You look inside. The shopkeeper explains, “It’s all included now.”
“The CSS – it comes with the web page. Well, they thought it would be easier that way. No need for you to go back and forth, asking for the CSS every time.”
“But I’ve already got–” you hold up the box of CSS from your last visit. “Oh, never mind.”
By inlining certain resources, such as critical CSS, in the HTML, you can cut down on the number of requests and responses, and improve load times. However, this means that those resources can no longer be cached separately and are delivered to visitors every time.
Figure 2 – A web page with inlined CSS
HTTP/2 and server push
The next time you pass the shop, it looks a bit different: there’s a big sign above the door, which proudly proclaims: ‘NOW USING HTTP/2!!!’.
Curious – besides, you need a copy of that web page again – you go inside.
“Hello – I’d like this web page please.”
“Here you are.” Once more, the shopkeeper retrieves a box from one of the shelves. “Now, before I give this to you,” he continues, “you’ll need some CSS to go with it. Would you like me to put it in the box for you?”
This is a positive development. “Actually, I already have the CSS for this page. But thanks for asking.”
He hands you the box and you walk out, happy that you have just what you need – no more and no less – and to have got it quickly.
In HTTP/2, server push means that the server can deliver resources to the client without the client having to ask for them, offering the same benefits as inlining. It can use a PUSH_PROMISE frame to tell the client about resources it intends to send. However, unlike inlining, with server push the client has the option to decline these extra resources (using a RST_STREAM frame) – for example, if they’re already cached.
Figure 3 – How server push can deliver the same benefits as inlining CSS
Alex is a member of the professional services team at NCC Group Web Performance.