Current time: 11-22-2019, 01:15 PM Hello There, Guest! (LoginRegister)

Post Reply 
 
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
B on Compress Images before compress C after compress
08-31-2011, 05:11 AM
Post: #1
B on Compress Images before compress C after compress
Hi all,

I ran several tests before and made improvements accordingly, one of the things I did is lossless compression of images using smushit but interesting I went from B to C on image compression.
(Also the suggestions shows some images that can still be compressed but when using smushit it says there nothing to do)

Please help me understandSmile

Thanks

Here are the logs
First Test
Last test
Visit this user's website Find all posts by this user
Quote this message in a reply
08-31-2011, 06:37 AM
Post: #2
RE: B on Compress Images before compress C after compress
WebPagetest's image compression check is for lossy compression and just checks jpeg images. Tools like smushit will only do lossless optimizations on images so if you save a jpeg at a high quality level they will not be able to make it smaller (even though the files can usually be SIGNIFICANTLY smaller by reducing the quality without visually making the images appear worse).
Visit this user's website Find all posts by this user
Quote this message in a reply
08-31-2011, 06:39 AM
Post: #3
RE: B on Compress Images before compress C after compress
Yikes, just checked the test result. RUN and figure out how to enable persistent connections. You will cut your page load time close to 50% just by enabling them. If you can't do it because of the hosting provider you are on there are services (like cloudflare) that are free that will get around the problem.
Visit this user's website Find all posts by this user
Quote this message in a reply
08-31-2011, 12:36 PM (This post was last modified: 08-31-2011 12:40 PM by Joel.)
Post: #4
RE: B on Compress Images before compress C after compress
(08-31-2011 06:37 AM)pmeenan Wrote:  WebPagetest's image compression check is for lossy compression and just checks jpeg images. Tools like smushit will only do lossless optimizations on images so if you save a jpeg at a high quality level they will not be able to make it smaller (even though the files can usually be SIGNIFICANTLY smaller by reducing the quality without visually making the images appear worse).
Thanks for the info! I believe I can go ahead and change jpeg images to png and compress it, right?
however this only answers part of my question, main question was; how come without doing anything it was B and later went down to C?


(08-31-2011 06:39 AM)pmeenan Wrote:  Yikes, just checked the test result. RUN and figure out how to enable persistent connections. You will cut your page load time close to 50% just by enabling them. If you can't do it because of the hosting provider you are on there are services (like cloudflare) that are free that will get around the problem.

Thanks againSmile great help pmeenan!
question: is there any downside to enable keep alive?
Visit this user's website Find all posts by this user
Quote this message in a reply
08-31-2011, 09:05 PM
Post: #5
RE: B on Compress Images before compress C after compress
NOOOOOooooooooooo !!!!! DO NOT convert the jpeg's to png's - they will get a LOT bigger. Just re-save the jpeg images with a lower quality setting (experiment to see how low you can go and keep the image looking good).

The only downside to enabling keep alives is you need to make sure your server can handle the connections. Tuning the keep alive time relatively short will help (10-15 seconds) but if you are running apache's prefork mpm it is still reasy to run out of connections (what I'll usually do in that case is run nginx or apache traffic server in front of the apache instance to terminate the connections).
Visit this user's website Find all posts by this user
Quote this message in a reply
09-09-2011, 07:23 AM
Post: #6
RE: B on Compress Images before compress C after compress
@pmeenan Thanks for your reply, very much appreciated! if you don't mind... I have few more questionsWink
  1. How does 'enabling keep alive' help with spped
  2. what does the 'apache traffic server' do
  3. if the apache traffic server will terminate the connections what will still be the benefit, (of course the answer on question 1 will explain this too)
  4. any downside of installing the apache traffic server

Thanks very much in advance, before I ask my developer to do this kind of things I wanna know the stuff a littleSmile

Joel
Visit this user's website Find all posts by this user
Quote this message in a reply
09-09-2011, 08:54 AM
Post: #7
RE: B on Compress Images before compress C after compress
1 - The expensive part of loading a web page is usually in the round trips from a user's browser to the web server (not downloading the actual content). With keep alive's enabled, the browser makes one round trip to set up the connection and then it can download each resource with one more round trip each. Without them the browser has to make an additional round trip for every request to set up a new connection. You can usually cut the page load time in half by enabling it.

2 - Apache traffic server is a proxy that logically sits in front of your web server. It can handle a huge number of connections without breaking a sweat (and even cache your static responses). It then can send the requests to your web server without keep alives (or over a much smaller number of connections) so that your web server doesn't have to deal with all of the browser connections.

3 - It makes it easy to handle a large number of connections that are kept open without having to figure out how to get the web server to do it. Apache - the web server, not traffic server - can be difficult to get to scale well when using php if it terminates the connections directly. It can be done but it's usually easier to just throw a proxy in front of it.

4 - The main issues are that there is added complexity and your web server no longer has direct access to the end user's IP address (if it uses it). The IP address is usually added to a x-forwarded-for header which is common industry practice.

Thanks,

-Pat
Visit this user's website Find all posts by this user
Quote this message in a reply
09-14-2011, 08:00 AM
Post: #8
RE: B on Compress Images before compress C after compress
Thanks so much Pat You're the bestSmile

1 more question on Keep-Alive enabled, I came across this post so my question is if changing the KeepAliveTimeout to 2-3 seconds is a good solution too

Thanks
Visit this user's website Find all posts by this user
Quote this message in a reply
09-14-2011, 08:18 AM
Post: #9
RE: B on Compress Images before compress C after compress
2-3 seconds is a reasonable stop-gap but it's not nearly as effective as a proxy in front of apache that can actually handle a large number of persistent connections. I'd call it workable but not "good".

Thanks,

-Pat
Visit this user's website Find all posts by this user
Quote this message in a reply
09-16-2011, 08:38 AM (This post was last modified: 09-16-2011 08:40 AM by Joel.)
Post: #10
RE: B on Compress Images before compress C after compress
Hi Pat,

our developer enabled keep-alive and set time-out to 2 seconds (I gave him both options; low timeout, or installing apache traffic server) the score is really going up, only problem is comparing results it looks like the time to first byte only got worse.

my question, can it be related to any of the recommended fixes like gzip or keep-alive? and if so what should be my next step

Test log

Thanks
Visit this user's website Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)