However, they are called every time due to the preload hint, unlike Server Push that keeps a diary and doesn’t push them twice until the next session.
If I just set the link header in .htaccess as Header add Link <"/fonts/poppins.woff2>; rel=preload", as per the Apache documentation, the fonts are pushed, but the problem is the fonts are still loaded normally as well.
Adding the full <“font/poppins.woff2>; rel=preload; as=font/woff2; crossorigin” only preloads the fonts rather than pushes them.
It’s not that I need to save any speed, but rather don’t want to waste people’s resources.
But are you referring to CF HTTP/2 Server push requirement to just use rel=preload ? In that case yes HTTP/2 server push will push the asset everytime. The reason is HTTP/2 server push is not browser cache aware and AFAIK Cloudflare’s HTTP/2 server push is not browser cache aware either.
Usually outside of Cloudflare HTTP/2 on origin web servers such as Apache or Nginx their HTTP/2 implementation allows for configuring browser cache aware HTTP/2 server push
It’s balance to be made, Service Worker pre-caching will only show up as extra requests for 1st visits which your standard webpagetest 1st visit tests would show. To properly evaluate it’s effectiveness you need to test for return/repeat visits as that is where Service Worker pre-caching is most effective as unchanged assets are located in visitor’s browser cache and doesn’t make a network request.
Basically, if you want to save visitor’s data bandwidth DO NOT use Cloudflare’s HTTP/2 server push as it isn’t browser cache aware so will push the asset to return/repeat visitors even if it’s already in the visitor’s browser cache.
That is expected behaviour for HTTP/2 server push as it isn’t browser cache aware as outlined in my above reply posts
that must be unique to Cloudflare and i haven’t tried that
Not sure you’d have to contact CF tech support to get hold of someone who knows it’s specifics
Not really, HTTP/2 Server push should ideally be browser cache aware but it isn’t technically out of the box without the aid of the web server or some mechanism. Whether CF has such mechanism for CF set browser cache TTL headers is unknown. There is no problem with preload being called everytime as it is browser cache aware unlike HTTP/2 Server push
With how HTTP/2 Server push in generally is done, it’s easier just to use preload. The difference in perceived render time for page load isn’t much.
To be precice you said: “But are you referring to CF HTTP/2 Server push requirement to just use rel=preload ? In that case yes HTTP/2 server push will push the asset everytime. The reason is HTTP/2 server push is not browser cache aware and AFAIK Cloudflare’s HTTP/2 server push is not browser cache aware either.”
So I’m saying, no it doesn’t push the asset every time. It’s pushing based on the Push Diary settings or equivalent.
You are correct with regard to preload being browser cache aware. After turning my Workbox service worker off, it doesn’t call for the fonts on repeat view.
Of course, now I know that, preload is the best option for saving data. Although using the push diary effectively can mittigate the server push wasted data problem somewhat.
This was due to initially trying to increase security be removing the asterix wildcard and adding my explicit origin. Everything seemed to be fine apart from when using the service worker.
Currently still using the Access-Control-Allow-Origin header, but without Vary Origin has solved the problem and now the service worker isn’t trying to fetch the fonts unnecessarily.
Apparently Apache sets the Vary header automatically if using Mod_Deflate which most people will be for compression.
Regarding the original question. Still no luck. It seems to me the problem is simple. Pushes are only done from the origin, so as soon as you add crossorigin (even from the same origin) the system obviously thinks a push isn’t posssible.
No matter what you do it won’t accept crossorigin or so it seems.
If anything changes in the future, would be interested to know. Cheers.