Skip to content
This repository has been archived by the owner on Sep 17, 2019. It is now read-only.

EQCSS is initiating others CSS files and lead to timeload issues #310

Open
tlartaud opened this issue Aug 21, 2018 · 13 comments
Open

EQCSS is initiating others CSS files and lead to timeload issues #310

tlartaud opened this issue Aug 21, 2018 · 13 comments

Comments

@tlartaud
Copy link
Contributor

image

Also see https://wp-customerarea.com/support/topic/the-pages-load-too-slowly/#post-319287

@tomhodgins
Copy link

If you are certain you don't need to parse EQCSS styles from a CSS stylesheet you can add data-eqcss-read attribute to any link, style, or script tag to skip processing of it entirely:
https://github.com/eqcss/eqcss/blob/gh-pages/EQCSS.js#L133

@tlartaud
Copy link
Contributor Author

@tomhodgins Thank you for reacting to this, this is very kind!

However, this does not help at all. How should I add a custom attribute to every loaded style of a Wordpress instance?

I would need to instantiate EQCSS and tell him which file I need to process, or, at least, I would need an argument like data-eqcss-process, so EQCSS will only process the required file. However, this is not the best, simply because there is no way in Wordpress to add custom attributes to styles links, except with Javascript, which is such a thing that I don't want to do for performances reasons.

Is there any planned update about this maybe?

Thanks a lot.

@tomhodgins
Copy link

However, this does not help at all. How should I add a custom attribute to every loaded style of a Wordpress instance?

document.querySelectorAll('link, script, style')
  .forEach(tag => tag.setAttribute('data-eqcss-read', true))

This JS code, after the <script>, <link>, and <style> tags in the document, but before EQCSS is loaded will prevent EQCSS from reading any of these files for example.

Also, I believe the first time it loads may be the only time this XHR happens - after the browser knows the file has been loaded, the XHR goes to cached file, rather than making a new request for a file the browser knows it has already loaded.

Is there any planned update about this maybe?

No, especially no breaking changes. I have other element query plugins you can use if you want similar functionality but that functions in a different way, like jsincss-element-query which runs entirely from JS.

@tlartaud
Copy link
Contributor Author

tlartaud commented Sep 13, 2018

Also, I believe the first time it loads may be the only time this XHR happens

Yes, you right.

This JS code, after the <script>, , and <style> tags in the document, but before EQCSS is loaded

I do not really like the JS script adding data-eqcss-read on styles inclusions. It's okay for static sites, not for WordPress, but thank you for the recommendations, I'll check this ! Plus, I can't be sure on WordPress that a plugin or the theme itself will output all of this in the order I need.

Regards.

@vpratfr
Copy link
Member

vpratfr commented Sep 13, 2018

Thanks a lot for the input.

Maybe we cannot do much about inserting anything automatically but we could for sure get some instructions for end users on how to have their theme implement the fix.

@tlartaud
Copy link
Contributor Author

The only real solution I see would be to be able to tell EQCSS to only parse styles that have a data-eqcss-process attribute. Using the linked solution below, I could be able to add the attribute on our eqcss stylesheet only.

https://wordpress.stackexchange.com/questions/110929/adding-additional-attributes-in-script-tag-for-3rd-party-js

@tomhodgins
Copy link

A breaking change like that to how styles are loaded would break all of the (hundreds of) sites using EQCSS presently, so such a drastic change to how the plugin works cannot be made at this point.

If you can show me where you've used the element queries, and what features of EQCSS you need, I'm very confident we could switch it to another element query plugin that doesn't even have the capability for XHR-loading styles in the first place. There are plenty of other viable options, some that even perform better than EQCSS, but breaking EQCSS for all users to solve this problem isn't an option.

@tlartaud
Copy link
Contributor Author

I do not really understand why adding an option would be a breaking change. I'm not asking to change the whole default behavior, you can keep it unchanged. However, there are many ways to pass some options to EQCSS, to tell him how it should interact with the stylesheets.

Like any other JS/jQuery plugin, you could allow us to pass some options array like below

eqcssOptions: { mode: 'readallfiles' }
readallfiles could be the default mode, so, passing this option could be optional (= NO BREAKING CHANGE)

eqcssOptions: { mode: 'readonlyselectedfiles', files: { 'mystyles.css', 'myotherstyle.css' } }

If you can show me where you've used the element queries, and what features of EQCSS you need,

Sure :) Thanks.

You can view it live on http://demos.wp-customerarea.com/freelancers/customer-area/files/my-files/
Connect with login jake and password jake123

image

@tlartaud
Copy link
Contributor Author

Hi @tomhodgins , Hope you are fine.

I saw that you recently updated EQCSS. I was wondering if you plan to add some options to only parse given files, instead of parsing every file except excluded ones?

