Solve SvelteKit Limitations for performance and i18n #12001
JaviKeziah
started this conversation in
Ideas
Replies: 2 comments 1 reply
-
cc: @benmccann has done a lot of investigation on SvelteKit's performance. I think he'll have some good ideas to share. |
Beta Was this translation helpful? Give feedback.
0 replies
-
Do you have a link showing what exactly you're proposing? I don't have experience with those frameworks |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I've been using SvelteKit for several websites and have encountered some limitations that seem improvable. These limitations might be among the reasons why I'm not aware of any large companies using it in production.
All of these concerns are related to the app.html file. The inability to control your own head section results in performance issues, reduced control over your application, and difficulty implementing simple things.
For example:
There is limited control over the order of the elements, which is important for performance.
When attempting to preload an image or add a
preconnect
to load images from a CDN, I've observed delays sometimes exceeding 0.5 seconds more than usual.It's not easy to place the Title at the beginning of the head where it is recommended (you can do it for every route with
transformPageChunk
, but it becomes tedious as your app scales).For internationalization (i18n), serving static pages without using a library or modifying the hooks seems unfeasible, as changing the %lang% attribute in
hooks.server.ts
is necessary.When using client-side routing, it's not a good idea to add a component inside svelte:head because it re-renders every time you navigate to the same page.
Controlling the body tag for each specific route is also more difficult, as it is not scoped.
I believe these and other issues could be resolved by allowing the addition of Layouts as components with all the head elements replacing app.html file, similar to what is done in Astro or Next. This also would enable us to place
%sveltekit.head%
and%sveltekit.body%
wherever needed for each route, facilitating easy implementation of internationalization without modifyinghooks.server.ts
and allowing a choice between static and dynamic routes with zero configuration.Am I the only one thinking this @Rich-Harris?
I may be mistaken about some of these points, so if anyone knows an efficient way to address these challenges, I would love to hear it.
Beta Was this translation helpful? Give feedback.
All reactions