languagetool-org / languagetool-website-2018

OUTDATED, do not use anymore
12 stars 11 forks source link

Analyze how to optimize loading times #27

Closed danielnaber closed 6 years ago

danielnaber commented 6 years ago

Any optimizations should be discussed here first. Also use Google's PageSpeed Insights.

dpelle commented 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
danielnaber commented 6 years ago

Thanks, Dominique, I've done that for all PNG images and indeed helps quite a bit.

dpelle commented 6 years ago

Where is the repository of the new LT website? I wanted to check if I spot anything else relevant for this ticket.

danielnaber commented 6 years ago

https://github.com/languagetool-org/languagetool-website-2018

dpelle commented 6 years ago

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.

danielnaber commented 6 years ago

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.

dpelle commented 6 years ago

@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
danielnaber commented 6 years ago

Thanks. These are images from the framework, I don't think they are in use.

nickchamel commented 6 years ago

@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

danielnaber commented 6 years ago

@neprev I've removed app.js - do you have more ideas how to improve page loading speed?

nickchamel commented 6 years ago

@danielnaber I'm testing production - dom content loading pretty fast:

screen shot 2018-05-27 at 22 18 02

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.

danielnaber commented 6 years ago

Okay, then closing for now.