Parts of Your Site That Live on Someone Else's Servers

Tuesday's outage

On Tuesday, a large cloud storage service in the United States had an outage lasting several hours, and a great many websites lost images, forms and scripts along with it.

Most of their owners had no idea any part of their site lived elsewhere. Their own hosting was running normally. Their pages simply arrived incomplete.

A page is assembled in the visitor's browser from many sources. Your server sends the page itself, and the page then asks other servers for fonts, scripts, images, maps and widgets.

Any of those can fail. This week showed that even the largest can, all at once, for hours.

What usually lives elsewhere

• Fonts, loaded from a font service.
• Scripts, such as common libraries from public servers.
• Images and files, kept in cloud storage to save hosting space.
• Forms and booking calendars, embedded from the provider that runs them.
• Maps, videos and social feeds, shown in frames.
• Tracking and advertising tags, which load quietly in the background.

The fourth is the one that costs enquiries. When an embedded form or booking calendar fails, the page around it looks normal, and the business has no idea anyone tried.

Failing fast and hanging

An outside file that fails quickly costs little. The browser notes the error and moves on, leaving a gap where an image or a feed should be.

A file that hangs is worse. Browsers wait for stylesheets, and for scripts placed in the head of a page, before showing anything, so one slow server can hold a whole page blank.

Fonts have their own version of this. Some browsers hide the text for a few seconds while they wait for a font, then fall back to a standard one.

So the same outage can leave one site with a missing photograph and another looking broken, depending on how each loads its outside files.

Making the list

Open your home page in Chrome, bring up the developer tools (F12 on a Windows computer), switch to the Network tab and reload. Every file the page asks for is listed, with the address it came from.

Anything not from your own domain is an outside dependency. Write each one down: what it is, who provides it, and which pages use it.

Repeat for the contact page, any booking page and any page with a form, since those often carry dependencies the home page does not.

If that sounds tedious, it is a short job for your web developer, who can also tell you why each one is there.

Sort by what breaks

For each outside service, ask one question: if it went down for an afternoon, what would a visitor see?

Some failures stop the page appearing. Some stop enquiries or bookings. Some make the page look wrong, and some nobody would notice at all.

Only the first two groups need action. A missing social feed is untidy; a missing quote form is lost business.

A worked example

An Ethiopian restaurant with a busy weekend dinner trade has a site with its menu, a reservation calendar and photographs of its shared platters.

On Tuesday the menu page showed empty boxes and the reservation calendar spun without loading. The owner assumed the site had been hacked and phoned the designer.

The hosting was fine. The designer had stored the site's images in a cloud storage account to keep the hosting small, and the reservation calendar came from a booking service that was having its own trouble that day.

Worse, the menu itself was a set of images of the printed menu. For several hours, the site had no menu at all.

The fix took a day. The menu became text on the page, the photographs moved onto the site's own hosting, and the phone number now sits beside the calendar with a line saying bookings are taken by phone too.

The designer also wrote a one-page list of every outside service the site uses and what a visitor would see if each failed.

Forms and bookings come first

An embedded form can fail in two ways: it does not appear, or it appears and quietly fails to send. The second is worse, because the visitor thinks they have reached you.

Put your phone number and email address in plain text beside every embedded form and booking calendar, so a visitor always has another way in.

Make sure the form service emails you a copy of each submission, and send a test enquiry every week or two. Nobody else will notice when it stops.

Bring the important files home

Fonts and common scripts can usually be served from your own hosting, as long as the licence allows. The page then depends on one server instead of three.

Images belong with the site unless there is a strong reason otherwise. Cloud storage suits large file libraries, and a small business site rarely has one.

What has to stay outside, a booking system or a payment page for instance, can be loaded so it cannot hold up the rest, usually by letting the page appear first and the widget follow.

Accounts and who pays for them

Every outside service has an account somewhere: a login, an email address and often a card that pays for it.

A booking widget whose card expired stops as surely as one whose provider has an outage, and much less visibly.

Add each service to the list with its login owner and renewal date, the same way you would list the logins to your hosting.

The counter-case

Outside services are not the enemy. A large provider is usually more reliable than a small server, and booking or payment systems do work your site should not do itself.

A site with three dependencies, all of them cosmetic, can reasonably leave things as they are.

The aim is not to rebuild everything in-house. It is to know what you depend on, to have a fallback where enquiries are at stake, and to keep the critical files close.

Make the list, sort it by what breaks, and fix the top of it first.

Before the next outage

1. Load your main pages with the Network tab open.
2. List every outside address you find.
3. Note what each one does and who provides it.
4. Mark the ones that would stop enquiries.
5. Add your phone number beside every embedded form.
6. Serve fonts and scripts from your own hosting.
7. Record logins and renewal dates for each service.

Step four decides where the effort goes. A missing font costs nothing, while a booking calendar that fails on a Friday afternoon costs a weekend of tables.

The same inventory habit, applied to logins, is covered in FTP accounts nobody remembers creating.

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.