Websites and the Internet: The things you don’t get told.

Why can making websites be difficult? We hear it a lot. Why is WordPress so hard to use? Why does it work like that? Why do I have to consider things I don’t want to? Can you change the way everything works to make things easier?

I’ll hold my hands up and agree that it’s not that easy to make a website that performs well, that looks good, and is easily found in search engines. So why make a website? Why is it so hard? What are the easy options? Hopefully this post will help answer a few of these questions.

Since Google launched in 1998, people have used it to search for anything and everything. There’s a belief that Google may have affected our ability to remember things (people have done studies). Just as the calculator paved the way to us forgetting how to do mental arithmetic, it’s entirely possible that we remember less, simply because we can look it up online.

Let’s say you’re a plumber, and you do a really good job for Jim, but you don’t have a website. If Jim’s neighbour needs a plumber, and Jim can’t remember your contact details he’s probably going to turn to Google to find you. It’s not like they print the Yellow Pages any more, now, is it? Except Jim won’t find you, he’ll find your competitor, who does have a website.

Because there’s so much of this searching that goes on, and people do tend to mostly turn to Google for local searches, that’s a big slice of pie that you’ll miss out on if you don’t have a website.

A lot of the things that make websites difficult are based misconceptions about how everything works.

Yes, that’s right. The internet wasn’t designed for us. It was designed for the US. The US army in fact. The original intent of the internet was to connect a distributed network of computers that could survive, at least in part, a nuclear attack. It wasn’t designed so you could buy shoes while you’re at work… yes, Glenda, I’m referring to you… I can see your screen… get the black ones, they match your soul.

The web runs on the internet. Although the two terms are generally interchangeable, they’re different things. The internet is the network. The wiring if you will. The web is the collection of websites (yes, facebook is a website) that you access using the internet.

The original “web” was invented by Tim Berners-Lee and its original purpose was to interlink scientific research papers. One paper could refer to another paper, and you could click the reference to see the other paper.

That’s right, the original web idea was a bit like Wikipedia, except it was specifically for scientific research papers, rather than everything you can think of. In a way, the web isn’t that different for what Tim Berners-Lee had in mind. Interlinked, decentralised, pieces information that refer to each other. I’d guess Tim might have pictured his invention as having more text, and a more noble purpose rather than being the planet’s most inaccessible advertising space, but the cat was out the bag, and it wasn’t his cat any more… and… why is that cat using a computer!? Welcome to the internet. Tim.

Why are you handing me my coat and calling a taxi? I’m not the only person who thinks this!

While porn might be the internet’s guilty little secret, it’s also the unsung hero of broadband. Long before Netflix and Amazon were buffering your box sets, adult content was demanding faster, smoother, and more reliable connections. If streaming had waited for Jeff Bezos, we’d still be downloading pixels at dial-up speed — and judging by the shape of his rockets, the irony would’ve been hard to miss.

While streaming services do keep a constant IV drip of data goodness — most of the web doesn’t work that way. In the majority of cases, your browser and the web server aren’t in some long, intimate relationship. They talk briefly, do what they need to do, and then ghost each other until the next request.

It’s called a “request-response” model: you click a link, your browser sends a request to the server, the server coughs out a page, and the browser renders this in to what you see. From that point on, most things that you see change (buttons lighting up, menus dropping down) is all happening locally in your browser. No need to bother the server again… unless you click another link, submit a form, or click the “Buy Now” button.

So rather than some ongoing, loving connection, it’s more like ordering a la carte: one dish at a time, on demand. The waiter doesn’t hang around spoon-feeding you or endlessly regurgitating a pre-chewed dinner in to your open mouth (that’s how streaming services work).

Browsers are a bit like a goldfish with a to do list.

Take note, future web wizards: browsers are single-threaded. That means they can do one thing at a time. No multitasking, no parallel magic, just a very orange little fish swimming through one hoop at a time.

Picture the scene:

You build a site with zero inlined CSS and toss in a glorious 5MB external CSS file. What happens?