I temporarily fixed our issue by adding a JS script that adds a data-eqcss-read to all the script/link tags of the page, but this is not the best solution ever, this is a bit consuming, even if it's better than nothing for now.

Best regards.

@tomhodgins
Copy link

I don't see this changing in EQCSS any time soon, the core parts of the EQCSS experience are that you can include it in any browser and all your styles are upgraded without any further work on your part, and that it suppports IE8, so even in a browser so old it doesn't have CSS media queries - you can have element queries and all these features with zero configuration just by including the JS files once.

But the same experience that makes EQCSS flexible in some ways (many features, good support) limit it in other ways like you're pointing out. To change it would break all of the sites out there currently using it - so how can we pursue better performance and more flexibility without touching EQCSS?

EQCSS has the features of about 20 individual plugins all rolled into one (it's big), so if you only need width-based element queries it can also be overkill.

I have another plugin called jsincss which is simply a virtual stylesheet manager. It doesn't read your CSS at all, it just creates <style> tags and populates it with the output of different function calls when different events happen in the browser. If you haven't called jsincss with anything, nothing will happen. EQCSS contains something like jsincss inside of it, but not so clearly defined that you can use it by itself. Then we're able to extend this jsincss engine using different plugins like jsincss-element-query which brings only the element query functionality similar to EQCSS, or jsincss-parent-selector for the ability to target an element's parent, similar to EQCSS, but you can mix-and-match which jsincss plugins you want to use and you don't need to include any that you don't want. The result is a 10x performance increase, and the ability to more flexibly control what runs, and when. Though there are jsincss plugins for almost all EQCSS features, very rarely do I include more than 2 in something I'm building, so jsincss gives me the power to exclude all that code I didn't need.

If you're looking for more performance, and IE8 support isn't a concern, I'd recommend having a look at jsincss + jsincss-element-query (modular, good performance) for replacing EQCSS (complete, good browser support).

Just for an example, here is the same demo, one in EQCSS and one with jsincss + jsincss-element-query. Compare these in complexity, and performance:

<div>Make me 500px+ wide</div>

<style>
  @element div and (min-width: 500px) {
    :self {
      background: lime;
    }
  }
</style>

<script src=https://elementqueries.com/EQCSS.js></script>
<div>Make me 500px+ wide</div>

<script type=module>
  import jsincss from 'https://unpkg.com/jsincss/index.vanilla.js'
  import element from 'https://unpkg.com/jsincss-element-query/index.vanilla.js'

  jsincss(event => element('div', {minWidth: 500}, `
    [--self] {
      background: lime;
    }
  `))
</script>

@tlartaud
Copy link
Contributor Author

tlartaud commented Aug 21, 2019

@tomhodgins Hi,

To change it would break all of the sites out there currently using it

I'm sorry, but I don't understand why you keep saying that adding an option to a script would break anything. I'm not asking to change the default behavior, but any script can look on initialization for some optional variables that would change the behavior of the script. So, instead of scanning everything, on initialization, the script could scan instead only the given files. If those optional variables wouldn't be found, the script would keep running as before on other sites....

EQCSS has the features of about 20 individual plugins all rolled into one (it's big), so if you only need width-based element queries it can also be overkill.

Thanks for the warning!


Anyway, thank you for this script, for the time taken to answer my request, and for pointing out your others alternatives (I'll check them), This is appreciated.

Regards.

@tomhodgins
Copy link

I'm sorry, but I don't understand why you keep saying that adding an option to a script would break anything. I'm not asking to change the default behavior, but any script can look on initialization for some optional variables that would change the behavior of the script. So, instead of scanning everything, on initialization, the script could scan instead only the given files. If those optional variables wouldn't be found, the script would keep running as before on other sites....

Where or how would you include something like this? It makes sense for plugins where you would have to do something like EQCSS.init({scan: false}) compared to EQCSS.init(), but currently there is no initialization mechanism built in - it just runs when it runs. How or where could you define a variable reliably that would always be defined before EQCSS happens to load and run?

@tlartaud
Copy link
Contributor Author

tlartaud commented Aug 22, 2019

Just use an optional global variable like EQCSS_options, and if it's defined, read it and use it instead of parsing every <styles/link/script> tag in EQCSS.load. https://github.com/tomhodgins/element-queries-spec/blob/gh-pages/plugin/element-queries.js#L59
Then apply the EQCSS.process to only the given styles/link/scripts that have been found in EQCSS_options.styles, for instance.

Then it would just be up to the user to define their option array before your script is loaded.

<script src=https://mysites.com/EQCSS_options.js></script>
<script src=https://elementqueries.com/EQCSS.js></script>

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants