Open elucidsoft opened 9 months ago
Does setting embedded: true
(https://kit.svelte.dev/docs/configuration#embedded) help here, which would make the application trust what the server thinks is the URL, rather than what the browser thinks is the URL?
I will test that and let you know.
This change made no difference and here is why, it's not about trust. It's about how the SXG is determining which resources to cache and which to dynamically load. So the js files are still getting a 404 from app and entry. My suggestion for immediate recommendation is a huge warning be posted about this because this is catastrophic if you enable SXG your app will remain broken for a very long period of time, until the SXG caches drop your site. And based on the documentation, they use the cache header which is set to 1 year. So I really hope this issue doesn't persist for an entire year, or I'll be forced to remove my URLs entirely and rename them slightly to get them relisted on Google Search which would definitely not be ideal.
Actually, you may need to test this yourself as I disabled SXG in Cloudflare and it looks like new code changes aren't being updated on the exchanges anymore. So I would suggest recreating this scenario, my site needs to get back to normal ASAP so I can't play around with these SXG things anymore.
@elucidsoft Early hints is another place where I have traced it too that will cause issues with CloudFlare and this strange error. It looks like Cloudflare caches this on the edge and so if the browser tries to preload these files it will fail.
Notice the headers in the HTTP response
Describe the bug
Google Signed Exchanges (SXG) allow Google search to prefetch your content while preserving the users privacy, and also enhancing your websites performance. It can lower LCP significantly for example.
The way I came across this issue is that Cloudflare has a feature that is off by default that will enable SXG. This means your site is served from https://.webpkgcache.com/doc/-/s//
For example, if a user clicks on a SvelteKit app from Google Search results that is served from an SXG, the initiator chain would look like the following for a js file:
As you can see the originator is the SXG. This breaks the app, as it will get a 404 not found for the .js file, because the
app.<hash>.js
andentry.<hash>.js
is referencing a path that no longer exists because its expecting origin to contain these files since these files were referenced originally. I do not know why the SXG is caching app, and entry locally and not the others but if you read the docs on Signed Exchanges it says that they will pre-fetch certain files such as HTML, Javscript, CSS, etc. in a privacy-preserving manner.https://developers.google.com/search/docs/appearance/signed-exchange
Reproduction
This is not too difficult but can be a bit time consuming. You will need to create SvelteKit app with several pages. These pages need to load several components into them, as well as CSS, etc.
Then upload this to Cloudflare Pages or some other hosting provider as long as you use Cloudflare Proxying. Enable Cloudflare Signed Exchanges. Submit your site to Google Search console and let it pickup your site. Then on Google Search Results click on items and observe the initiator chain. It does NOT serve ALL your search results from SXG, only a subset and the link on hover of the search result can be misleading as it sometimes lists the exchange url and sometimes not. The best way to see is to look at the Requestor initiator chain in Google Chrome DevTools for the item, in the network tab, under initiator for that specific item.
Logs
No response
System Info
Severity
serious, but I can work around it
Additional Information
I am not sure how this can be fixed, but this does work perfectly fine using NextJs as I have several sites running with SXG enabled with no issues.
Also related to #9089