-
-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Optimize load times of images & icons #1066
Comments
I did some more research regarding this problem. I still think that the #5985 is the direction we should head towards. It seems that Github is actually using a very similar solution: Can anyone check if that's something that might work for us? From the text it is not clear at which point they are injecting SVG code into HTML...They were using icon fonts before, an approach that I was pondering as well, and didn't notice any performance change after making the switch. Icon font is still an option for us, but there are some a11y problems related to it. Is it possible to measure performance impact of #5985 to server? @skjnldsv @nickvergessen @rullzer @MorrisJobke EDIT: here's Github's injector helper script primer/octicons_helper |
They do it in their ruby server. So it's basically the same as #5985 |
The only problem I see there is, that the browser can not cache that asset and thus it is loaded all the time. On the other side: the server should have this in memory all the time anyways and just serves it. Only problem is, that we also do a lot of JS injection of icons, which is not possible with that approach. and would require to load the asset via browser anyway. Nevertheless it's worth a try. |
With HTTP/2 this should not be that much of an issue anymore, I think. 😉 |
That, plus the move to Vue and more advanced file loaders like the url-loader that just inlines images smaller than a certain threshold make this less of an issue. I'll therefore close this ticket as there are now de facto standards that make the improvements possible without requiring us to implement these "hacks". |
No matter the outside technical developments, we still need to make sure to use all of the means we have to optimize performance. Not everyone checks out Nextcloud on a fast landline. 😉 |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@pixelipo, we add some strings to the svg on the colour api, so it's logical that it's bigger. |
it's 10 times the size, which is a bit concerning... |
Hum, it's more like 100Bytes more, or am I misreading your screenshot? |
you're misreading it - in the first line, actual image size is 176bytes, but a total of 1.07 kilobytes were used up to fetch it. |
Ah yes! How is that possible then? The data comes from the headers or something? |
I don't buy that we add 900kb of headers. @pixelipo any way to obtain more info on the request? |
But it's 900 bytes, not KB? |
Right. I should not answer so fast. |
I looked at some requests and the ~1kb of header data seems pretty reasonable, but there is not much we could do about this, besides merging icons to a sprite. @pixelipo I also don't see any huge difference between the svg api endpoint and the direclty fetched svgs. Probably something related to the webserver setup? |
@pixelipo I noticed the php script is slowing things down yes!
That's why we have hard caching :) |
Well yes there is overhead of course. But it should be 1 time. I assume there is some theming going on and that is why we don't ship it as static asset right? |
Fixed with #12016 (using inline images in css instead of a sprite) |
It would be good to reduce the number of HTTP requests necessary to load the icons. Currently every icon is its own file. Now that we don’t have PNG anymore it’s high time to optimize the SVG delivery.
We could and should optimize that by putting the SVG icons into a sprite. We can use http://iconizr.com for that. (Which uses https://github.com/jkphl/svg-sprite )
cc @nextcloud/designers and especially @juliushaertl @Henni because you seemed interested in that. :)
The text was updated successfully, but these errors were encountered: