On this website, I normally only write about solutions I’ve come up with to problems I’ve encountered (pertaining to web development). I recognize that’s not entirely authentic because I can’t solve every problem I come across. Sometimes, I’ll come across an issue where the solution isn’t immediately clear to me. Sometimes, it festers for long enough that I’m driven to take drastic action. Sometimes, I’m forced to write an entire post about it. This is post about one of those festering, unsolved problems.
It started while working on the Svelte Work:Rest Timer component I wrote about a few months ago. You see, the timer was intended to be a static Single Page Application (SPA)/Progressive Web Application (PWA) without a back-end server component. That is, once served to the client and installed via the browser PWA installation process, it would be usable on mobile devices whether or not they had an internet connection. I thought surely, this will be easy enough for me to tackle since I’ve already built something similar with helth app. The only major difference being that this timer application would utilize the SvelteKit static site adapter instead of the Node.js adapter.
The Problem
During development, everything ran smoothly. It wasn’t until deployment to production that I noticed issues.
SvelteKit uses Vite to deliver that buttery-smooth development experience, and Vite uses esbuild to bundle an application during development. However, when building the production version of an application, Vite uses Rollup to bundle the app. I believe this discrepancy; coupled with my obvious lack of understanding of the underlying technologies behind SvelteKit (Vite, esbuild, and Rollup), is why I ran into any issues in the first place.
When I attempted to deploy my static files to a static host, I noticed the app was missing several key features, like some of the actual code that made the logic in the application run and the CSS included in each component. After checking the network requests in my developer console, I noticed the development version was making 3-5 more requests than my production build. Why?
Troubleshooting
Since I had built the application to be static, it was safe to prerender the HTML on the one and only page. Any two users should see identical HTML, CSS, and JS on the site when they open it for the first time. To accomplish this, I simply needed to add the following code to the file src/routes/+layout.js:
export const prerender = true;
export const ssr = false;I figured since there wouldn’t be a back-end component of the application, it would be fine to disable Server-Side Rendering (SSR) while I was at it. My thought was that this would force SvelteKit to prerender and it would skip generating any server-side code for that route.
I discovered that if I removed the line that disabled SSR, I would get a different index.html located at .svelte-kit/output/prerendered/pages/index.html.
Right: index.html included in “.sveltekit-output/prerendered/pages/” when option that disables SSR is removed
This file contained links to resources that were not being loaded in my production version of the app. This file was also not included in my production build folder (build/). I don’t fully understand why disabling SSR and enabling prerendering generates a different version of the index.html file. I also don’t understand why the version of index.html I needed wasn’t included in my build directory. For now, I’ve simply overwritten the file build/index.html with the file .svelte-kit/output/prerendered/pages/index.html and the application works as expected.
If you or someone you know has some insight as to why this is, please drop a comment below, reach out to me via my contact form, or message me on various social media platforms. I would love to understand what I assume I’m doing wrong.
