Connections Closed After Every File

One file, one connection

When a browser loads a page, it asks the server for the page itself and then for every file the page uses: images, stylesheets, scripts, fonts. A typical small business page needs dozens of them.

Before any file can be sent, the browser and server open a connection, a short exchange of messages to establish contact. A secure site adds a second exchange to set up the encryption.

A well-configured server keeps that connection open and sends file after file down it. Some servers close it after every file, so the browser has to start again for the next one.

Each fresh start costs time on any network. On a phone it costs much more.

Why phones pay the most

The cost of a new connection is mostly waiting. Messages have to travel to the server and back before anything useful is sent, and that round trip is far slower on a mobile network than on office broadband.

A new connection also starts cautiously and speeds up as it goes. One used for a single small image and then closed never gets up to speed.

Browsers soften this by opening several connections to the same server at once, typically six. With keep-alive off, those six are used once each and replaced, over and over, until the page is complete.

What keep-alive means

• Keep-alive lets one connection carry many files, one after another.
• Persistent connections is the formal name for the same thing.
• The server decides whether connections stay open, and for how long.
• Crowded shared servers sometimes have it switched off to save memory.
• Your host's setting covers your own files; other companies' servers set their own.

The fourth explains how sites end up without it. Holding connections open uses memory, and switching keep-alive off was once a common way to fit more accounts onto one machine.

How WebPageTest shows it

WebPageTest, a free testing site, opens your page in a real browser in a city you pick and records what happened. Use the city nearest your customers and a mobile connection speed.

Across the top of the results is a row of letter grades. One is labelled Keep-alive Enabled, and an F there means connections are being closed that should stay open.

The waterfall chart below shows each file as a bar. An orange segment for the initial connection at the start of nearly every bar, rather than only the first few, tells the same story.

The grade covers every server the page uses, not only yours.

If the failures are all on files from another company, such as an old visitor counter or a widget, the host cannot fix them. Remove or replace that piece instead.

Asking the host

On shared hosting, keep-alive is set in the server's own configuration, which only the host can change.

Ask plainly whether keep-alive is enabled on your server, and if not, whether it can be, or whether your account can move to a server where it is. Attach the WebPageTest result.

Some guides suggest a line in the site's .htaccess file that adds a keep-alive header. That changes what the server says about the connection, not what it does with it.

If the host says it cannot be enabled on your plan, that is worth knowing: a server tuned that way is often old or crowded in other respects too.

A worked example

An ice sculptor carves pieces for weddings, corporate parties and winter festivals, working from a cold room in an industrial unit. The website's gallery shows several dozen thumbnails of past work, each opening a larger photo.

Event planners and couples often browse the gallery on a phone between appointments, and on a phone it filled in slowly, a few pictures at a time.

WebPageTest gave the site an F for keep-alive. The waterfall showed a new connection being set up before almost every thumbnail, each adding a round trip before any of the picture arrived.

The site sat on an older shared server where the host had switched keep-alive off. The sculptor's web developer sent the host the test result and asked for a move to a current server, which took a day.

The retest showed an A, with new connections only at the start of the waterfall. The gallery now fills in steadily on a phone, and nothing on the site itself had to change.

Checking that it took effect

After the host makes the change, run WebPageTest again from the same location and connection speed, so the two results can be compared.

The Keep-alive Enabled grade should now read A, and the waterfall should show connection setup only on the first few requests to your server.

For a second check, open the browser's developer tools, reload the page and look at the response headers for any image. A header reading Connection: close means it is still off.

Fewer files still helps

Keep-alive makes each file cheaper to fetch. It does not make files free.

A page with eighty files still makes eighty requests, even down open connections. Combining small scripts and stylesheets, removing ones nothing uses and sizing images properly reduces the count and the weight together.

The order is simple: switch keep-alive on, because it costs nothing, then reduce what the page asks for.

Where HTTP/2 fits

HTTP/2, published as a standard in May, lets a browser fetch many files at once over a single connection. Current browsers support it on secure sites.

Server software is only starting to support it, and few hosts offer it yet, so for now keep-alive still decides how connections are used.

The counter-case

Keep-alive matters most on pages with many files, viewed over slow or distant connections. A plain page with a handful of files gains little from it.

Holding connections open does use server memory, so some caution from a host is reasonable, provided connections are held for a few seconds rather than closed after every file.

A page slowed by a sluggish server or heavy images will still be slow with keep-alive on. The time is being lost elsewhere.

Even so, it is a free setting, it helps every visitor on a phone, and asking the host takes one email.

This week

1. Run WebPageTest on your home page at mobile speed.
2. Read the keep-alive grade first.
3. Check the waterfall for repeated connection setup.
4. Note which servers the failing files come from.
5. Email your host with the result attached.
6. Retest after the change from the same location.
7. Remove widgets whose servers close every connection.

Step five is the one that fixes it. The setting lives on the host's side, and an email with the test attached gets a straight answer fastest.

Telling the browser to keep those files for later visits is covered in files the browser downloads again on every page.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.