minetest.github.io
minetest.github.io copied to clipboard
minetest
Large download size
The website's gallery doesn't have thumbnails, and the bootstrap installation could be stripped down. The W3C mobileOK Checker (which has some quite questionable suggestions, but its download size counter is useable) reports:
Primary document: 9.2KB, Images: 2.6MB, Style sheets: 124.6KB
It explains the need:
Big pages require a possibly high cost and a long waiting time in many mobile networks. For instance, on many mobile networks, downloading 100KB worth of data takes as long as 1 minute.
- [x] Gallery needs thumbnails (or responsive images, or something like that)
- [ ] Bootstrap could be stripped down → would reduce stylesheet's size
The gives this W3C mobileOK Checker interesting suggestion:
Make sure to separate CSS styles defined for
screenandhandheldmedia types so that only relevant CSS styles are downloaded by most devices.
Can/should we implement it?
Note that the "real" size of the page is usually less due to compression, eg, bootstrap goes from 120KB to 23KB. Images don't compress quite as well though...
Also, a lot of what's good for HTTP/1.0 and HTTP/1.1 (eg, inlining and sharding) is bad for HTTP/2.
Additional performance improvements:
- [ ] Make the splash images responsive (would reduce size substantially, but would probably require moving away from CSS
background-imageto do sanely). - [x] Inline
main.js(it's tiny, and requests have a huge overhead on HTTP <2) - [ ] Ditch Bootstrap :-P (a smaller, simpler library would probably still be needed).
- [ ] Don't use a custom font.
- [x] [minor] Serve logo (and anything else we can) as a (minified & stripped) SVG with a PNG fallback (SVG support) Example:
<img src="media/logo.svg" onerror="this.src=this.src.replace('.svg','.png');this.onerror=null;" />
Surely there's a CSS optimiser that reads a collection of pages, and then makes a CSS file with only the rules used? ie: removes unused rules.
[minor] Serve logo (and anything else we can) as a (minified & stripped) SVG with a PNG fallback (SVG support)
We do not try to support IE 8, so why a PNG fallback?
Ditch Bootstrap :-P
Perhaps it can be done in the future. The most complex thing is to have a good, responsive navbar.
I've wondered myself as well whether an svg logo would be smaller, but as it seems it isn't. Before we apply it, we should compare svg vs png sizes.
And about responsive images, their implementation seems to be shit, according to my testing. It seems that mobile firefox always downloads the largest image.
@Calinou: SVG only then, doesn't matter much to me.
@est31: SVG icon size I looked into it and this is what I came up with: An optimized SVG icon is 2527 bytes [1], whereas the 96x96 favicon that's currently used is 2829 bytes!
However, the nginx proxy that c55 has set up compresses things with gzip. This (with a compression level of 4) results in the SVG being only 1003 bytes (note, however, that 2527 may be below the gzip minimum size threshold that c55 has set). Compressing the PNG is, predictably, far less successful, with an output size of 2862 bytes (more than the original).
So an SVG is actually substantially smaller than the PNG.
Responsive images Well, we always send the biggest image now anyways so it wouldn't much worse. You could probably do something with CSS or JS that would work better, but of course it would add some overhead.
[1]: I used http://petercollingridge.appspot.com/svg-editor on misc/minetest.svg with everything turned on except "Remove IDs" (breaks tree and cactus shadows) and decimal places set to 1.
I noticed that the background images of the headers in other pages than home are 1920x1080, although you can only see a small part of it (e.g. in the community page you can only see the sky; my browser window is ~1920x1080).
These images take almost 5 seconds for me to load (per page), while everything else loads in under 1 second.
For the community tab and this browser resolution, you'd get the same visuals by just making the community header a solid blue background color, and speed up the page load by a factor of 5.
I can reproduce what PilzAdam says, except that I have a few pixels of some trees showing up at the bottom. The image only takes around 0.8s to load for me, but my connection speed is above-average (~30Mbit/s).
I agree, we could use plain colours or a gradient instead for the page jumbotrons.
Another thing to consider would be using progressive JPEG so that low resolutions are loaded quickly and the images improve in quality as the download finishes.