Add keep-alive-header via .htaccess

[drublic]

I stumbled over keep-alive a view times lately while checking Google Page-Speed for some advice for a specific project.

Keep-alive is an HTTP feature which allows the server to send multiple requests through one TCP-connection as far as I understood. This improves performance up to 50% according to the Apache config docu. @getify states in #28 that a connection with keep-alive may be 20-30% faster.

From my experience and this SO question it seems like the HTTP header is set in a server-configuration and you can't change it easily via .htaccess.

Today I found this new answer on the SO question from above which describes that it is possible to use Header set Connection keep-alive in the .htaccess to control the behavior of this.
This works for me. I've tested this in two projects now, one of them is my blog. The request-header "Connection" is set to "keep-alive" now and Google Page-Speed does not show this anymore as "to be done". Here is a screenshot of the headers.

I'd suggest adding this to the .htaccess file as it seems to improve performance and I've not encountered any problem with setting this header.

Looking forward to your feedback!

[mathiasbynens]

From https://www.vbulletin.com/forum/showthread.php/377255-To-keep-alive-or-not-to-keep-alive-that-is-the-question?p=2143425&viewfull=1#post2143425:

There is no easy answer to the question as it depends on your workload: If you have a lot of clients requesting several resources during a certain timeframe is is usually better to have keepalive turned on to get rid of the overhead for establishing TCP connections. But if your clients request only a few resources it is better to have keep-alive turned off to free workers immediately. Rule of Thumb:

• Keep-Alive off for backend servers
• Keep-Alive off for frontend servers
• Keep-Alive on for static content servers

[drublic]

I found some similar statements like this one which summarizes the advantages and disadvantages pretty good I think.

Maybe it's not useful for everyone to include Keep-Alive by default but to have it as an opt-in.

I wonder what the reason for Google Page Speed is to include it as a recommendation; they don't provide further information from what I have seen.

[paulirish]

this could be enabled for just image/js/css assets maybe?

[drublic]

You think it's ok to have it turned on for every site that uses HTML5 BP even with the problems mentioned?
I have no idea what the problems mean in reality for a standard hosting package. If this is something that is bad for most pages that are driven by HTML BP I'd not include Keep-Alive for static resources by default.
On my blog I didn't notice any problems with including Keep-Alive yet.

[paulirish]

@guypod @stoyan what do you think?

[guypod]

I am strongly in favor of turning on keep-alive, even by default. Here are some key reasons why.

1. TCP Connect is expensive. There are many stats which are more data-backed out there, but even a quick test on WebPageTest shows an average connect time of 100ms for Cable speed with 28ms latency. Adding 100ms to the time to fetch every resource is a lot, even if some of those are happening in parallel.

2. On Mobile networks, TCP Connect is even more expensive. The same test from above, but slightly modified to use a 200ms latency connection raised the average connect time to 234ms. That's a lot of time.

3. Keep-Alive is required for the use of HTTP Pipelining. Most mobile browsers use HTTP Pipelining, and it looks like Chrome will enable it by default soon. Clearly the data these browser makers have indicates piping requests is good, and closing the connection each time will take away that value.

4. As @safruti recently reminded me, not knowing your content length (e.g. when gzipping content) does not require closing the connection if you use chunked encoding. So perhaps changing .htaccess should come with some other changes to enable chunked encoding if it's not already on...

So while there are a few downsides to using keep-alive, I would absolutely recommend using it, as I think its value outweighs its limitations. I don't know enough about what deployments of HTML5 BP look like to be certain about turning it on by default, but I would bias in favor of doing so.

[vendruscolo]

We can also add a timeout to Keep-Alive, so that the server closes the connection after a certain time.

[tchalvak]

I already use keep-alive pretty-much everywhere, though I can imagine this being a surprise for people who weren't expecting this kind of configuration alteration. I think that keep-alive should definitely have a time-out config go with it, if it does go in.

[necolas]

cc @h5bp/server-configs

[sstok]

KeepAlive Directive can only be configured in the section at max.
https://httpd.apache.org/docs/2.2/mod/core.html

Does changing the header 'alone' work completely?

And we must make sure its only enabled for 'capable' browsers as some don't work properly with this.

[syslogic]

If you intend add that KeepAlive directive ... it should be wrapped with a IfModule directive.

Else it will certainly throw an HTTP500 in case mod_headers is absent on the box.

Not that I would be aware of any browsers not supporting it (besides .htaccess can't detect any browsers).

So how you suggest to ensure this?

I honestly see no way ... this simply isn't PHP so no access to browsecap.ini (if even installed).

IE6 must die.

[reecekol]

was any decision made on this ?

[drublic]

Not yet. This should be on hold until .htaccess is moved to the h5bp/server-configs repo. Please see h5bp/server-configs#59.

[necolas]

Issue moved to h5bp/server-configs#107 following the migration of development of the .htaccess to the @h5bp/server-configs team

[thesogafoi]

hey guys

i access to .htaccess but when i check my keepalive ( From There ) this tell me your connection is close :| why i cannot enable this from my htaccess file

i used this code too

<ifModule mod_headers.c> Header set Connection keep-alive </ifModule>

but still does not work

[roblarsen]

@thesogafoi 1. Wrong repo. the server configs have their own repos. 2. This is more of a support request than a bug request. Stack Overflow, maybe?