Performance suggestions

Joined
Mar 21, 2018
Messages
2
MangaDex can't be a lightweight website, being image-heavy, but looking at the network traffic there's a few thing I'd like to suggest to speed up loading and reduce server load.

Keep in mind that the home page loads more about 3MB of data, with about 180 network requests. Now, in no particular order:

- use css image-slicing for the country flags, would remove ~40 requests (-22%)
- use vector social icons (e.g., https://github.com/edent/SuperTinyIcons), -18KB, -5 req if bundled in a single SVG file

- drop the "Ubuntu" custom font and rely on system fonts (-700KB (-23%) for cold-cache users)
- alternatively, don't serve .ttf files, but switch to .woff2 and reduce the set of included characters —will reduce the font files size

- only load chart.js on pages where it is actually used, -50KB
- minify and bundle all javascript in a single file, -9 req
- bundle all css in a single file, -7 req

- depending on your back end, it would be worth passing at least the image covers through something like jpegoptim, to reduce their size; that will easily get a 10-20% reduction in size.
 
Contributor
Joined
Mar 10, 2018
Messages
3,507
This is nice, i also prefer performance over interface quality, all resources should go to the load of manga pages, everything else can be minimal as much as possible, infact would be good to have more customizations about the widgets used in the main page and the whole GUI overall, so the loading time and burden will be much mitigated.
 
VIP
Joined
Feb 11, 2018
Messages
375
Promising ideas. I don't know much about the technical details of these things, but they sound reasonable. (This is the first time that I've heard of CSS image-slicing...)

I'd be cautious about any sort of lossy compression like jpegoptim, though. Group releases should be hosted unmodified (and if the groups are compressing their images suboptimally, it should be changed on their end) to try and stave off this kind of quality loss. Though obviously, it's fine if it's used on the covers on the front page, which are already downscaled thumbnails anyway.
 
Custom title
Staff
Developer
Joined
Jan 19, 2018
Messages
2,696
I forgot to reply, but yeah, most of these I've already been wanting to do. The flags should be relatively simple to rewrite to css sprites once I just get around to it, but god knows. Proper js bundles are also something I really want to do, but there's a lot of script here that needs to be completely rewritten and I'm still waiting on something we've been working on to finish before I can start with it.
 
Joined
Mar 21, 2018
Messages
2
Setting up the sprite generation as part of the build process (e.g., with the "sprity" npm package) could take some time, but as a one-off conversion, it takes about 15m to generate the code with something like https://css.spritegen.com and update the CSS.

The result is 3KB of additional CSS, and 14KB¹ of combined flags that can be requested in one go. Compare to 38 separate requests that sum up to 120KB.

As ununseti mentioned, `jpegoptim` would be mainly for cover and cover thumbnails, which I assume are the most requested images. Even if it can apply lossless optimisation, running it on all the pages would be expensive in terms of resources.



[1] Extra mad step: 14KB is small enough to inline directly in the CSS as data URL 😁
 

Users who are viewing this thread

Top