Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Pagespeed and render-blocking CSS
philwareham wrote #289872:
in latest Photoshop (CC 2015) the 55 quality is perfectly good enough
And for those paupers like me who use Photoshop twice a year and thus still have real installable software (CS5) as it’s good enough…do you know if they’ve changed the filters in recent versions? e.g. 55% in CC2015 is equivalent to, like, 75% in CS5 or something? Or has 55% always been acceptable and I’ve been over-saving all these years?
Must admit I tend to use Save For Web set two or three notches from the top and never really noticed much degradation. But my images aren’t exactly world class anyway so it doesn’t really matter to me.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Pagespeed and render-blocking CSS
monkeyninja wrote #289881:
Out of interest how do you deal with delivering user uploaded images? We often have to resize images uploaded by users on the server (currently using GD but I’m pushing the use of ImageMagick as it seems to be faster and more capable). 55% quality is often poor when resized this way so we’ve had to up the quality to ~85%.
That is a problem, for sure. The artefact quality produced by GD and ImageMagick is quite horrific. I used 75 as a base on client sites in the past but luckily on my own site I can control the image quality myself. There may be something in using retina images with lower compression, as detailed by The Filament Group – I’ve not done a client site using that method yet but I’m keen to try it out.
Offline
Re: Pagespeed and render-blocking CSS
Bloke wrote #289883:
do you know if they’ve changed the filters in recent versions? e.g. 55% in cc2015 is equivalent to, like, 75% in CS5 or something? Or has 55% always been acceptable and I’ve been over-saving all these years?
It seems to have improved in quality recently, but I’m not really sure. As I say, I used to routinely use 75 quality setting in PS but after getting bad scores on WebPagetest I followed their recommendation of an A grade being within 10% of 50% (which means 55% in truth), and it seems to look fine.
Offline
Re: Pagespeed and render-blocking CSS
maniqui wrote #289871:
Does it really affect performance severely, even if loaded at the very bottom?
If you load analytics asynchronously after everything else, hell no; how could it. The default setup includes loading a lightweight 16 kB JavaScript file (ga.js which doesn’t run anything crazy on its own), does a cross-domain request using an image when the actual tracking action is initialized, and ends up creating few small cookies.
Performance-wise it doesn’t affect your users’ experience. Altho, the requests may take a while to complete but that doesn’t matter if the request is asynchronous.
Offline
Re: Pagespeed and render-blocking CSS
philwareham wrote #289884:
That is a problem, for sure. The artefact quality produced by GD and ImageMagick is quite horrific. I used 75 as a base on client sites in the past but luckily on my own site I can control the image quality myself. There may be something in using retina images with lower compression, as detailed by The Filament Group – I’ve not done a client site using that method yet but I’m keen to try it out.
Images have to be one of the biggest problems for web performance these days more so than any other assets. It is hard to avoid the web performance hit generated by poorly optimised images being uploaded by a user on many sites.
Offline
Re: Pagespeed and render-blocking CSS
monkeyninja wrote #289880:
The result of politicians meddling with things they don’t get (again)!
They should just outlaw this ‘internet’ thing, if you ask me. I’ve heard it’s infested with horrible things and influences violent behavior in our innocent children!
Offline
Re: Pagespeed and render-blocking CSS
Lots of interesting pagespeed tools here. Are you all Base64-ing your above-fold images?
Offline
Re: Pagespeed and render-blocking CSS
About images compression, this post is interesting as it shows that high compression level can allow you to save larger images which can also work with retina display.
Last edited by NicolasGraph (2015-04-10 16:55:24)
Offline
Re: Pagespeed and render-blocking CSS
zero wrote #289890:
Are you all Base64-ing your above-fold images?
No, we are not. Not now, not ever hopefully. For exactly the same reasons we are not inlining our above-the-fold CSS – it’s of dubious benefit and takes a lot of legwork to achieve. I’m fairly happy with a 233ms page load time without those 2 techniques…
The 4 points dropped are because of CloudFlare’s cookie. If I turn off CloudFlare I get 100 score but a 50% slower page render, so I’m willing to take the shame of a non-perfect score.
Bear in mind that if you do inline above the fold CSS on one page, chances are you’ll have to inline some entirely different CSS on the next page of your site, and the next, etc. That is unless your above the fold content is identical across your whole site, which I doubt.
Offline
Offline
Re: Pagespeed and render-blocking CSS
I’m waiting for an upcoming update to mod_pagespeed (or update to ngx_pagespeed if I go over to nginx) that rewrites JPEG to WebP when using img srcset. At the moment the feature blows mod_pagespeeds mind (it only writes standard img src to WebP right now). Once I have that I can reduce the page size in Chrome/Firefox by around 200kb. Happy days!
Offline
Re: Pagespeed and render-blocking CSS
philwareham wrote #289864:
Also, don’t use Drupal. For anything. That’s probably my first performance tip.
+1.
Offline