The browser gets the HTML…
Then stops everything.
Then swims off to fetch that monster CSS file, heaves it over to your browser (using it’s fins).
Then, finally, starts drawing the page.

During all that the visitor is staring at a white screen, wondering if their Wi-Fi died or if your website’s loading by post.

A browser is a bit like a bad barman. You go to the bar with the intention or ordering a round of five drinks. You say one drink, the barman goes off and makes that, he comes back, you order drink number two, he goes off and makes that and this cycle keeps happening until you have all five drinks. It would be a lot more efficient for you to say all five drinks, and the barman to then go off and make them all, but browser’s don’t really work like that.

Instead you have to give your barman a set of sequential instructions that result in the quickest serve time.

Get five glasses. Start filling glass one with Guinness now, now put half a pint of lemonade in glass two, in glasses three and four put lager, top up glass two with lager, stop the Guinness in glass one, put ice and Bulmers in glass four, finish off filling glass one with Guinness. This is roughly how you optimise web page output, except you do it with HTML, CSS and JS instead of lager, shandy, Guinness and Bulmers.

In a lot of cases, the page output of a website has more effect on page load times, than the underlying hosting. You can’t just throw money at it to make it faster (that would probably work OK with a bad barman, but it doesn’t so much with browsers). You have to actually know how to do things!

KNOW THINGS? NOBODY TOLD ME I HAD TO KNOW THINGS!!!

It’s my personal belief that the way browsers work is a nerd’s revenge on a wealthy high school jock in some American teen like movie scenario. In reality, it’s more a question of security and being able to operate on a wide range of devices. Hey, EVERYONE used paper at one point, and that was really low power consumption.

HA! Sorry. HA! Sorry… Say that to anyone that works in IT. See what they say.

Now, it’s not like everything is completely failing all the time. Part of the reason why we use Linux is because it’s very stable and doesn’t fail like this.

On the other hand, you do get “that’s just how it works” like text based email filters not working on HTML encoded emails.

We do also get “other people’s stuff…” type problems. My personal favourite was a year long support ticket that involved emails occasionally routing to where a website, rather than mailboxes were held, due to RFC 5321 section 5.1 and 3rd party nameservers failing to serve an MX record. That was a year of fun that was resolved by begging a 3rd party to use Cloudflare’s DNS management because they reliably serve records when queried.

Most of the internet runs on free software that’s effectively been shoehorned and bodged together. There are exceptions like web servers, but these are really part of a bigger picture.

This brings me to…

I love LAMP. I wouldn’t have this job without it. Or the job before that, or the job before that, or the job before that. In half of these jobs, I didn’t even know what LAMP was!

The LAMP stack (or variations of it) are what run most of the internet today.

How the LAMP Stack Became the Web’s Unlikely Hero
Back in the 1990s, when the web was still figuring out whether it wanted to be a digital library or just a place for dancing baby GIFs, the LAMP stack was quietly assembling itself, not as a grand plan, but more like a pub quiz team that accidentally won the pint glass full of pound coins.

• Linux: A hobby project by a Finnish student (Linus Torvalds) who wanted a free alternative to UNIX (which cost a fortune and ran on special chips). Definitely not created with dreams of powering the world’s cat meme servers.
• Apache: A web server written by volunteers, named after “a patchy server” because it was literally a bunch of patches stuck together. If Frankenstein puked out web pages upon request, you’d have something a bit like apache.
• MySQL: A lightweight, open-source database born in Sweden, intended to be fast and flexible. Great for small tasks… until people started trusting it with entire businesses.
• PHP: A scripting language originally meant for building a personal homepage. It grew like an overwatered houseplant; messy, unstoppable, and somehow still alive.

LAMP wasn’t designed to “run the web.” It just happened to be free (wich is important when your budget is £0 and your server is under your desk), and simple-ish or at leastflexible enough to hack together something that kinda worked.

