Closed danielnaber closed 6 years ago
Another easy step to make the web site more responsive: run "optipng -o7 foo.png" to reduce the size of png images. It's lossless so there are no drawbacks. I just tried it on 2 png at random and it reduced the size by more than half for each of them:
# Image size before
$ ls -l korrekturen_de.png iserv.png
-rw-rw-r-- 1 pel pel 5070 apr 26 23:44 iserv.png
-rw-rw-r-- 1 pel pel 6395 apr 26 23:44 korrekturen_de.png
$ optipng -o7 iserv.png
$ optipng -o7 korrekturen_de.png
# Image size after
$ ls -l korrekturen_de.png iserv.png
-rw-rw-r-- 1 pel pel 2368 apr 26 23:44 iserv.png
-rw-rw-r-- 1 pel pel 2770 apr 26 23:45 korrekturen_de.png
Thanks, Dominique, I've done that for all PNG images and indeed helps quite a bit.
Where is the repository of the new LT website? I wanted to check if I spot anything else relevant for this ticket.
I cloned https://github.com/languagetool-org/languagetool-website-2018 and ran "pngcheck -v foo.png" on the images. Some of the images have text metadata which we could strip. For some images, the text metadata is actually much bigger than the image itself. Take this example:
$ pngcheck -v public/images/logo-160.png
File: public/images/logo-160.png (15740 bytes)
chunk IHDR at offset 0x0000c, length 13
34 x 33 image, 32-bit RGB+alpha, non-interlaced
chunk pHYs at offset 0x00025, length 9: 2835x2835 pixels/meter (72 dpi)
chunk iTXt at offset 0x0003a, length 15250, keyword: XML:com.adobe.xmp
uncompressed, no language tag
no translated keyword, 15229 bytes of UTF-8 text
chunk cHRM at offset 0x03bd8, length 32
White x = 0.31269 y = 0.32899, Red x = 0.63999 y = 0.33001
Green x = 0.3 y = 0.6, Blue x = 0.15 y = 0.05999
chunk IDAT at offset 0x03c04, length 356
zlib: deflated, 32K window, maximum compression
chunk IEND at offset 0x03d74, length 0
No errors detected in public/images/logo-160.png (6 chunks, -250.7% compression).
$ ls -l public/images/logo-160.png
-rw-rw-r-- 1 pel pel 15740 apr 27 10:42 public/images/logo-160.png
There is a 15KB XML text embedded in the image added by Adobe photoshop CC 2017 (Windows). It's not compressed, so I can see the XML content using "vim public/images/logo-160.png" for example.
It can be stripped out using:
$ optipng -o7 -strip all public/images/logo-160.png
$ ls -l public/images/logo-160.png
-rw-rw-r-- 1 pel pel 411 apr 27 10:41 public/images/logo-160.png
So the size of that image went from 15740 bytes to 411 bytes (38 times smaller). The same remark can apply to some other images.
I can see the XML content using "vim public/images/logo-160.png" for example.
That image isn't used anywhere it seems, I have removed it.
@danielnaber wrote:
That image isn't used anywhere it seems, I have removed it.
Thanks. That was just one example though. There are several other images with useless tTXt or tEXt png chunks. So you may want to run "optipng -o7 -strip all foo.png" on all pngs.
Many of them have admitedly small texts, but a few of have large amount of text:
public/vendor/tcg/voyager/assets/img/screenshots/theming.png (also 15 KB of useless text) public/vendor/tcg/voyager/assets/lib/js/tinymce/plugins/youtube/icon.png (also 15 KB of useless text)
Many have smaller amount of text. For example ./public/images/maily-sad.png has:
chunk tEXt at offset 0x00025, length 25, keyword: Software
chunk iTXt at offset 0x0004a, length 808, keyword: XML:com.adobe.xmp
Thanks. These are images from the framework, I don't think they are in use.
@danielnaber
Actually app.js
is not needed. I think that this is the result of the webpack build that was once on the project. In fact, it's just a script bundle. Like vendor.js (but it is not included in the project).
What about two requests of the jQuery
- I see only one. There are also jquery-ui
- this is another library
@neprev I've removed app.js
- do you have more ideas how to improve page loading speed?
@danielnaber I'm testing production - dom content loading pretty fast:
Then, various scripts are loaded in the background. Basically there are a lot of requests of advertising services (while the banner on the page os only one). But there are also requests of scripts connected from other servers (they are not cached and do 2-3 requests by themselves) - this is utils.js, gpt.js and piwik.js. At least, the utils.js here is not entirely rational - it's used to create a form for sending a subscription request. For this we have 2 additional requests and the form is built during the time after loading the scripts, but this task can be solved by creating a regular form with an Ajax request to our API. But in fact, i don't see any problems with page loading. For me website loads quickly.
Okay, then closing for now.
Any optimizations should be discussed here first. Also use Google's PageSpeed Insights.