How to make a website

As I launch a new website for my business, the 9th version to appear on wizpip.com but first directly related to my new status as a business, it seems fitting that my first blog post should be all about how a website is made.

In the beginning

When I first became a web developer in 2006 I had no experience of making websites professionally. There was a sharp learning curve. As in all agencies my time was charged to clients the same as it was for the senior developers; £600 +VAT per day. This is an important figure, because it demonstrates that a freelancer such as myself, now with 11 years experience, is cheaper than a junior developer (at 2006 prices) in an agency with no experience. And you don't get to choose if the junior's working on your website.

But our agency had some good talent. The internet was a simpler place for web developers in 2006. Websites were designed to work in Firefox 1.5 and then bug fixed to work properly in Internet Explorer 6. Most agencies didn't bother with the Firefox part, and why would they? Almost nobody had heard of it. There was no responsive coding to do; websites were made to fit on an 800px wide display and that was it. Job done. The talent we had, that I learnt from, showed me the importance of making sure the code we wrote was valid; that is to say that we were writing to the HTML specification so that no errors were present when tested. Most agencies don't do that even now, either through inexperience or ignorance, and I'll tell you why it's important shortly.

Internet Explorer 6 was a real pain to work with. Because the browser itself didn't adhere closely to the HTML specifications, things would render incorrectly even when rendering properly in Firefox. Many hacks were required to make the same code work in both browsers, and the internet was full of dirty tricks. Adding an asterisk at the beginning of a CSS statement so that IE couldn't see it; using comments on linked documents to trick IE into loading a stylesheet specific for itself. But I didn't like that. Through time and experience I became an IE6 bug neutralising king, hack free.

When Internet Explorer 7 was released it fixed some, but not all, of the rendering bugs that were present in IE6. Huge swaths of websites across the internet broke as people updated their browsers. IE was still the browser king, but all of the hacky code that worked with IE6 was a complete failure on IE7. Our websites of course, were completely fine because I'd made sure that my fixes were not only hack-free, but were completely valid when tested against the HTML specification. And that is why validation is so, so important.

Another benefit of valid code is that it is for the most part, inherently accessible. Of course there are other things you need to keep in mind, but more often than not a valid website produces far fewer accessiblity issues.

In short, 11 years ago, a website was made for one device, one resolution, and two browsers.

2017

Making a website in 2017 is somewhat different. I'll summarise it for you first, so you can see how much longer this is than the previous paragraph. Websites are made to work with IE11 (if required), Microsoft Edge, Google Chrome, Mozilla Firefox, Google Android Chrome, and Apple iPhone Safari. They are designed to work, responsively, for multiple desktop, tablet, and smartphone display resolutions. Although most agencies don't, websites are validated against the HTML specification, and tested for accessiblity against the W3C WCAG 2.0 level AA guidelines. The thing I find interesting about that last point, is that the Equality Act 2010 makes it a legal requirement to have an accessible website, thus most websites in the UK are illegal.

I haven't finished yet. A 'premium' agency or freelance developer, such as myself, will also produce code that is as small as possible, optimise images for maximum clarity yet fastest download speeds, the smallest number of requests for server efficiency, and many, many other optimisations and settings to keep a server running quickly and securely. You may assume as a client that these are all things to be expected, but how many times have you heard of large companies such as Sony or Vtech in the news because a database of plaintext passwords was stolen? At the very least those passwords should have been salted and hashed into an irreversible string of characters, which only demonstrates how poor or lacklustre some agencies can be.

It's fairly clear to see, that going from 2006 to 2017 we've added a huge number of things to cater for. Whereas in 2007 I'd managed to start churning out fully bespoke brochure websites of six to ten pages within two to three days (design and project management time excluded), now it can take at least a week and sometimes two, even for a relatively simple website.

These times can be shortened somewhat by using a CMS such as WordPress, and ready-made templates, but only if you're willing to forgo many of the optimisations and be fully legal as stated earlier. Although WordPress templates can be altered to be valid and accessible, that does consume all of the time you've just saved by using the CMS. You could join the crowd of people with an invalid, inaccessible website, and if it's cheap, your first website, and you're a single person business, then it may seem like a good option. No guarantees that it won't break when the next browser update happens, or that you won't get a cease and desist letter from people who can't use your website for accessibility reasons, though.

And finally...

You may have been expecting a tutorial on how to make a website, going from the title of this article, so I'm sorry if you feel tricked. But I hope that I've highlighted how involved the process of web development is. I haven't even spoken about any of the 31 JavaScript frameworks (and counting), and why I'm avoiding them like the plague. That's for another blog post.

WizPip (that's me) doesn't do design work, but I can advise on UX, UI, and colour contrasting (part of accessibility). I code websites completly from scratch (front-end and server-side code), register and configure domains, email addresses, hosting, and configure webservers for optimum efficiency and security. You're looking at a fully bespoke website right now!

Technical details

Here's some info about the bespoke website you're currently viewing:

  • The site uses no libraries, frameworks, or CMS. This keeps it remarkably lightweight and fast
  • The DOM content loaded is ~70ms. That's ~20x faster than most websites
  • The site takes ~250ms (that's 1/4 of a second) to fully load on a typical broadband connection, up to 20x faster than most other websites
  • The homepage is ~45KB, which is ~50x smaller than most webpages on the internet
  • (Almost) all of the images are SVG. This allows them to scale to any resolution and remain sharp, whilst significantly reducing the complexity of the code required to handle responsive images, and the overall filesize. Where jpgs are used, they're available in a full range of resolutions (up to 4K), and your browser chooses the correct one; no messy JavaScript
  • There's an animated banner (HTML5 canvas & JavaScript) on every page. Possibly too much effort went into the cookie page. There are also CSS3 animations dotted about, including inside some of the SVGs!
  • The site has been tested across all of the browsers and platforms noted in the article above. During these tests I raised a bug report for Chromium (Chrome) because the location of HTML 5 form alerts is incorrect on a high-dpi display (4K), and discovered a bug that only affects iPhone Safari. Of course, I found a hackless solution
  • There's an RSS feed available, largely because Ben Dodson requested it
  • The site passes W3C HTML validation with no errors, W3C WCAG 2.0 level AA guidelines (tested with Webaim WAVE) with no errors, and scores AA for optimisation from GTmetrix

I use Disqus for comments, which adds well over 700KB to the page weight (over 5x more than this page on its own!) which is why you have to activate it manually.