Before long, web developers everywhere were copying each other’s bad PHP code and spinning up forums, blogs, shops, and whatever else they could think of, all running on this happy little stack of misfits.

Over time, LAMP evolved through sheer momentum. It powered everything from WordPress blogs to million pound startups. The open-source community gaffer-taped security, speed, and features onto it. And despite dozens of shinier alternatives since, LAMP refuses to die. It’s the Les Dennis of stacks; dependable, scrappy, and always two commands away from working again.

The LAMP stack wasn’t supposed to run the internet. It just did.
Like ketchup on the table; no one asked for it, but everything’s better with it.

Once upon a time in 2003, two developers (Matt Mullenweg and Mike Little) wanted to make a nicer blogging platform after the one they were using (b2/cafelog) stopped getting updates. The plan was simple: fix a few things, tweak a few features; “Just a fork, nothing major.”

Fast forward to today, and WordPress runs over 40% of websites on the internet. That includes everything from local cake shops to MP’s websites and FTSE 100 companies.

That little fork? It turned into an excavator that accidentally dug the foundations to a lot of the web you see today.

Originally designed for bloggers, WordPress was meant to make writing posts easy and elegant. It had a text editor, a comment section, and maybe a sidebar if you were feeling fancy.

But then people started saying things like:

• “Hey, can I use this for my business site?”
• “Can I turn this into an online shop?”
• “Can it book yoga classes, run a membership site, and also email my mum?”

And the answer somehow kept being:
“Sure, there’s a plugin for that.”

• Free and open-source, because everyone loves free stuff until it breaks.
• A plugin for everything – SEO, shops, forums, recipes, dog-sitting calendars… you name it.
• A theme for every mood, from corporate sleek to Comic Sans chaos.
• No coding required… allegedly… until you break something and have to Google “white screen of death.”

As WordPress grew, so did its ambition, and it’s mess. What started as a clean little blogging platform is now a full-blown content management system, a page builder, a site editor, a WooCommerce megastore, and (if you try hard enough) a social network.

It’s like a Swiss Army knife with 300 attachments; powerful, but slightly terrifying.

And Yet… It Refuses to Die

Despite newer, shinier platforms promising “modern stacks” and “cleaner code”, WordPress keeps winning. Why?

Because it just works (mostly), it’s familiar, and there’s a vast army of developers, designers, and confused clients who already use it.

WordPress was supposed to be a blogging tool. Now it’s the god-emperor of DIY websites. Built on PHP, gaffer tape, glue and plugins, it powers everything; even if no one’s entirely sure how… or why. It’s not perfect. It’s not elegant. But it’s WordPress. And it’s not going anywhere.

I’m sorry what was that? You thought that was the hard part up there? Oh, no, that was just the backstory, here’s the hard part.

You’ve bought some web hosting, you’ve registered a domain, you’ve installed WordPress and the first thing you think is “what on earth this this thing all about?”. A friend of mine, who’s a programmer, who needs security clearance to do his job said roughly this. I say roughly, there was more swearing (and I’m at work).

Out of the box, in a first attempt, WordPress isn’t that easy to get to grips with. The funny thing is, all you need to do is press this key on your keyboard:
/
And everything starts to fall in to place.

Why they don’t just say this in the interface is beyond me… Well, actually it’s not. They’re doing this to set a level of expectation. That’s right, there’s going be a lot of “why didn’t they just say?!”. There’s no manual. Well, there is, but it’s not for users, it’s for developers. We do what we can though don’t we?

Several themes, a page builder, a few hundred plugins and a considerable amount of time later, you’ve managed to make a website. And it runs like a dog. With no legs. It’s just a dog caterpillar slowly wriggling it’s way into your browser, scraping the skin of it’s underside when doing so. So you Google:
Why is WordPress

And it autocompletes to:
Why is WordPress so slow
or
Why is WordPress so hard to use

At least you’re not alone. Console yourself with that. You’ll need a lot of that. Both consoling and Googling.

After reading enough, you find out that what you’ve accidentally done is made a WordPress that will be slow.

