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

Add Async and Defer boolean attributes for script resources #464

Closed
wants to merge 3 commits into from

Conversation

symbiogenesis
Copy link

No description provided.

/// Adds the specified boolean attribute to the next HTML element that is being rendered. Boolean attributes such as 'async' and 'defer' have no value. They are true when present and false otherwise
/// </summary>
/// <param name="name">The name of the HTML attribute.</param>
void AddBooleanAttribute(string name);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this method should not be defined on this interface. You can create an extension method in your project.

@djanosik djanosik added this to the Version 2.0 milestone Dec 7, 2017
@exyi
Copy link
Member

exyi commented Dec 27, 2017

Actually, I don't think that the Defer and Async api should exist in this form, as setting these properties on one script resource would break all dependencies. It also pretty useless to load the scripts asynchronously when they are already on the end of the page, and styles are not synchronous by default.

Maybe we could have a global option that would render all script in the head with the defer attribute, but actually doubt it would make the performance much better.

@symbiogenesis
Copy link
Author

symbiogenesis commented Dec 28, 2017

I wanted get a good score on Google PageSpeed, even if there is no other benefit. It is an SEO thing.

Currently, PageSpeed says:

None of the above-the-fold content on your page could be rendered without waiting for the following resources to load. Try to defer or asynchronously load blocking resources, or inline the critical portions of those resources directly in the HTML.

Remove render-blocking JavaScript:

I also wanted to load scripts via CDN with integrity hashes, and had put the script tag directly in the dotmaster.

However, now I am able to specify the Integrity hash, thanks to another pull request, so I could probably load all of my scripts via the registration, and wire up the dependencies correctly. And have all the scripts loading at the bottom of the body, in the correct order.

That may make pagespeed happy, although I would need to test. It doesn't specifically say this will solve the problem on their help page. https://developers.google.com/speed/docs/insights/BlockingJS

But, if that is sufficient, perhaps this pull request isn't necessary as long as one is consistent in using the script registration.

@exyi
Copy link
Member

exyi commented Dec 28, 2017 via email

@symbiogenesis
Copy link
Author

symbiogenesis commented Dec 29, 2017

Given that the entire point of DotVVM is to minimize the need to use javascript, it makes sense that we should, by default, assume that we have predictable control over how it is used and in that case we may be in a position to always defer javascript. Async probably not, although I'm not clear on what it truly means. I'll open a separate issue, as you suggest.

Do you have any info about integrity and performance? I actually think that browsers could use that for caching (as content adressed blobs), but I have not seen anything about that.

That is a brilliant idea, although I don't know how local caching works in browsers. May vary by browser. That would be a great question to ask Mozilla, Google, etc.

@symbiogenesis
Copy link
Author

symbiogenesis commented Dec 29, 2017

The response from WHATWG is

As for identifier-based caching, the problem is that this exposes, across origins, which resources you have visited. w3c/webappsec-subresource-integrity#22 has more details and pointers on this.

whatwg/fetch#301

@exyi
Copy link
Member

exyi commented Dec 29, 2017

Given that the entire point of DotVVM is to minimize the need to use javascript
I'd be careful with this assumption :P Although dotvvm is definitely designed to help you with that.

async is problematic, as it does not guarantee the order of execution, and I don't think it will have significantly better performance than defer.

And thanks for the info about the subresource integrity, I have also found an interesting study of the problem (https://hillbrad.github.io/sri-addressable-caching/sri-addressable-caching.html). It just seems that nothing is easy on web :)

I'm closing this PR in favour of #528, thank you.

@exyi exyi closed this Dec 29, 2017
@exyi exyi removed this from the Version 2.0 milestone Dec 29, 2017
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

Successfully merging this pull request may close these issues.

3 participants