Re: In defense of PUSH

In my experience playing with h2, I found that browsers don’t respond to PUSH as I’d expect; for example, they don’t try to reset the stream if they’ve already got the resource cached.

So maybe there’s a chicken-and-egg in play here?

As to streaming, could what you want be done via Server-Sent Events? That fits right on top of h2 natively. Though as to a chat app, I would think trying to do something like that with anything *but* WebSocket would carry a good deal more complexity than WS.

-FG

> On Aug 31, 2018, at 2:19 PM, Matthew Phillips <matthew@bitovi.com> wrote:
> 
> I recently saw this talk (https://www.youtube.com/watch?time_continue=8041&v=Um5HHZkXGg4) given by Chrome engineers on experimenting with disabling H2 PUSH, where they concluded that sites currently do not see a benefit from using PUSH. At the end of the presentation they mentioned the idea of  disabling PUSH for everyone. I wanted to reach out to this list to present a case in favor of PUSH.
> 
> 
> The talk focuses on the use of PUSH as a mechanism to speed up initial load time. There has been much written about this in the past, and I fully believe the conclusion that it is difficult to make work for that use case.
> 
> 
> First I'd like to point out the obvious; PUSH is still a very new technology and few sites are even attempting to use it. So it shouldn't be any surprise that few are using it successfully. It is competing against techniques that have been refined for over two decades; CDNs, caching strategies, Preload, resource prioritization / deferring, etc. It will take time to figure out where PUSH fits in with these strategies. The results suggest that it is not a replacement for them.
> 
> 
> With that being said, there are use-cases for PUSH aside from pushing cacheable static assets. PUSH is of great value for non-cacheable dynamic data. I'd like to present a couple of use-cases to illustrate the point.
> 
> 
> With modern web pages preferring to render content in the client, rather use server rendering, load performance is better measured by "time to interactive" (https://developers.google.com/web/tools/lighthouse/audits/time-to-interactive). This goes beyond the time it takes to load HTML, CSS, and JavaScript as this talk focuses on. Pages also now need to make additional requests for data. This is where PUSH can help.
> 
> 
> As a simple example consider a chat application. The app might elect to use a technique such as the app shell model (https://developers.google.com/web/fundamentals/architecture/app-shell) where only the skeleton of the application is sent to the browser, which then makes another request for chat messages once JavaScript is ran. This technique works particular well for applications with offline support. The application is not interactive until those messages are loaded. PUSH can be helpful here; the server can create a stream of messages and PUSH them along with the initial HTML. By the time the JavaScript has ran and connects to that PUSH stream it can immediately start displaying messages. And with new streaming APIs in the browser, it can stay connected to this stream for the lifetime of the application, receiving new messages as they come. This prevents needing to use WebSockets and the complexity they bring.
> 
> 
> In a slightly more complex example, my company has been envisioning an alternative to HTML streaming that utilizes H2 PUSH. When I say HTML streaming I am talking about the technique of sending HTML in chunks, as database results come in, until the fully page is sent out. One problem with HTML streaming is that the top of the page isn't always ready before parts further down.
> 
> 
> As an example, consider an ecommerce site that shows a shopping cart, with a count, in the page's header, and then lists products, such as shoes, in the main part of the page. The database query for the list of shoes is likely to be faster than the query for the cart count. It is likely a simpler query with proper indices, and if streaming is supported by the database it can be loaded even quicker. Whereas the cart might require a more complex query with multiple joins. With HTML streaming the slowest database request blocks rendering anything below it.
> 
> 
> A newer idea we've been pursuing is to send an app shell (like discussed above) and then further updates occur as mutation instructions through an H2 PUSH stream. The client connects to this stream and applies the mutations via DOM apis. In this case we can start displaying the product listing for shoes while the user's cart data is still being loaded.
> 
> 
> H2 PUSH is critical for doing this. Without the ability to push this mutation stream, it doesn't have as much of an advantage over using HTML streaming. I wrote about research we did into this idea last here. It includes non-scientific data, but it's worth giving some consideration. https://www.bitovi.com/blog/utilizing-http2-push-in-a-single-page-application . You can see a demo of it working here: https://www.youtube.com/watch?v=3smwqZHJ68I
> 
> 
> In conclusion, please don't kill PUSH! Give web developers more time to come up with creative uses for it aside from the asset loading case.
>

Received on Monday, 3 September 2018 07:21:41 UTC