Yes, that is the voice of experience speaking. I think everyone’s first WordPress is probably a bit slow.

The inevitable fact is that you’re probably have to rebuild your entire site. You’ll try and avoid this for a while, go through the phases of denial, rage, and finally acceptance. You wonder how all this happened, just like I did, and then you accept you have to remake your website, just like I did.

Hopefully you didn’t smash your computer up in a fit of rage, just like I did. WordPress! With free hammer and safety glasses included!

How I accidentally made a bad WordPress. Here’s my step by step of how I did it wrong.

I didn’t work the / part out, so I installed a page builder. WordPress comes with a page builder, which isn’t too bad once you get used to it. By installing a page builder, I inadvertently added an additional layer of CSS and JS to my page output, and a font library that when used causes delays in fonts loading, which can make text appear late.

I didn’t know that’s what I was doing at the time. I only found this out when I started looking in to a poor text to HTML ratio, an excessive DOM size and “ensure text remains visible during web-font load” as reported by the delight that is pagespeed insights.

Just by installing a page builder, I’ve added a lot of code (some of it’s not great) to my page output, which increases the time it takes for a page to load.

I installed a contact form plugin, I installed another plugin to put a captcha on that contact form, I installed a gallery plugin, I installed a Google reviews plugin. Hey, they’re all free and easy to install! These don’t sound like a big deal and most people want them, but here’s the main thing to consider:

These plugins don’t know which page they’ll end up on… so they put their render blocking CSS on EVERY page.

OK, so not every plugin does this, but the more you install, the more chance you have of this happening. Not just once, but many times.

The other thing that isn’t entirely transparent about WordPress is that it runs (as in code running) as a whole. A lot of people think “this plugin runs when that page is visited because that page has this plugin’s stuff on it”. It doesn’t really work like this. The whole WordPress runs when a page is requested. WordPress core, the theme, and all the plugins. The more plugins, the more code, the more code, the more time.

So by installing a lot of plugins, I’ve added more code to my page output AND I’ve made my WordPress slower by making it run more code.

It is possible to do things like unload certain scripts on certain pages using things like a child theme or a code snippets type plugin (another plugin, yay!). The downside of doing this is that it can break things, and it’s a bit of a nightmare to manage in the longer term as your site evolves and you add more features (more plugins, yay!).

I wouldn’t recommend trying anything to clever here. The main thing to consider is:

What do I want to keep?

In a lot of cases, it’s mostly words and pictures.

So here’s how you keep that… you might want to take backups or at least check they’re available before doing this. Also disable object caching before starting if your site uses this, otherwise strange things that mess with your mind will happen.

Lets say your WordPress is running on www.domain.com…

1. Create a subdomain with it’s own document root in your hosting. We’ll call this dev.domain.com for example’s sake.
2. Install a new copy of WordPress on dev.domain.com
3. In www.domain.com install the WordPress exporter:
   Tools > Export > Install (in the WordPress section)
4. Export all pages:
   Tools > Export > Pages > Download export file
5. Export all media:
   Tools > Export > Media > Download export file
6. Export all posts (if you have any):
   Tools > Export > Posts > Download export file

You now have 3 XML files, one for pages, one for media, one for posts.

7. In dev.domain.com run the WordPress importer:
   Tools > Import > Run importer (in the WordPress section)
8. Import the page XML file you exported in step 4, if you see an option to “include attachments” tick this.
9. Repeat steps 8 for media and posts to import these

That’s your words and pictures imported to dev.domain.com.

The next job is to get the site running on dev.domain.com looking and functioning how you want it to. To do this:

10. Install Kadence theme (see the Why Kadence section below if you’re thinking “why Kadence”)
11. Install Kadence blocks
12. Use:
    Appearance > Customise
    To make the header and footer look like they should
