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.

Sign up for GitHub

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

Jump to bottom

Improving time to load. Inspiration from McMaster-Carr #835

Open
3 of 12 tasks
JuroOravec opened this issue Dec 8, 2024 Discussed in #717 · 0 comments
Open
3 of 12 tasks

Improving time to load. Inspiration from McMaster-Carr #835

JuroOravec opened this issue Dec 8, 2024 Discussed in #717 · 0 comments

Comments

@JuroOravec
Copy link
Collaborator

This is based on the discussion in #717.

I think it would be great to eventually implement these, so I'm making an issue for this, so we can track progress for this.

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

Summary

  • 1. Prefetch URL on hover over link

❌ 2. CDN caching

  • 3. Service worker caching

    • Check if service worker caching policy respects Cache-Control HTTP header

  • 4. Asset preloading

    • JS rendered by django-components (djc)
    • CSS rendered by djc
    • Other JS / CSS
    • Assets (images, fonts, ...) in HTML
    • Assets in CSS
    • DNS prefetch

  • 5. Critical CSS

❌ 6. Fixed size images

❌ 7. Image sprites

  • 8. Loading only needed JS

My analysis

  1. 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:

  2. CDN caching (2:03)

    • This is outside of scope of django-components

  3. 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:

  4. 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:

  5. 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.

  6. 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.

  7. 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.

  8. Loading only needed JS (9:04)

    • As of v0.110, we already do this :)
@JuroOravec JuroOravec moved this to Backlog in Roadmap Dec 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
Roadmap
Status: Backlog
Milestone
No milestone
Development

No branches or pull requests
1 participant
@JuroOravec