In the everyday rush of work and family life it’s easy for personal projects to be neglected. That’s what happened to one of my web sites, which hadn’t been updated since 2010. It had been uploaded to a new web host and just left there, and was showing its age. I decided it was time to update it, and I thought I'd describe the process here.
Some Background
The site is a local history site and the domain was registered in 2001. The original contents had been hosted on my ISP’s customer pages before then. The coding was a mixture of hand-crafted and editor-generated HTML4/4.01/XHTML with CSS styling and some JavaScript. Despite the CSS there were still some in-line style and layout specifications. There was no mobile-friendly version of the site – well there used to be, but it was a very lightweight WAP (Wireless Application Protocol) version. Lightweight because WAP didn’t lend itself to much at all beyond text. On the other hand it looked really cool at the time on a Nokia 7110, and it was quite a useful thing to put on my CV/resumé back then!
The site was updated on a laissez-faire basis for about nine years (it’s a personal site after all!) and then as I moved away from the area its maintenance faded into the background.
I’d always used Google Analytics and Google Web Tools to see what was going on with the site but, like the site updates, I gradually got out of the habit of looking at them.
Turning Point
In 2017 when I started adding more articles to this site, I decided to take a look at the web analytics for my old site as well. They weren’t that impressive – the visitor numbers were pretty constant but Google was complaining about:
Search Appearance / HTML Improvements
An assortment of duplicate and short titles and meta descriptions
Image too wide for page
Search Traffic / Mobile Usability
Viewport not configured
Content not sized to viewport
Small font size
Touch elements too close
Behavior / Site Speed / Speed Suggestions
Eliminate render-blocking JavaScript and CSS in above-the-fold content
Leverage browser caching
Optimize images
Enable compression
Minify JavaScript
Minify CSS
That’s an awful lot of complaining about an awful lot of the site. I decided that it was time to start fixing things.
Where Am I Going?
I wanted to update the site to use modern web markup – HTML5, CSS3 etc. I also wanted a site that would stop Google’s complaints, or at least reduce their number.
You may be wondering why I decided not to just use a regular CMS like the one you’re reading this article on. I thought about it, but then I decided that the site’s quite picture-heavy and there are quite a few pages which would need to be migrated. All of the pages would need to have page redirection set up, because there are a lot of external references to them, so I decided I’d stick with a pure hand-written HTML site for the moment. A useful side effect was that I’d get some HTML5 and CSS3 experience, maybe with some JavaScript too, but that wasn’t a primary consideration. Honestly!
How Will We Get There?
I decided the best way to go about the renovation was to see whether there were any “easy wins”. A few types of change sprang to mind:
- Server changes – what changes can be made to the server to improve the whole site
- Simple HTML5 migrations – easy updates to the existing pages to turn them to HTML5
- Minify JavaScript and CSS files
- Simple mobile usability updates – more easy updates to the existing pages to make them mobile-friendly
My main criterion for each fix was that I should be able to complete it in about half an hour. That would let me do them one at a time, and then upload the latest files after I’d completed each change. There are some other changes I made in response to the warnings from Google, but I’ll cover them in a later article.
Tools
Most of my development work is done on Windows, so I decided to start with a few fairly simple tools:
Notepad++ - Very nice search and replace / regex facility and lots of plug-ins. The search and replace facility handles multiple lines very nicely, which was useful.
Microsoft Visual Studio Code – A cross-platform editor with a better display of all of the files in a directory structure, so useful for a web site. Also plenty of extensions to help with HTML formatting, JavaScript and CSS minimization etc.
W3C Validator – Lets you validate web pages once you’ve uploaded them.
Changing the Server
The following problems are fixed by making changes to the web server:
Behavior / Site Speed / Speed Suggestions
Leverage browser caching
Enable compression
I decided to start with enabling compression, which reduces the amount of data that has to be transferred from the server to the client. My server is a Linux system running Apache and cPanel, so there’s an option under Optimize Website / Compress Content which enables Apache’s mod_deflate. This only does some of the compression though – if your site uses PHP there are some other configurations you need to add to the .htaccess file. After looking around the web I decided to add:
<IfModule mod_deflate.c> AddOutputFilterByType DEFLATE text/plain AddOutputFilterByType DEFLATE text/html AddOutputFilterByType DEFLATE text/xml AddOutputFilterByType DEFLATE text/css AddOutputFilterByType DEFLATE application/xml AddOutputFilterByType DEFLATE application/xhtml+xml AddOutputFilterByType DEFLATE application/rss+xml AddOutputFilterByType DEFLATE application/javascript AddOutputFilterByType DEFLATE application/x-javascript AddOutputFilterByType DEFLATE image/x-icon image/svg+xml AddOutputFilterByType DEFLATE application/vnd.ms-fontobject AddOutputFilterByType DEFLATE application/x-font-ttf AddOutputFilterByType DEFLATE application/x-font-woff AddOutputFilterByType DEFLATE application/font-woff AddOutputFilterByType DEFLATE application/font-woff2 AddOutputFilterByType DEFLATE font/opentype AddOutputFilterByType DEFLATE font/woff2 </IfModule>
Speaking of the .htaccess file, you can enable the caching by adding the following to the file:
# Enable expiration control ExpiresActive On # Default expiration: 1 hour after request ExpiresDefault "now plus 8 days" ExpiresByType text/html "access plus 1 day" ExpiresByType image/gif "access plus 2 weeks" ExpiresByType image/jpeg "access plus 2 weeks" ExpiresByType image/png "access plus 2 weeks" ExpiresByType text/css "access plus 8 days" ExpiresByType text/javascript "access plus 1 week" ExpiresByType application/xml "access plus 1 week" ExpiresByType application/xhtml+xml "access plus 1 week" ExpiresByType application/rss+xml "access plus 1 hour" ExpiresByType application/javascript "access plus 1 week" ExpiresByType application/x-javascript "access plus 1 week" ExpiresByType image/ico "access plus 1 week" ExpiresByType application/vnd.ms-fontobject "access plus 1 week" ExpiresByType application/x-font-ttf "access plus 1 week" ExpiresByType application/x-font-woff "access plus 1 week" ExpiresByType application/font-woff "access plus 1 week" ExpiresByType application/font-woff2 "access plus 1 week" ExpiresByType font/opentype "access plus 1 week" ExpiresByType font/woff2 "access plus 1 week"
N.B. I KNOW the caching module is enabled on my server. If you’re not sure, you can put the code above in a block like:
<IfModule mod_expires.c> ExpiresActive On ExpiresDefault ... ExpiresByType statements </IfModule>
Uploading the updated .htaccess showed some initial improvements, but there were still plenty of complaints from Google. It was probably worth making some other changes somewhere else as well.
Simple HTML5 Migrations
There are some easily-implemented changes to move from the various versions of HTML to HTML5.
The Document Specification
The original document specifications for the files were:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
or:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html lang="en-gb"> <head> <meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> <?xml version="1.0" encoding="iso-8859-1" ?>
or:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" />
or:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html>
<head>
<meta http-equiv="content-type" content="text/html; charset=US-ASCII" > <meta http-equiv="Content-Language" content="en">
Changing them to HTML5 meant updating them to:
<!DOCTYPE html>
<html lang="en-GB" xml:lang="en-GB">
<head>
<meta charset="UTF-8">
This was a simple change to implement – mostly just running a few search and replaces.
Scripts And Style Sheets
Script declarations in HTML5 pages are assumed to be JavaScript, so I changed all script declarations starting with:
<script type="text/javascript">
to:
<script>
This included scripts imported from external files. While I was doing this, I decide I may as well fix the following warning from Google:
Behavior / Site Speed / Speed Suggestions
Minify JavaScript
Minify CSS
Minifying involves reducing the size of a file by removing unnecessary characters (spaces, comments, carriage returns etc.) and replacing long variable names with much shorter versions. MS Visual Studio Code has a minify plugin that does exactly this. It also keeps the original file, so for example, if you start with:
mystylesheet.css myscripts.js
you’ll end up with:
mystylesheet.css mystylesheet.min.css myscripts.js myscripts.min.js
I did this with my style sheets and scripts, and then replaced all references to the original files with references to the “min” versions. Now I make any changes I want in the original files, use VS Code to recreate the “min” versions and upload them to my server.
Document Structure
The original pages had a column on the right-hand side so there were lots of <div> sections on every page. HTML5 has its own page structure elements, so I updated the <div> sections to <aside> elements with the same class. Later I added the other HTML5 semantic structure elements (<main>, <article>, <footer> etc.) to the pages to move them further towards being full HTML5 format.
Other Changes
Some of the simpler HTML changes suggested by Google were also fairly simple to change as I worked through the pages:
Search Appearance / HTML Improvements
An assortment of duplicate and short titles and meta descriptions
Fixing this just involved going each page and making sure it had its own unique title and description meta tag. There were other tags that needed to be changed, but I’ll cover those later.
Web Page Changes - Mobility
The mobile usability warnings seemed like something that needed to be solved – around half of my site’s visitors use mobile devices to view it.
Search Traffic / Mobile Usability
Viewport not configured
Content not sized to viewport
Small font size
Touch elements too close
These all look quite involved, but they’re actually not too bad. The first two are caused by the web page not having a viewport, which is the way of mapping from the physical pixels on the device’s display to the logical pixels on the page. This never used to be much of a problem when almost all pages were shown only on desktops, and very few people cared too much about scaling to different screen resolutions. Now, with mobile displays and multiple resolutions, all scalable on many devices, logical pixels are rather more important. Setting up the viewport and getting rid of the first two of these warnings is done by adding one line in the <head> each page:
<meta name="viewport" content="width=device-width, initial-scale=1">
The small font size problem was caused by my CSS style sheet specifying a 10pt text size. Rather than specifying in pt or px, which are not scalable units, I moved to em, where "1em" is the same as "12pt". While I was working on the style sheet I took a moment to convert all of the pt and px specifications to % and em.
That was enough to stop the warnings about mobility usability.
Summary
By now, the pages were HTML5 with a few minor errors that didn’t cause any problems in browsers. The changes were enough to clear most of the warnings from Google, especially after a few days when the site had been re-crawled.
The remaining errors were either not that serious, or looked like they were much more complex than a half-hour fix; so fixing them got put off until later. I'll go into more detail about those later.
