run onComplete callback too slow about css-vars-ponyfill HOT 8 CLOSED

@chenyulun --

Without a working demo, there isn't much help I can offer. Can you recreate this scenario on https://codesandbox.io, https://stackblitz.com, https://github.com/features/codespaces?

I can say that it looks like you're processing a lot of CSS based on the nodeArray length and the parsing time, which means a the ponyfill has a lot of work to do. The easiest way to speed up the ponyfill is by reducing the amount of work it has to do. Configuration options like options.include and options.exclude can help with this.

from css-vars-ponyfill.

This is our internal component library project and cannot be opened to the extranet，
If you have a low-end Android device, I can send you a test link，（This page on my low-end device takes 2 or 3 minutes to render）
Please provide your email address，

Such a large number of problems are estimated to be difficult to optimize and solve, I do not have too much hope

from css-vars-ponyfill.

I can see several things that help explain your performance issues just by looking at the first run:

run getCssData count:[1]
css-vars-ponyfill.esm.js:1561 nodeArray.length: 158
css-vars-ponyfill.esm.js:1591  Parse CSS and variables count:[1]: 11611.660ms
...
css-vars-ponyfill.esm.js:1730 run onComplete count:[1]: 16051.656ms

1. Based on the nodeArray.length, you are processing a lot of <style> elements (158)
2. Based on "Parse CSS and variables count" time (11.6 seconds), you are processing a lot of CSS
3. Based on the environment (Android 5 / Chrome 39), you are testing on very old hardware and software.

Given these things, I am not surprised you are seeing performance issues. It seems like you're asking the ponyfill to do a lot of work. That's going to take time. If you want the ponyfill to take less time, the first step is to figure out a way to ask the ponyfill to do less work.

Try creating a demo with one component from your library which we can use to evaluate the ponyfill's performance. Then try 10, 100, and 1000 instances of the same component to see where the performance bottleneck comes from. Then try 2 different components, then 100 then 1000 instances of those two components. And so on until you can recreate the problem. For example, if you're injecting a stylesheet with each component instance, you'll get much better performance if you switch to injecting one stylesheet that styles all components instances of the same type. You can use https://codesandbox.io, https://stackblitz.com, or https://github.com/features/codespaces to make the code shareable. This is an easy demo to make, it will prevent you from having to share company code, and will help us identify the cause and hopefully troubleshoot the issue. Just make sure to use the same dependencies when possible (React, Vue, Angular, Bootstrap, Tailwind, etc.) so the demo matches your application as much as possible.

A few closing questions/suggestions:

• What is rendering performance like without the ponyfill? My gut tells me that if the ponyfill takes ~16 seconds to process an application's CSS, the application almost certainly has significant performance issues aside from the ponyfill.
• If you don't need to modify custom property values on the client, consider using a tool like PostCSS to transform custom properties to static values at build time so you can avoid the performance hit on the client.
• Are these performance issues happening in a real-world or internal/test scenario? By this I mean are users experiencing these issues while using your application (real-world) or are these issues the result of rending every component in your system on an internal test page or component catalog (not real-world)? If the issue isn't happening in a real-world scenario, it may be easier to "fix" the issue by not rendering hundreds of components on your internet test page(s).

Happy to help if/when a public demo is available.

from css-vars-ponyfill.

I guess it may be that the browser of low-end Android devices cannot effectively use multi-core CPU, resulting in low performance. Can you try to use worker to turn on Multithreading for computing parseCss and parseVar?

from css-vars-ponyfill.

Any browser that has support for service workers also also has support for CSS custom properties, so they would be no value in adding worker support to the ponyfill.

Closing for now, but happy to reopen if/when a demo is available to investigate further.

from css-vars-ponyfill.

https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers

from css-vars-ponyfill.

I did an experiment. I have a vivo X7 mobile phone. The system comes with a browser. The chrome kernel is version 39. The process of running cssvar is very slow. However, for the same mobile phone, if a browser with a higher version of chrome or Firefox is installed, it runs cssvar very quickly. Therefore, I intuitively think it is caused by the inability of browsers with a lower version to effectively use multi-core CPU

In addition, by worker, I mean window.Worker, not service worker

from css-vars-ponyfill.

@chenyulun --

Very interesting. I learn something new every day. :)

Even though IE11 support web workers, I'm not sure adding support in the ponyfill is worth it in 2022. IE11 is the primary use case for this ponyfill, and that browser will officially reach end of life on June 15, 2022. Aside from that, offloading tasks to a web worker will free up the main thread but it won't significantly reduce the amount of time required to complete a task (and in same cases, it can actually take longer due to worker overhead). If the ponyfill takes two minutes to parse your CSS, a web worker isn't going to magically solve your problem.

@harry32009 --

You may be right. It's hard to know how a web worker would behave in such a scenario.

from css-vars-ponyfill.