This page is an evaluation of this website:

Abandoned & Little-Known Airfields

This marvelous website, popular with aviation enthusiasts, documents the over 2,500 airfields in the United States that have been abandoned and/or forgotten. There are almost 30,000 photos that document these forgotten airfields along with eyewitness accounts provided by many of the website's visitors. But beneath that exceptional content is coding from the early 2000s. Much of that coding has since become deprecated and we can't expect browsers to continue support forever.

Expecting browsers to continue to support our ancient and deprecated coding contributes to browser bloat, which impacts browser performance and security.

For this website, it's Open Office that's producing these ancient pages—a word processor that's a very poor web development tool. It's only advantage is the website owner's familiarity with it.

To make a case for bringing the site's coding up-to-date, we converted a portion of the site as a demonstration. The result was code size reduced by well over half. Resizing images and converting to lighter-weight image formats reduced them by up to 80 percent of their original size. Additionally, the demo pages are mobile-friendly—the original site ignores mobile device issues, allowing major portions of images to be off-screen and text to be unreadable.

This website's pages are all identical in format. Pages have images with captions and supporting paragraphs of text. A templating system could be created that takes images and text and automatically builds web pages from them.


Web server Microsoft IIS /8.0
Service provider Go Daddy
Size of site 3 GB
Number of HTML files 399
Number of JPG files 29,042
Number of PNG files 1
Number of GIF files 34
Number of image sizes* 27,053
Web development Open Office 4.1.3

* Out of over 29,000 images on the website, there are 27,053 image sizes (geometries). There's no effort to establish standard image sizes.


The website only runs HTTP. This is a problem for two important reasons. The first is that there are links for donating money. Most people won't do that with an unsecured Internet connection—or they shouldn't. The second is that Internet search engines tend to rank non-HTTPS sites poorly. Our suggestion is to move the site to a HTTPS server.

Given that the web server used is Microsoft IIS and it can be difficult to adapt free Let's Encrypt certificates to IIS, it may be the cost of commercial certificates and in configuring IIS that's keeping this site HTTP-only. Perhaps this article may help:

Using Let's Encrypt with IIS on Windows

Browser compatibility
The site uses outdated HTML code (circa early-2000s). HTML tags and attributes are used that have been deprecated years ago. Future web browser versions may not render the site's webpages as desired. Our suggestion is to update the HTML to version 5.
High bandwidth
The site's outdated HTML code and lack of Cascading Style Sheet support results in styling defined in individual elements. The result is huge page size.

Images are typically much larger than they need to be, resulting in high bandwidth usage. They are mostly in JPG format and there's no effort to establish common image sizes for consistency. Images are kept in the size that contributors' submit.

Our suggestion is to switch to HTML5 and use CSS3. Use more efficient image formats, such as WEBP, to reduce image size substantially, save bandwidth, and reduce page loadtimes.
Mobile unfriendly
The site does not handle mobile devices (with screens smaller than desktop computers) well. In many cases, images are partially off-screen with no way to see entire images.

Given the use of ancient HTML code, there's no facility to adapt image sizes to screen sizes. Sending an image that's, say, 2000 pixels wide when the mobile device can render less than 600 pixels across is a waste.

Our suggestion is to create images sized for popular screen sizes, update to HTML5, and use media queries.
Large pages
Each webpage displays a collection of airfields ranging from two to about twenty. Each airfield typically has several photos and illustrations. The amount of data moved from the web server to the web browser is large. If the user is interested in viewing only one airfield, there's substantial wasted bandwidth.

Our suggestion is to have one-airfield-per-page and re-engineer how airfields are listed and found.
No Search
There seems to be no ability to search for airfields by name or other criteria. You simply must know where it is. You first go to the state page. Most states are divided into areas, so you'll need to have a rough idea of where the little-known airfield is located. Once you load the correct page, there's a list of airfields across the top of the page.

Our suggestion is to add a search facility and a better way of listing airfields.
No support for mobile devices
There is no support for mobile devices. None. Nada. The screenshot below shows what a typical page looks like on an iPhone X. The vast differences in image sizes causes the phone to squish down the text to where it's unreadable for most people. You'd have to constantly pinch/unpinch and swipe the screen to try to follow along.
Freeman webpage on an iPhone


To demonstrate what it would be like to solve the above-mentioned problems, we wrote scripts to convert the site's pages to HTML5, CSS3, and a minimum of Javascript. The scripts also resize images to consistent sizes and convert them to WEBP format. The open source software used to do the conversion are awk, sed, tidy, and Imagemagick called by bash scripts.

We decided to use one airfield per webpage instead of combining many into one as the current site does. Each of our individual airfield pages loads in about 0.4 seconds on the first load and 0.05 seconds on subsequent loads. The website's own combined pages takes about 11 seconds for the first load and about 0.8 seconds for subsequent loads. User's don't normally see the large delay on the first page load. They see the first screenful appear quickly and don't notice that the remainder of the page is still loading.

W3C HTML Check

Checking the website's pages with the W3C HTML Checker dispays several hundred errors before giving up with “Fatal Error: Too many messages.”.

Our demo pages had no errors or warnings.

Lighthouse evaluation

Lighthouse is a webpage evaluation tool that rates four categories of webpage “goodness” and displays a graphical dashboard of results. Here's the evaluation of the combined webpage:

Lighthouse results for Alaska combined page

Here's the evaluation of the demo page:

Lighthouse results for Alaska combined page

The Performance category doesn't depend on the number of images or their size, thus the existing webpages are not penalized for their bloat. The demo page has a smaller performance number only because it doesn't declare a width and height for images. This is deliberate. The images scale to the viewport, thus image width and height change with the size of the browser window. Lighthouse (incorrectly, we think) sees this as a quality/performance issue. The demo pages take a hit in the Lighthouse score because of it but easily outperforms the combined page.

This brings us to these words of wisdom: “Never do anything to degrade your webpage simply to improve your Lighthouse score.”

— END —