A Weather Box That Holds Up the Whole Page

Every page waits for the weather

A golf course's site shows the temperature and conditions in a small box at the top of every page, beside the tee time link. On most days nobody gives it a thought.

On a Saturday morning, the outside weather service slows down. Every page on the course's site, the tee times and the contact page included, now takes twenty seconds or more to appear.

Golfers checking before they drive out see a blank screen. Some decide the site is broken; some decide the course is closed.

Why one small box holds up everything

Most sites build each page on the server before sending it. When a page includes a box filled from another company's server, the site sends a request there and waits.

The page cannot be sent until the answer arrives or the site gives up, which, depending on how the box was written, can take a few seconds or a full minute.

So a delay at the weather company becomes a delay on every page you own, including pages with nothing to do with weather.

What asking on every visit costs

Asking the service each time someone opens a page is the simplest way to write the box. It also creates several problems at once:

• Every delay at the other end becomes a delay on your pages.
• An outage becomes your outage, with pages that hang or show an error.
• Usage limits run out. Many services cap requests per key per day, and a busy day can use them up.
• Search engines wait too, since a crawler fetching pages meets the same delays.
• The answer barely changes. The site asks hundreds of times for a reading taken once.

The last point is the waste at the heart of it. Weather stations commonly report once an hour, so most requests get the reading the previous visitor got.

Fetching on a schedule instead

The alternative is to fetch the weather on a timer rather than on demand. A scheduled task on the server asks the service every thirty minutes and saves the answer.

Pages then read the saved copy, which sits on the same server and costs almost no time. The service is asked as often on a quiet Tuesday as on a holiday weekend.

If a fetch fails, the task tries again at the next interval, and nobody browsing the site waits while it does.

How long a reading can be kept

Current conditions stay useful for thirty to sixty minutes, which matches how often most stations report. A forecast changes a few times a day, so a copy two or three hours old is still sound.

Show the time of the reading in the box: 18 degrees, light cloud, at 9:30. Visitors can judge it for themselves, and nobody is misled by a reading that quietly went stale.

Data that changes slowly, such as sunrise and sunset times, can be kept for a whole day.

A worked example

A bison ranch in the Interior sells meat from its farm store and runs wagon tours of the herd on summer weekends, booked online. Every page showed current conditions and a weekend forecast.

On the first hot weekend of the season, visitors told the ranch the site took half a minute to load, and the booking page timed out for people trying to reserve a tour.

The box asked the weather service on every page view, with no limit on how long to wait, and on busy days the ranch's key ran out of requests by mid-afternoon.

Now a scheduled task fetches the weather every thirty minutes and saves it, giving up after three seconds if the service is slow. Pages read the saved copy, with the time shown.

If the saved reading is over three hours old, a link to a full forecast replaces the box. Since no page waits on the service, a slow day there never reaches the booking page.

When the service is down

Plan for the outside service failing, because at some point it will. The question is what visitors see when it does.

Within a reasonable age, show the last saved reading with its time. Beyond that, remove the box or show one plain line linking to a forecast, never an error message or an empty frame.

Set a short time limit on the fetch itself, two or three seconds, so a slow service cannot tie up the scheduled task either.

Loading the box after the page

Another approach sends the page first and lets the visitor's browser fetch the weather afterwards with a small script. The page appears at once, and the box fills in when the answer arrives.

That removes the wait, but every visitor still asks the service, so usage limits still apply, and the service key sits in the page code for anyone to copy.

Combining the two avoids both problems: a scheduled fetch on the server, and a page that loads the saved copy after everything else.

Other boxes with the same habit

Weather is the obvious case, but anything fetched from another company's server can do the same: a feed of recent tweets, a review badge, an events calendar, availability from a booking system.

Each deserves the same test. Ask what happens to the page if that service takes thirty seconds to answer, and whether every visitor really needs a fresh copy.

The counter-case

Some outside content cannot be saved ahead of time. Live tee time availability has to be current when someone books, and the booking system will always ask its own server.

The answer there is to keep the live part on the page where it is needed, behind a link or a button, rather than on every page of the site.

A box that needs live data is fine where it lives. A box showing every visitor the same reading for an hour has no reason to make them wait.

Fixing the box

1. List every box filled from an outside service.
2. Find out how each one is fetched today.
3. Move the weather fetch to a scheduled task.
4. Save each reading with the time it was taken.
5. Set a time limit of a few seconds on every fetch.
6. Decide what shows when the copy is too old.
7. Test the site with the service switched off.

Step seven is the proof. On a copy of the site, point the box at an address that never answers, and every page should still appear at its normal speed.

The same wait on other companies' servers can slow the admin screens staff use to keep the site current, as a WordPress dashboard that takes a minute to open explains.

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.