Re: In defense of PUSH

Thanks for sharing the link.

I have to note that the presentation from Akamai and the note from the
Google's engineer refer to two slightly different uses of Push. Only a
bunch of accelerators can do what Akamai presented (my company sells
another one, specifically tailored for e-commerce),  so I expect that
using Push for resources while the web application "thinks" does not even
register in the statistics presented by Google. Also, I know from
experience that without a data analysis pipeline that takes into account a
bunch of variables, push  makes things worse more often than not.

Nonetheless, as it was  made clear in the presentation, there are clean,
statistically sound cases when HTTP/2 push improves loading times. So, I
agree with Matthew that push should be given a fighting chance, and it
should be given enough time to mature into a widely deployed, mature
technology.

I just hope that Chrome* don't* follow through on any attempts to nix it.





On Fri, Aug 31, 2018 at 8: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.
>
>


-- 
Alcides Viamontes E.
ShimmerCat AB, CTO
(+46) 722294542