Better document, how to use preload

[PetrDlouhy]

The usage of preload from documentation is not working on real websites.
The result html must consist from two tags: the <link rel="preload"> and the <link rel="stylesheet"> (or script) in order to be preloaded by browser.
Working example for me is:

    {% compress css file style %}
    <link rel="stylesheet" href="{% sass_src 'css/scss/style.scss' %}">
    {% endcompress %}
    <link rel="preload" as="style" href='{{ compressed.url }}' crossorigin>

I didn't find out how to get this working with the preload type on compress templatetag.

I think, this should have clearer explanation in the documentation.

[PetrDlouhy]

This issue closely relate to #690

[PetrDlouhy]

I just realised, that the trick with the compressed variable doesn't work in offline mode. So my final solution is to override the preload templates:

templates/compressor/css_preload.html:

{% include "./css_file.html" %}
<link rel="preload" href="{{ compressed.url }}" as="style" />

templates/compressor/js_preload.html

{% include "./js_file.html" %}
<link rel="preload" href="{{ compressed.url }}" as="script"/>

And use the compression as the documentation recommends:

    {% compress css preload style %}
    <link rel="stylesheet" href="{% sass_src 'css/scss/style.scss' %}">
    {% endcompress %}

I think, that might be the desired content of those templates for most users, but I am not sure about the original intention of the preload compression type (maybe sometimes it would be desirable to use the preload link with crossorigin parameter)

[karyon]

the way the feature currently works you have to use the same compress tag twice, see #951 (comment). I agree this needs better documentation.

Out of interest, in your solution you're putting the preload tag right before the actual stylesheet/script tag. What's the benefit of that compared to just the script tag? I thought the point of preload is to preload a resource that will be required some time later, not in the exact same place. the html.

[jsumnerPhD]

@PetrDlouhy @karyon You are both right... I did a poor job with the documentation and I will try to make a PR with an update this week. The intention of the preload option was always to just generate the preload link element; the usual invocation of compress still being required to actually use the preloaded resources. The idea was to avoid forcing these two lines of HTML from having to appear together and support the prototypical (although trivial) use pattern from mdn where the preload is in the head but the resource itself isn't discovered until much later.

[jsumnerPhD]

@karyon As mentioned in the PR, I'd just cherry-pick the last commit... I have some merge conflict resolutions that I wouldn't want to cruft up the main git log. Cheers! (I will try to take a closer look at #961 and a second look at #987 as well.)

[PetrDlouhy]

@jsumnerPhD
I am not sure, if I understand current solution correctly. But isn't repeating exactly the same content of the compress tag for the regular tag and for preload tag very inconvenient and potentially can easily lead to bugs?

Or is there some way to reference the previously generated tag?

[jsumnerPhD]

Hi @PetrDlouhy,

I think the repetition is somewhat unavoidable given how the preload directive works. The proposed solution essentially re-uses the regular tag generation workflow to ensure that the hash in the preload tag is correct (in fact, that is all that it really does). There may indeed be another way to reference that hash.

Cheers,
J