| Sebastian_Berlin-WMSE | |
| Jun 24 2019, 9:01 AM |
| F29629215: Screenshot from 2019-06-24 11-43-59.png | |
| Jun 24 2019, 9:52 AM |
When viewing a page with a lot of videos, e.g. https://commons.wikimedia.org/wiki/Category:Videos, it takes a long time to load. Enough so that Firefox suggests stopping the page loading because it's slowing the browser. The same page loads fine with the non-beta player.
This happens in Firefox 67.0.2.
Confirming. Using https://commons.wikimedia.org/wiki/Category:Videos?debug=true :
It transfers a large webm file while I only expect a small thumbnail file?
Probably should adjust the preload setting; ISTR some related issue in past. Will test further once no longer encountering unrelated server errors.
Actually its also pretty slow if you completely disable the JS player. Were doing inline video now, im wondering if the render is a lot more expensive now (and not cached due to beta ?)
@Aklapper's results are strange.. All video elements are hinted not to preload.. All JS instantiations on pages with more than 10 videos are also hinted NOT to preload. As such entire downloads really shouldn't be possible.. Maybe Chrome is being too smart for it's own good.
We can likely improve performance of JS initialisation a bit by breaking up the collections .each iterator, to make use of setTimeout/requestAnimationFrame, so that not everything happens in the same execution cycle. Does seems as if Safari is particularly slow when it has many <video> elements however...
We probably should also profile a page like this on the PHP side.. It's just a bit difficult to reproduce a Category page like that locally in order to run that profiling....
This seems to be largely dealt with the new load-on-click mode, I'm going to close it out.