What is the optimum http/2 push links for mobile sites?

Question

I have LEMP stack WordPress sites (responsive theme) and use mod_pagespeed with Cloudflare. I have enabled mod_pagespeed filter hint_preload_subresources. I can see that there are over 20 http/2 pushes URL's.

13 URL are added by myself in nginx config file and rest of added by mod_pagespeed.

I want to know that, are there any optimum number of http/2 push for mobile sites header?

Link    </wp-content/themes/fonts/economica/economica-bold.woff2>; rel=preload; as=font; type=font/woff2; crossorigin
    Link    </wp-content/themes/fonts/lora/lora-regular.woff2>; rel=preload; as=font; type=font/woff2; crossorigin
    Link    </wp-content/themes/fonts/economica/economica-regular.woff2>; rel=preload; as=font; type=font/woff2; crossorigin
    Link    </wp-content/themes/fonts/lora/lora-regularitalic.woff2>; rel=preload; as=font; type=font/woff2; crossorigin
    Link    </wp-content/themes/fonts/lora/lora-bold.woff2>; rel=preload; as=font; type=font/woff2; crossorigin
    Link    </wp-includes/js/jquery/jquery.js>; rel=preload; as=script; crossorigin
    Link    <https://pagead2.googlesyndication.com/>; rel=preconnect; crossorigin
    Link    <https://fonts.gstatic.com>; rel=preconnect; crossorigin
    Link    <https://cdn.onesignal.com>; rel=preconnect; crossorigin
    Link    <https://tpc.googlesyndication.com>; rel=preconnect; crossorigin
    Link    <https://www.googletagservices.com>; rel=preconnect; crossorigin
    Link    <https://securepubads.g.doubleclick.net>; rel=preconnect; crossorigin
    Link    <https://fonts.googleapis.com>; rel=preconnect; crossorigin
    X-Page-Speed    Powered By ngx_pagespeed
    Link    </dalgona-coffee-recipe/_,Mjo.HNzDPsM1gt.js.pagespeed.jm.e1WOIS1Zb_.js>; rel=preload; as=script; nopush
    Link    </wp-content/plugins/jquery-updater/js/jquery-3.5.1.min.js.pagespeed.jm.A8biqtTJrt.js>; rel=preload; as=script; nopush
    Link    </wp-content/plugins/jquery-updater/js/jquery-migrate-3.3.0.min.js.pagespeed.jm.KuaEtw4rAV.js>; rel=preload; as=script; nopush
    Link    </wp-content/themes/focus-pro/js/responsive-menu.js.pagespeed.jm.nP4yb5h4IW.js>; rel=preload; as=script; nopush
    Link    </wp-content/plugins/ewww-image-optimizer/includes/lazysizes-pre.js.pagespeed.jm.rCxbQtytJ3.js>; rel=preload; as=script; nopush
    Link    </dalgona-coffee-recipe/_.pagespeed.jo.M8QchvC_7_.js>; rel=preload; as=script; nopush
    Link    </dalgona-coffee-recipe/_,Mjo.WekTyeyJeu.js.pagespeed.jm.OxNrKbQqy7.js>; rel=preload; as=script; nopush
    Link    </wp-content/plugins/content-views-query-and-display-post-page/public/assets/js/cv.js.pagespeed.jm.UGPwgHHoMK.js>; rel=preload; as=script; nopush
    Link    </wp-content/plugins/quicklink/quicklink.min.js.pagespeed.ce.XAGoxleb0H.js>; rel=preload; as=script; nopush
    Link    </wp-content/plugins/wp-recipe-maker/dist/public-modern.js.pagespeed.ce.SOOy8iGsGt.js>; rel=preload; as=script; nopush
    Link    </wp-content/plugins/simple-lightbox/themes/baseline/js/prod/client.js.pagespeed.ce.3VunenzJ26.js>; rel=preload; as=script; nopush
    Link    </wp-content/plugins/simple-lightbox/themes/default/js/prod/client.js.pagespeed.ce.-9aYp48Jjk.js>; rel=preload; as=script; nopush
    Link    </wp-content/plugins/simple-lightbox/template-tags/item/js/prod/tag.item.js.pagespeed.ce.HKRnB5RaiU.js>; rel=preload; as=script; nopush
    Link    </wp-content/plugins/simple-lightbox/template-tags/ui/js/prod/tag.ui.js.pagespeed.ce.82hZO-SaY-.js>; rel=preload; as=script; nopush
    Link    </wp-content/plugins/simple-lightbox/content-handlers/image/js/prod/handler.image.js.pagespeed.ce.m7L4ntgvbt.js>; rel=preload; as=script; nopush

Answer 1

A very subjective question.

There’s two potential problems where pushing can be the wrong thing to do:

1. Pushing resources when there are better things to use the network for. So overly prioritising less important assets by pushing them.
2. Pushing when the client already has the resources being pushed. So a wasted push.

Let’s start with the first. Browsers are very, very good about knowing what order to request things in. Shoving everything down the pipe with no thought of that throws all that out the window. Of course a site owner can know better than a browser (which is after all generic and has to do the best for most sites) but doing this is very hard.

For example is see you are pushing your fonts first (or at least those are defined first in the config). Are those the most critical things on your page? Are all of them important? Or by pushing them are you holding up CSS without which nothing can be painted to the screen (not even the text that the font is being used for)? I don’t know your site well enough to know the answer to that but suspect pushing as much as possible is doing more harm than good.

Google published a paper advising to “push just enough to fill idle network time and no more.” The problem is that’s a very hard thing to get right.

More critical requests can come in - for example user cancels the current page and then navigates to the new page. If you’re still pushing everything, then they have to wait for all of that to arrive before they get what they asked for. Even if the server could reprioritised (and most servers are bad at reprioritising!) the problem is the payloads may have long left the server and be clogged up in the network so reprioritising is only of limited use in this case.

The second issue with blindly pushing is that it doesn’t take into account what’s in the browsers cache? So back to your example with your fonts that you are pushing (not to pick on them - it’s just an example and what I’m about to say applies to the other things being pushed too). Maybe pushing them is the right thing to do so the page loads nice and fast. Now you go to a second page on the site and you push the fonts again - even though the browser already has them in the cache! You are now wasting bandwidth which is both more expensive for the user in terms of wasted cost (maybe not on broadband but few enough have an unlimited plan on mobile!) but also in the fact the new content is queued behind this pointless push. It’s possible to avoid this with a cookie based approach but that requires extra setup, or some browsers (like Apache) track what resources have already been pushed on that connection to avoid this, but that only works if same connection is used and you don’t come back later that day.

In short the optimum amount to push with HTTP/2 is often a lot less than you think. And some would argue “push nothing” is the right answer. Google have repeatedly voiced the opinion that HTTP/2 Push has not proven as a net positive and stated they could drop support of it from Chrome (including very recently).

Resource hints and taking that further with the (the as yet very poorly supported) 103 Early Hints is seen as far less risky (as they are hints so the browser remains in control) and give almost the same performance benefits.