13. Work through your pages and posts to make them look like they should. Make sure you only use Kadence blocks elements when you do this wherever possible.
14. Install additional plugins to gain functionality ONLY if there’s no respective Kadence block.
15. Install the “better search and replace” plugin by WP engine.
16. Delete the contents of the www.domain.com’s document root (make sure you don’t delete the contents of dev.domain.com’s document root when you do this.
17. Copy the contents of the dev.domain.com’s document root to the document root of www.domain.com, then check the wp-config.php file to see which database is in use.
18. In the database in use, update the siteurl and home values in the options table from https://dev.domain.com to https://www.domain.com .
19. Login to WordPress https://www.domain.com/wp-admin
20. Use better search and replace (tools > better search and replace) to:
    – Search for https://dev.domain.com and replace with https://www.domain.com
    – Select all tables
    – Tick all options below tables EXCEPT for “do as dry run” which needs to be unticked
    – Run the plugin
21. Purge all caches (if there are any).
22. Correct any remaining config (SMTP plugin config, captcha keys etc)

And you’re done. The horror is over. Well survived…. but wait there more!… in a bit.

The Kadence people are pretty smart. Kadence is a pretty customisable theme so you can make it look mostly how you want (if not completely how you want) with it’s straight forward customisation options.

Kadence, when used with the WordPress blocks editor keeps you page output fairly minimal, and doesn’t add many elements to your page output that will cause delays in page loading.

By using Kadence Blocks with WordPress, you don’t bring a lot of different “layers” of plugins in to effect with all their render blocking code that gets put everywhere.

Because you’re keeping. everything in the Kadence house, it all works nicely together, doesn’t put a lot of issue laden code in your page output, and generally means things will be quicker.

Kadence blocks also has a lot built into it which negates the need to use additional plugins, such as contact form and captcha plugins. Kadence has a built in form with all this built in.

You’re doing as much as you can with a few elements as possible, and this helps keep the total codebase of your WordPress fairly minimal, and your page output nice and lean.

Try it, you might like it!

More?!?!? After all that? You’re telling me there’s more?

I’m afraid there is.

By now, you’ve got your website online, and it’s performing well in terms of page load times. The thing it’s not performing well for, is being found online.

Luckily, I’ve already covered this in previous blog posts. Not so luckily, you’re going to need to revise a lot of your website. Again.

This time, it’s words on the page and where they appear, or SEO as it’s usually referred to. Luckily (?) I’ve covered this in past posts:

• Carry out keyword research
• Optimise your page content
• Add your site to google search

You might then need to carry out some backlink outreach in addition.

I’ll admit, it took me years to get through what I’ve covered above. My first computer related job was telemarketing for a company that sold refurbished Unix servers. Back then Linux was a new thing, dial up was the common internet connection and you could make a cup of tea in the time it took for a website to load. Even then it was a flat HTML unresponsive website because smart phones didn’t exist. That’s how long I’ve been doing this. I’m a dinosaur. A tired, jaded, burnt out dinosaur, with bleeding stumps where my fingers should be.

If I had a time machine, and I could go back and give my younger, more enthusiastic self some advice, it would be this:

Buy into this, and you’ll spend a lot of time reading and testing to stay ahead of the change, or catching up with it.

As above, but with more effort. Not only are you going to need to know things, but you’re also going to need to understand things. While they might sound like the same thing, it’s one thing being able to tell the time, it’s another thing understanding how a clock works… or how time works for that matter. There’s no manual, there’s probably no course that covers everything. There are a lot of courses put together that will help with a lot, but some of it you’ll have to teach yourself.

Most of the mistakes made that I’ve outlined above could have been avoided if I’d done a bit of research. I’d have saved A LOT of time. Then again, I wouldn’t have had the delights of experience to regale you with. Swings and roundabouts, I guess.

Yes, there is always the option of paying someone to make your website. It can be expensive, and you can find that you need to pay one person to do one thing, and another to do another thing. There are also a lot of people that promise the world, charge you a lot, and deliver very little. Check the reviews, recommendations count for a lot, know your subject matter, and set your twaddle radar to full.

Good luck, I hope it goes OK, I’m off for a lie down now.