You can still do initial page speed optimization using dirty tricks. Some of these were possible even before HTTP/2 Push existed. If you already have fancy mi

You can still do initial page speed optimization using dirty tricks. Some of these were possible even before HTTP/2 Push existed. If you already have fancy middleware to predict the best assets to push for different users, perhaps you can extend the middleware to inject the dirty tricks as well. - data: URLs inlined into the initial page HTML - compression to remove the entropy of base64 encoding - ordinary inlining, e.g. for JavaScript, CSS and (less likely) HTML fragments - Cache and ServiceWorker to allow future pages to use the inlined assets without fetching them a second time Combine the above with heuristics like you were using for HTTP/2 Push to decide what to inline for each user. So a user with an If-None-Match Etag or a cookie has probably seen the page before, and a user with neither probably has not. As others have pointed out, <link> preloads are also available. Although those don't kick in until the first data from the initial page has been received, if there is enough page data, one extra RTT needn't matter for some resources, especially JavaScript that is only needed once the user starts interacting with the page, items far below the fold, and other page resources if it's a single-page application.