You are here » Home » Internet » Case Study - The Why and How of a Major Site Update
But something was "wrong". I just couldn't complete the job then, for some unknown reason.
At the time, I blamed the fact that I was recovering from my own major heart surgery (triple bypass in January). I still couldn't concentrate enough to do the work involved.
Now, I realise that the problem was that the house needed "gutting"!
That meant stripping everything out except the bare framework, and rebuilding it from scratch!
So that's what I have been doing for the last couple of months!
And here's what happened, in web design terms, when I upgraded a 15-year-old website to current standards.
There was none.
All the core pages have been lovingly "hand-crafted" in raw HTML. The actual directory listings were generated "on-the-fly" by CGI when people saved them.
The search results pages were created by hundreds of CGI routines, depending on what was going on.
I used some server-side-includes to easily update basic components in the headers, navigation and footers etc.
But when it comes to actually "doing" a major update to the skin/layout, it was still a huge job as pretty much every page had to be adjusted. But with only 600 or so static pages, that shouldn't take long LOL.
After my surgery, it was pretty obvious that NO-ONE other than me could "drive" the multi-faceted website.
If I had died, the site was "cactus" simply because no one would understand WTF went on there, and how it all worked.
I had to rectify that so the site would be worth "something" to my heirs and successors LOL
So I have completely upgraded it to "modern standards. And now, one click into the back end of that pretty much gives me (or my heirs) the ability to do almost anything on the site!
And I even managed to work out how to do "templates" with all the coding, so I'm "chuffed" (yep... slow but steady wins the race... eventually... with this old fella!)
I'll adapt it over the next few months and install on my other core sites.
Sure are! Fix the main one, and the rest will probably fall into place:
Coming from a 14.4K modem background, this has always been on my mind. Back then, if your website loaded more than about 50KB, it was far too slow!
But we (web developers) have got extremely lazy now in this broadband age, and page load times have gone through the roof! According to GTmetrix, "the averages" relating to page load are: (appalling - my word)
Obviously, a slow loading site will annoy the ^$%#&^%$ out of your users! That little red "X" in the top right-hand corner is so very easy to use...
If you want people to stay "engaged" and consume your stuff, you've got to make the experience pleasant right at the start... even BEFORE you look at whatever content you are serving!
Oh... and by the way, only since 2010, have Google's search ranking algorithms included site speed as a signal :)
Sidebar: Go check out GTm's Top 1,000 sites on the Internet, and "play" with the columns to see how many of them have poor page load speeds. It's "enlightening" to say the least LOL
I once thought that people who couldn't wait more than three seconds for a page to load were symptomatic of our modern "Rush! Rush! Rush!" world...
But now I understand why :)
Here's a link to the side-by-side comparison of the two pages.
Using most of the recommendations that were made when I ran my pages through the "Analyser" over at GTmetrix, you can see a huge difference!
Me Old - PageSpeed Score (83%) - YSlow Score (75%) - Time 4.8s - Page Size 380KB - Requests 44
Me New - PageSpeed Score (99%) - YSlow Score (93%) - Time 2.3s - Page Size 106KB - Requests 9
Top 100 Avs PageSpeed (71%) - YSlow Score (69%) - Time 8.1s - Page Size 2.54MB - Requests 84
Some of the suggestions were a bit "picky" and might save a byte or two, but where I could see an obvious improvement, I went for it!
A lot of the recommendations meant I had to get very "intimate" with my .htaccess file!
Now that's a scary thing to do because if you stuff up there, it generates a server wide error LOL
Never the less, careful work will yield important results! So I added
Oh... almost forgot... I ALSO had to add this to the top of my htaccess file too:
AddDefaultCharset UTF-8
I also found out how to do several OTHER things to that file, which have been plaguing me for years!
Specifically...
Seriously, in 2011/12 I went looking for a particular solution to this. I just could not get an answer to my question as to why the "normal" approach refused to work on my server.
The problem is simple enough... You should NOT use query strings in your URLs... And I had them everywhere:
eg - search.cgi?terms=keyword&state=nsw&cat=web design
And you shouldn't use them as the search engines do NOT like them!
I have had a "love-hate" relationship with Google for years with one of my sites. For some reason, it absolutely refused to index those URLs.
I also used them extensively at Come On Aussie, yet THERE they were indexed (even though I did NOT want some of them to actually BE indexed)! Go figure ???
The solution involves simple redirects via .htaccess such that requests like this
/cgi-bin/cat.cgi?state=nsw&cat=computers&page=2
can be made into URLs like this
/nsw/computers/2/
Everyone is happier! My visitors, the search engines, and me!
And yeah I know, the solution is actually very simple to achieve! But when ALL the "experts" you consulted previously forgot the critical line (RewriteBase /) in the code... well, what can I say :)
Oh and the code? Here it is:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^nsw/([^/] )/([^/] )/$ cgi-bin/stateroutine.cgi?v1=$1&v2=$2 [PT]
RewriteRule ^nsw/([^/] )/$ cgi-bin/stateroutine.cgi?v1=$1 [PT]
</IfModule>
The first rule is
state/category/pagenumber/ where category is v1=$1 and page number is v2=$2
The second rule is
state/category/ where category is v1=$1 and the receiving script knows it is page 1
There are multiple variations of this in the .htaccess file now, for other states, and other functions :)
And, while I was there... I ALSO finally fixed my
AND did it with only one rule...
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} ^(www\.)?yourdomain\.com\.au$ [NC]
RewriteRule ^(.*)$ http://www.yourdomain.com/$1 [R=301,L]
</IfModule>
So again, another .htaccess issue for which the answer has avoided me for a long time. Mainly because I have seen some extremely convoluted variations to this, which never seemed to actually work LOL
To be honest, I have NOT paid enough attention to the issue in the past. And promise that I will in the future :)
I DID run my template over the accessibility tester here at https://tenon.io
And found a few simple issues I could address quickly, as the site was already live. So I certainly will go back there before the next update and include the five other recommendations they made.
For those folk wondering why I didn't use Wordpress for this?
Well, apart from the "integration" problem of mixing MY data with Wordpress queries (something I did NOT want to learn at this stage), there were other reasons.
Firstly, I seem to spend an extreme amount of time doing nothing else but constantly updating Wordpress and plugins on those sites which have it installed. Yes, I know, it's part of my job and I include that for my clients... But still, it has been taking forever lately!
But that's not the main reason.
I installed WordFence on a client site a few months ago. It's a security/firewall plugin for Wordpress and a damn good one! It stopped literally thousands of unexpected/unknown attempts to get into that site in the first week!
So I also put it on a development site when I started it. What a surprise to see exactly how many constant hacking attempts were being made to get into my website, simply because I used Wordpress on it! And what made it even worse remember... this was only a "developmental" site at the time, which "supposedly" no one knew about?
Yes, I had it open to the public, and yes Wordpress was doing its job pinging whomever it pings when I published my testing stuff. But to have people attempting to hack into it only 20 minutes after I started playing? What the???
Many years ago, another client's web hosting company flat out refused to put Wordpress on their servers on the basis of poor security! I now see why they were so adamant about it!
Yep. Wordfence did the job and stopped all that. Mind you the increased server load in dealing with those repeated attempts is another, unwanted issue. Particularly on a site which is already fairly busy!
And here's another problem with Wordpress and a lot of other CMS's...
We get lazy!
Instead of possibly using a simple 3 line piece of code to do something, we install a "plugin"... or two... or ten... or even 20!
And each plugin has to load its own set of code - be it jquery, javascript, or whatever - to perform its job.
WOW!
So the site I was recoding at the time in Wordpress, I decided to avoid using too many plugins for that reason.
But still, here are today's figures for that home page when I ran a test on it...
PageSpeed Score (63%) - YSlow Score (55%) - Time 5.8s - Page Size 0.98KB - Requests 47
Pretty dismal!
And most of that is STILL due to all the jquery, javascript, and (who woulda thought) bootstrap CSS files that are needed (?).
So my next job is to get back there, and redo that site with MY CMS!
I loved the concept of Bootstrap when I first started playing with it. Simple CSS to do amazing things, especially with responsive websites.
But I don't understand enough to minify it properly for each application. So I was using stock standard minified versions, which came in at over 120KB to load the CSS file. Another thing that takes away from my page speed!
And then I "discovered" what I am now using... W3.CSS
This was initially proposed and developed back in the mid 1990's by the World Wide Web Consortium (W3C) people.
Jeez, Stephen... Out of touch or what? LOL Again, this is something else I should have been aware of a LONG time ago LOL. But life gets in the way of learning, often...
My point is, I can still do what I want in under 30KB of W3.CSS, compared to using a Bootstrap file 4 times the size.
One of the things I noticed is how much these can also slow you down.
With CSS files - put them on your server, and do NOT load them from the source. That reduces ONE DNS lookup. In fact, if you have more than one, combine them into one file. One less item to lock and load!
When you "embed" a video in your page from YouTube or Facebook etc, don't be surprised when you lose all the speed improvements you just made. Your page load time blows out, but NOT because it's downloading the video! That hasn't even happened yet.
It's all the "other" stuff that gets loaded before (javascript etc) from multiple sources, which means, even MORE, DNS lookups. And unfortunately, they all load before your browser can "do" its thing and show the page!
Well, you'd "think" that template Authors would have a good understanding of all this stuff, and serve you the best product they could.
Uhmmm... No.
A lot of the templates I have purchased and run through the analyser over at GTmetrix have big issues! All of which YOU will have to fix if you really want to optimise your site properly.
Since I had THAT much work to do already, I might as well code my own stuff for free :)
Nope... not yet. There are still a few things to do. Like I said before you have to get really intimate with your htaccess file ;)
Back to that again for some more tweaks, this time playing with some 301 redirects, to lose the old pages, and tell the search engines where they went to. I think I only redirected about 500 of them LOL.
Using this simple method...
redirect 301 /categories/employment.html /employment/
This essentially says, REDIRECT PERMANENTLY /OLDFILEPATH to /NEWFILEPATH
If NEWFILEPATH was NOT on your server, it needs to have an FQDN (Fully Qualified Domain Name) in front of it... i.e.
http://www.yourdomain.com/employment
otherwise the /relative path used above is fine.
So why do things go wrong? Because they can!
And of course, the moment something goes "live", you will spot problems that simply did NOT exist on your development server!
Don't ask me why. It just happens! Despite weeks of rigorous testing!
So keep an eye out for them and fix them quickly.
If you want to relax... try that in a week or so ;)
Look, that's more than enough for now... This has grown into a rather long piece, and I don't want to distract you even more :)
Remember all those other shiny objects which can distract you from time to time?
Come On Aussie is now, after 15 years, a lot closer to where I wanted it to be when I first set it up.
I know I can be a slow learner at times, but what a shame it took a triple bypass to wake me up to that!
Written by coais
Stephen Spry is a freelance web designer and Internet publisher. He has been working online, full-time, since 1995 after an 18-year career as a high school Careers Adviser. Stephen operates several websites and web directories in a variety of niches. His main web design business can be found here » Come On Aussie.