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

Page speed optimization - fast assets #132

Closed
MadLittleMods opened this issue Nov 10, 2022 · 1 comment
Closed

Page speed optimization - fast assets #132

MadLittleMods opened this issue Nov 10, 2022 · 1 comment
Labels
A-performance What is slow, what made it faster and more efficient? T-Enhancement New feature or request

Comments

@MadLittleMods
Copy link
Contributor

MadLittleMods commented Nov 10, 2022

The page takes long enough load, we shouldn't need to additionally slow it down with 2 additional seconds of bootstrapping once it reaches the client.

Potential solutions

1. Use a CDN to serve the assets fast

Update: The production deployment will use Cloudflare (should be good)

It shouldn't take 2 seconds to serve 991kb JavaScript file (entry-client-hydrogen.es.js) for example.

We could speed up response times by using a CDN instead.

2. Smaller assets

Update: Tracking separately as #176

Almost 1 MB JavaScript file seems a little bigger than necessary.

One thing we can do is split Hydrogen out to its own bundle file so we can share it between the room directory and room archive view.

3. <Link rel="preload"> preload hints

Update: Added Link preload headers which are equivalent in #171 #185, and #187

Use <Link rel="preload" ...> for the CSS, JavaScript, and fonts that we always have to load. This should also help the essential assets beat all of the image avatars that load before and block them as well currently.

Docs: https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types/preload

<head>
  <meta charset="utf-8" />
  <title>JS and CSS preload example</title>

  <link rel="preload" href="style.css" as="style" />
  <link rel="preload" href="main.js" as="script" />

  <link rel="stylesheet" href="style.css" />
</head>

<body>
  <h1>bouncing balls</h1>
  <canvas></canvas>

  <script src="main.js" defer></script>
</body>

4. Better preload hints, HTTP 103

Update: See #32 -> #171

We can make the preload hints happen even sooner before the page even gets a HTML response. I think this could be a major win since it takes a while for us to assemble a response in the first place.

@MadLittleMods MadLittleMods added T-Enhancement New feature or request A-performance What is slow, what made it faster and more efficient? labels Nov 10, 2022
MadLittleMods added a commit that referenced this issue Apr 19, 2023
Because it takes us at best several seconds to request information from a homeserver and then server-side render the page, the browser has to wait for the response before it can even try loading the necessary assets. With this change that facilitates early hints, the browser can preload all of the assets necessary before we are done generating the response and will be ready to go by the time we're all done on the server.

Fix #32

Part of #132

See https://developers.cloudflare.com/cache/about/early-hints/ for information on enabling in Cloudflare
MadLittleMods added a commit that referenced this issue Apr 26, 2023
Follow-up to #171 and #175 where they broke because we went from scripts to modules.

Part of #132

Before this PR, we were seeing these warning in the Chrome devtools console:

```
A preload for 'foo' is found, but is not used because the request credentials mode does not match. Consider taking a look at crossorigin attribute.
```

This is caused by a credentials mode mismatch between the `<script type="module">` tag and the `Link` header. A `<script type="module">` with no `crossorigin` attribute indicates a credentials mode of `omit` and a naive `Link: </foo-url>; rel=preload; as=script;` has a  default credentials mode of `same-origin`, hence the mismatch and warning we're seeing.

We could set the credentials mode to match using `Link: </foo-url>; rel=preload; as=script; omit` but there is an even better option! We can use the dedicated `Link: </foo-url>; rel=modulepreload` link type which not only downloads and puts the the file in the cache like a normal preload but the browser also knows it's a JavaScript module now and can parse/compile it so it's ready to go.

---

Future consideration: Adding `nopush` to preload link headers. Many servers initiate an HTTP/2 Server Push when they encounter a preload link in HTTP header form otherwise. Do we want/care about that (or maybe we don't)? (mentioned in https://medium.com/reloading/preload-prefetch-and-priorities-in-chrome-776165961bbf#6f54)

---

References for preload `Link` headers:

  - https://medium.com/reloading/preload-prefetch-and-priorities-in-chrome-776165961bbf#6f54
  - https://html.spec.whatwg.org/multipage/links.html#link-type-preload
  - https://www.smashingmagazine.com/2016/02/preload-what-is-it-good-for/#headers
 - https://developer.chrome.com/blog/modulepreload/#ok-so-why-doesnt-link-relpreload-work-for-modules
MadLittleMods added a commit that referenced this issue Apr 26, 2023
@MadLittleMods
Copy link
Contributor Author

Closing as we have the preload part implemented now, HTTP 103 early hints will come with a Cloudflare on top of those Link preload headers, and better smaller bundles is tracked by #176

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-performance What is slow, what made it faster and more efficient? T-Enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant