Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JS is downloaded twice #500

Open
MattiaVerticchio opened this issue Nov 27, 2024 · 1 comment
Open

JS is downloaded twice #500

MattiaVerticchio opened this issue Nov 27, 2024 · 1 comment

Comments

@MattiaVerticchio
Copy link

Problem

The /elm.hash.js file is being downloaded twice during page load, which is unnecessary and impacts performance.
This issue is visible on the elm-pages documentation website itself.

Reproduction

  1. Go to https://elm-pages.com
  2. Inspect the network tab in browser developer tools and Ctrl+Shift+R
  3. Observe the /elm.53193920.js file being downloaded twice

Expected Behavior

The Elm JavaScript file should be downloaded only once.

Proposed Solution

In the HTML (of the docs website), there are duplicate references to the same Elm JavaScript file:

<link rel="modulepreload" crossorigin href="/elm.53193920.js">
<script defer="" src="/elm.53193920.js" type="text/javascript"></script>

I propose to replace modulepreload with preload and sync the crossorigin attribute for both the tags:

Solution A

<link rel="preload" as="script" href="/elm.53193920.js">
<script defer src="/elm.53193920.js" type="text/javascript"></script>

Solution B

<link rel="preload" as="script" href="/elm.53193920.js" crossorigin>
<script defer src="/elm.53193920.js" type="text/javascript" crossorigin></script>

Why?

I hope this is helpful, I could also make a PR with the solution you prefer, if that’s ok 😁

@dillonkearns
Copy link
Owner

Oh I see, thank you for the detailed issue and references that is very helpful!

Elm should be compiled to a module and handled by Vite

There are a few reasons why I don't do this. It's a little bit complicated to explain concisely, but a couple of key reasons:

  • There are some codemods applied to the code to allow for things like turning the Html type into a String (requires hacking the compiled code)
  • The Lamdera compiler output doesn't play nicely with some of those Elm ESM tools
  • The dev server has some optimizations around compiling the Elm code, so it's easier to run that separately
  • It runs terser options and some other things to optimize the Elm output, which I found difficult to get working correctly with Elm compiled to ESM
  • It shields the user from mistakenly messing something up with the Elm code bundling since it isn't effected by the user's Vite config

So all that to say, let's stick with the Elm code being compiled as is, and just change the <head> tags to be configured correctly based on that.

I would love a PR if you are up for it! Happy to discuss more details here or over Slack or Discord as well.

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants