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 understand:)

Thanks

Here are the logs
First Test
Last test

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).

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 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?

[hr]

Thanks again:) great help pmeenan!
question: is there any downside to enable keep alive?

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).

@pmeenan Thanks for your reply, very much appreciated! if you don’t mind… I have few more questions;)
[list=1]
[]How does ‘enabling keep alive’ help with spped
[
]what does the ‘apache traffic server’ do
[]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)
[
]any downside of installing the apache traffic server
[/list]

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

Joel

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

Thanks so much Pat You’re the best:)

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

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

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

Either one could cause the first byte time to be longer but not as a function of the optimization itself, it’s a symptom that is showing other issues.

The keep-alives (even at 2 seconds) could easily cause the first byte time to extend if your apache server is maxing out on the number of clients it can run. New requests would wait for a client to free up (and it would only free up after the 2 seconds of keep-alive). This is the main reason I recommend using a reverse proxy in front of apache - the apache clients will only be tied up when they are actually executing code. To get visibility into this you’d need to look at the apache status (if you have mod_status enabled). You can buy some time by increasing the number of clients but only if the server has the cpu and ram to support it.

Gzip could cause the times to be longer if your server is running hot on CPU or if the data is sent in bursts (with the first chunk being to small for the compressor to process).

My bet is on the keep-alives and your apache clients.

Hi Pat,

Where can one learn how to install/use the Apache traffic server, the pros and cons of using it (besides here in the forum…) ?

Thanks:)

Here is it’s official home: http://trafficserver.apache.org/

There are also several mailing lists listed on the page.

can apache trafficserver be installed only on a dedicated server?

Thanks

No, but it depends on what you are talking about. It can be installed on the same server as a website (though the website would have to be configured to listen on a different port). As long as you have rights to install software you can do it (VPS or dedicated server). You wouldn’t be able to install it on a Shared server though.