Inspiration: McMaster-Carr #717

EmilStenstrom · 2024-10-19T21:26:45Z

EmilStenstrom
Oct 19, 2024
Maintainer

https://youtu.be/-Ln-8QM8KhQ?feature=shared

Really inspiring how much speed they can cram into a rather old Asp.Net site. But thinking of it, we can do pretty much all of the tricks! Should we even make them default?!

JuroOravec · 2024-12-08T12:01:36Z

JuroOravec
Dec 8, 2024
Collaborator

Finally went over the video again. Lots of grate ideas.

Topics in the video:

Prefetch HTML (0:55)
- Thoughts:
  - Challenge for us is that we don't know which URLs our users (other devs) may want to preload.
    - As example, in theory we could scan the rendered HTML for all links, and prefetch them all. But if a page would have hundreds of links, then that doesn't sound optimal.
  - I think what Wikipedia does (and what McMaster-Carr does in the video) is to prefetch the URL on hover
  - We could add a JS script that would add a <link rel="prefetch"> tag when hovering over <a href="..."> tags.
    - IMO this would make sense to define as a standalone plugin, which would define a single JS file that adds this behaviour.
- Read more:
  - https://developer.mozilla.org/en-US/docs/Glossary/Prefetch
  - https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel/prefetch
CDN caching (2:03)
- This is outside of scope of django-components
Service worker caching (2:36)
- Thoughts:
  - I came across this articles ("Offline cookbook"). Based on that, it seems it would be possible with django-components, but it also seems incredibly complex.
  - The challenge is that we don't know which pages should be cached and which should not. (E.g. we don't want to cache transactional pages)
  - There was another article in the series talking about having same or different expiration policies for service worker and server caching. If we wanted to allow to manage the those policies independently, it feels complex enough that it would deserve a separate project and someone to own it.
  - BUT, if the service worker cache could be configured to behave based on cache HTTP headers, then all the caching would be configured at the point where user creates Django's HttpResponse to send back.
  - IMO this would again make sense as a standalone plugin, which would define a two JS files - one to register the service worker, and one for the service worker itself.
- Read more:
  - https://web.dev/articles/offline-cookbook#serving-suggestions
Asset preloading (3:29)
- Thoughts:
  - Lots of different cases, but sounds feasible
  - Cases:
    - JS rendered by django-components (djc)
      - Easy. We have knowledge of those files, so we could just add preload tag to where we render the CSS.
    - CSS rendered by djc
      - It's already rendered in the <head>, so I think not much more to do here.
    - Other JS / CSS
      - We'd have to parse the HTML to find all JS / CSS links and declare them with preload tag if they are not defined in the <head>.
    - Assets (images, fonts, ...) in HTML
      - We'd parse HTML to find all images and fonts and create preload tags.
    - Assets in CSS
      - For this we'd first have to get all CSS stylesheets from the HTML. And then in each CSS file search for url(...) definitions.
        
        This would add a level of complexity, as we'd probably want to cache these so that we don't have to parse the CSS files for url(...) on every request.
    - DNS prefetch
      - Given all URLs for the assets above, we could extract the domain names and generate these prefetch tags.
  - Since this involves mostly post-processing the HTML, then IMO again it would make sense as a plugin.
- Read more:
  - https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel/preload
Critical CSS (5:33)
- We kinda do this already, in a sense that the CSS defined for individual components (Component.css) will be inlined into the HTML into <head>. This does not apply to CSS from Component.Media.css, which is only linked as <link href="...">.
- For more fine-tuned definition of what the "Critical CSS" is, I think this already has to be decided by the users.
Fixed size images (7:36)
- I think this has to be done by users. Because IMO it'd make sense only if the image did not have any styling applied that'd define the size. But if image's size was defined in CSS, then we'd need to somehow know which CSS rule applies to the image. And that's what browsers do.
Image sprites (8:32)
- Very cool
- I'd leave this one again up to individual users / projects. In theory we could take all images mentioned in the HTML, put them in a single image, save that image temporarily, and serve that. But we wouldn't be able to tell which images are frequently used, and it could lead to just generating loads of files.
Loading only needed JS (9:04)
- As of v0.110, we already do this :)

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Inspiration: McMaster-Carr #717

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 1 comment

{{title}}

Select a reply

Inspiration: McMaster-Carr #717

EmilStenstrom Oct 19, 2024 Maintainer

Replies: 1 comment

JuroOravec Dec 8, 2024 Collaborator

EmilStenstrom
Oct 19, 2024
Maintainer

JuroOravec
Dec 8, 2024
Collaborator