Newbie Question from Germany: images in cache twice as big as originals, feature or bug

1

Hello world,
sorry for my bad english first. Second is, that i work with grav just one week and i am new with markdown and ?Twig? and so on. I choosed grav, because i am strong 55+ and i like to work on pages with ssh and vi in terminal. OK, i build a small site with too grav instances, because it`s not easy for me to understand your routing, cache, slug and so on. Here they are:

www.baiersbronn.jetzt with admin panel based on skeleton big-picture
www.baiersbronn.jetzt/blog with admin panel based on skeleton clean-blog

everything is up to date, caching and Apache deflate (Compression) is ready and my question is about the big size of my image in cache:

And: because i am a newbie i can put just one pic in my post. If you want to see the images, you have to put the url together for your own:

original Pic. is 2000x1100 Px and 381234 Bytes:
https://
www . baiersbronn . jetzt
/user/pages/01.home/_start/01_huzenbacher_see_2000x1100_K20.jpg

Pic in Cache is 2000x1100 Px and 852702 Bytes, twice as big and Extension .jpeg (?)
https://
www . baiersbronn . jetzt
/images/5/b/1/5/a/
5b15ae970ce651d598e3eb4edab6817047dfa174-01huzenbachersee2000x1100k20.jpeg

In the 2 Backends the quality of images is set to 100%, because in older days you made the work with your images before they come into the internet. Bye the way, the google page speed test for this site with all caching and compression ist sooooooo poor:

Desktop: Low: 29/100
Mobile: Medium: 71/100

OK, any suggestions to improve speed and quality? My work with the pictures at home was worthless:

Original: 3264 x 2448 px and 3,3MB online with 2000x1100px and 381234 Bytes.

Where does the 85% Quality of pictures come from which is the default im Backend?
Is there a way to serve the original Image without any ?? Manipulation or Optimaziation ?? from grav? What abaut a way to serve different qualities of one image with sourceset and so on?

Just one sentence and i have finished. Because i am a newbie my first goal was to get the site running, because there are differences between Ubuntu 16.04 at home and the situation online by my webhoster (curl_exec() has been disabled for security reasons and so on). In Case of /home and /blog with the 2 instances of grav at baiersbronn.jetzt i choose the same picture for the starting point of home and blog. The impression when you see the pic is surprising different. In case of /blog the quality is good, in case of /home the quality is poor. OK, the section is bigger in the case of /home, but i am thinking about the background of this all. Is this the choosen skeleton (shure when you think about the section), but maybee there are other reasons in presentation of images as center or spread which i can use, to get the best optical impression for the user.

Best regards from blackwood forrest:-)

Eckhard

2

Hi Eckhard,

image quality for JPEG images should be set to 80-85%, not 100%. You won’t see a notable difference on most displays. The suffix .jpeg is perfectly valid, as is .jpg, .jpe and even .jfif (although there are some difference regarding the color space of JFIF images, but all four are of MIME type image/jpeg).

As for speeding up GRAV, see this blog post: https://getgrav.org/blog/turbo-charge-grav-with-a-cdn

There are some useful tips, albeit I personally don’t use a CDN.

As a first measure, you could configure Apache to serve static images directly, not through the GRAV PHP handler. I use nginx as a web server, which allows to serve certain parts of the document root such as images by the web server itself, avoiding time-consuming PHP scripts.

Best wishes from Odenwald,

lbc

3

Hallo Stefan,
thanks for your reply and the hint for the work with a cdn. Normal i try to keeps things near by, but maybee i will try this later. I tested a little with my images and this is the result:

Org: 373K

75%: 338K
80%: 357K
81%: 361K
82%: 364K
83%: 372K ==> nearest: unix:> ls -alh file.jpeg in cache
84%: 379K
85%: 383K
90%: 429K
100% 833K

I was suprised about the /image folder. After deleting the cache this folder is empty. One initial call of my site brings 173 Files and Folders in /image. Grepping for images brings 32 jpeg Files and all of my images Files were twice in this location. md5sum tells me, that these duplicated files in cache are the same, but never identical with my original File.

OK, best thing is in my sight: Never change the Number 85% :slight_smile:

Best Regards

Eckhard

4

I often reduce JPEG image quality down to 60% even for printed manuals. Best reduction factor always depends on the image itself, so 85% is a good measure for the average images, but you could compress the images often much more to save space.

The cache is for caching, so files appear and disappear there. However, I prefer to use direct access to static files together with a webserver-based cache in NGINX. This outperforms GRAV’s caching mechanism in terms of speed (but it’s no wonder since the webserver uses much fewer syscalls to send static content over the wire).

As for the blog post re CDN: I don’t use CDNs, too, mainly because our website is only interesting for german people and our high-speed server already is only a few hops away from the DE-CIX exchange, so CDNs provide not that much advantage in our case.

But there are a few more tips for speeding up GRAV in this post (below the CDN stuff), which are worth reading.

5

Hi @Eckhard
I’ve recently found the same issue. I optimise my images before uploading, I uploaded a 15k png and a 2mb png came out! After doing some digging it looks like an issue with the Gregwar image library and not Grav directly - see https://github.com/Gregwar/Image/issues/115. Sadly the fix never got merged.

The only solution is to disable the Grav image caching as its not possible to just cache but not do image manipulations (which inflate the image size). While this loads the images directly (and hopefully faster) you miss out on the caching and I find CloudFlare doesn’t seem cache these direct images either. Also I’d assume this would disable image manipulation on any other images you might have.

6

Hello Jared,
thanks for your answer and link. Its a good feeling (for a newbie like me even more) when youre not alone with your discovery, in this case the image growing. In my case it´s over at the moment:

  • Image preparing at home
  • 85% unchanged in Backend
  • hope the best (and get your site running because i have heard that content is king and pictures are only helpful with design and so on:-)
    but:
    i will test my site again next week with disabling img-caching inside of grav: no risk no fun and at the moment maybee 10 Persons worldwide knows baiersbronn.jetzt, so i can play :slight_smile: This is because i will follow the hint from Stefan with optimaztion speed, maybee with or without CDN. In my case i have a 3 MBits Internet Connection (Germany is great with forgetting people living not in big cities) and the loading of the page with empty cache is about 21 Seconds. Google page speed says “ugly” to this and i confirm. OK, i will keep you updated, but i can take a few days.

Happy and blessed Easter

Thanks and goodby

Eckhard

7

Hej Eckhard, did you test your site without the img-caching? Would be nice to know what happend. :slight_smile:

Christian