docs: further clarify and reinforce the performance impacts of single page apps (SPAs) #11637
Conversation
|
Co-authored-by: Willow (GHOST) <ghostdevbusiness@gmail.com>
There was a problem hiding this comment.
I gotta push back on the language of these changes and some of these changes in general - it sounds like we're on a crusade against SPA mode now. This creates FUD ("omg SPA mode always bad", which isn't true because it depends on your site) and may turn people off from using SvelteKit ("ok so they hate SPA I'll look for another framework that supports it better") which helps neither web vitals nor us.
I think there are other avenues to explore:
- some kind of SvelteKit dev tools which somehow analyzes your page and gives you some tips what you can improve, where this plays a part
- partial prerendering which will improve perceived performance and probably web vitals
- understanding why people opt for SPA mode in the first place and solve the roadblocks towards leaving SSR enabled
| @@ -46,6 +46,6 @@ In SvelteKit, you can do static site generation by using [`adapter-static`](adap | |||
|
|
|||
| ## SSR | |||
|
|
|||
| Server-side rendering (SSR) is the generation of the page contents on the server. SSR is generally preferred for SEO. While some search engines can index content that is dynamically generated on the client-side it may take longer even in these cases. It also tends to improve perceived performance and makes your app accessible to users if JavaScript fails or is disabled (which happens [more often than you probably think](https://kryogenix.org/code/browser/everyonehasjs.html)). | |||
| Server-side rendering (SSR) is the generation of the page contents on the server. Returning the page contents from the server via SSR (including with prerendering) is highly preferred for performance and SEO. It drastically improves performance by avoiding the introduction of an extra round trip necessary in a SPA and makes your app accessible to users if JavaScript fails or is disabled (which happens [more often than you probably think](https://kryogenix.org/code/browser/everyonehasjs.html)). While some search engines can index content that is dynamically generated on the client-side it is likely to take longer even in these cases. | |||
There was a problem hiding this comment.
This isn't really true - it's more about the perceived performance. The HTML is already there, but you still have the second roundtrip of fetching the JS which hydrates your stuff and then it's interactive. If your page doesn't work without JS it might feel just as bad.
There was a problem hiding this comment.
'roundtrip' refers to the data that is inlined into the page (whether in the form of serialised server data or inlined event.fetch responses)
There was a problem hiding this comment.
And if your site is content to be read, it's much more than perceived performance - it's actual performance
Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>
Co-authored-by: Tee Ming <chewteeming01@gmail.com>
Co-authored-by: Tee Ming <chewteeming01@gmail.com>
Co-authored-by: Tee Ming <chewteeming01@gmail.com>
Co-authored-by: Tee Ming <chewteeming01@gmail.com>
Co-authored-by: Tee Ming <chewteeming01@gmail.com>
Co-authored-by: Tee Ming <chewteeming01@gmail.com>
Co-authored-by: Tee Ming <chewteeming01@gmail.com>
Co-authored-by: Tee Ming <chewteeming01@gmail.com>
A huge portion of SvelteKit apps in the wild that are failing core web vitals are single page apps. The percentage of SvelteKit apps which pass/fail are tracked on cwvtech.report leveraging data from HTTP Archive. Some folks at Google were able to supply me with a random sample of SvelteKit sites from this dataset. While investigating the failing sites, I saw that the most common cause of failure was extra round trips due to deployment as a SPA.