Cluttered Websites
(Information Technology,Programming)

= Cluttered Websites =

2017-02-19

As I write this, it’s the year 2017. I started learning about computers in 1974, years before the personal computer became “a thing”. The Internet (for those of us not working in a huge computer company or in a major university) was even further away. The World Wide Web was even further away, relying as it does on the Internet. In fact, I’ll admit that when the Web first appeared on my radar, I thought (and told people) it would be a fleeting fad. Glad I didn’t bet money on that one!

My first experience with computers (mainframes) in high school led me directly into programming. and I’ve been doing that ever since. So it’s probably not surprising that I can write HTML, Javascript (not well), PHP and CSS. For those not familiar with the anatomy of websites, HTML, Javascript, PHP and CSS are the backbone of virtually every website on the Web.

Some of you remember back at the beginning of the web, when black, starry backgrounds were the style de jour. Gawd, they were horrible. There was no Google. We had AOL, Yahoo was our godforsaken search engine. Wikipedia was in the distant future.

And now it’s the future. The browser wars are more or less over. Flash has more or less come and gone. Now we have HTML 5. Your phone and tablet (!) can surf the Internet, though they probably serve up a slightly watered down version of most websites, thanks to Google.

It used to be that if you wanted to build a website for your company or your family or yourself, you had to know HTML at least. Maybe some Perl (another language) or PHP, if you had forms on it. Now you have endless companies lined up with templates to help you build websites. And if that’s not enough you’ve got WordPress as a whole website platform. HTML? Nah. It’s still there in the background, working its magic, but you don’t have to know anything about it.

Now let me tell you about my computer and my usage of it. I have a fairly modest computer. Not a lot of memory, a reasonably powerful CPU, a couple of speakers. This is a desktop machine, because I really don’t like laptops much and I don’t feel the need to walk around and compute everywhere. My desk is fine. I’ve got a browser open with about eight tabs open. A second “desktop” with my email program, a music player, calculator, a note-taker, a database editor, and about five programming project tabs open. On another desktop, I’ve got a spreadsheet with my tax spreadsheet open (it’s tax season). (In case you don’t understand what a “desktop” is, it’s like a whole different computer, but running on the same hardware as the rest of your stuff. I’ve got a map of the four desktops I have at the bottom of my screen. I just click on the icon at the bottom of my screen to go to that desktop. If you use a Mac, you kind of have something like that. Poor Windows users will probably never have anything like it; I don’t think the engineers at Microsoft could bring it off. I use “Linux”, which is kinda like OS X or Windows, but more capable.)

Under normal circumstances, this machine serves my purposes. It’s plenty fast enough to do what I need it to do. Yeah, I could spend a grand and buy a more powerful machine. But why? I’m a big proponent of, “If it ain’t broke, don’t fix it”.

My wife has a Mac. A big one. eight gigs of memory, a quad core processor. A huge monitor. She designs print newsletters and ads and websites.

One thing we’ve both noticed, which has gotten worse over the years and now is nearly unbearable: web speed. If you weren’t there from the beginning, you may not realize how much the web has slowed down.

Let me direct your attention to a little area at the bottom left of your browser window. This often tells you what your browser is doing as it sits there seemingly dumbfounded, waiting to fully paint the page you just asked for. This is a running record of the requests your browser is making as it pieces everything together for your requested web page. Some time, when you’re really bored, take a look at all the the requests it’s making on your behalf, as dictated by the page you asked for.

As you watch this display, you may ask yourself why it’s asking for all this crap. Google Analytics, Google fonts, ad text and images, lots of unknown crap from other websites which don’t really have anything to do with the webpage you called up.

What’s up with that? Here’s what’s up. Back in the day, when we had websites with black, starry backgrounds (remember those?), the HTML that built your website didn’t make any “side calls” to other websites for anything. Your browser made a few calls for images, maybe, and then went ahead and painted your page. But not today.

Let’s consider just one instance of these side calls: Google Analytics. These have to do with measuring the number and duration of web page visits, so advertisers know whether it’s worth it or not to advertise on a given site. Every time you open a page on a website tracked by Google Analytics, a call is also made to Google’s internal machinery to register what’s going on. Just think, for every web page everwhere which is registered with Google, their computers have to deal with a request every time a page on that website is accessed. You’ve got a website on mystore.com, and every time any page on it displays, Google has to fire up their computers and register what’s going on. That goes for every other page on every other website also registered. How many websites are there on the web? How many pages? And every page access is another hit on Google’s servers. So in addition to performing search functions, Google’s computers have to service millions or billions of page hits a second to know what’s going on.

Here’s another example. I just opened up a webpage for an average blog site and decided to look at the “source code” for the page (you can do this too) to see what was going on behind the scenes. Before you ever got to a part of that HTML page that governed the “header”, there were hundreds of lines of complicated CSS and Javascript code. For those unfamiliar with web design, that’s a lot of dang code. Just for reference, those old web pages with the black starry backgrounds probably had ten lines of code before they got to the point. And it didn’t stop there. The whole page was full of CSS and Javascript code, for God knows what reasons.

You want to know what is slowing down the web? Just that. Every time you use one of these template services, every time you register your web pages with Google Analytics, every time you try to use Google fonts, you’re adding to the more or less needless crap which fires every time someone visits a page on your site. Every time your page makes an offsite call (lots!) browsers have to stop and wait for the replies from busy servers elsewhere in order to finish painting their pages.

Here’s another fun thing I’ve noticed. More and more, I’m getting notices from my Firefox browser that some Javascript script embedded in the page I’m looking at has stopped responding, and asking whether the browser should terminate the script or let it continue in a seemingly unresponsive state. In almost of every single page I’ve seen this, there’s absolutely no need to have any Javascript on that page which could become unresponsive. But it’s there.

And here’s another item for you web designers who use a lot of database calls as a part of your web design. First of all, don’t store your damn web pages in databases. I’m talking to you, WordPress. That’s another silly delay, requesting and fetching content from a database which was never designed to store and retrieve web content. If your web page is designed to display data that properly belongs in a database, so be it. But otherwise, keep configuration and other data you need out of the database. Fetch it from a flat file somewhere. Sending all kinds of silly requests to a database server just takes up time and CPU cycles without any real benefit. And don’t attach a bunch of silly Javascript triggers to your site. AJAX, yes, if you must. But limit it to only where it’s truly needed.

It can and will be said that the real answer here is to beef up my machine, sit the hell down and shut up. Um, I’ve got news for you– my wife’s excessively powerful Mac has the same problems. She’s more impatient than I am, and she sits there quite often, waiting for some average web page to paint, as it processes hundreds of lines of unnecessary Javascript and offsite component calls. She just sits there and gets steamed. So it’s all very well to proclaim that everyone complaining should beef up their computers, but by the same token, there’s no reason to jam megabytes of code down the line to display single pages of domains. Seriously.

Here’s the bottom line. Learn to confront writing HTML, CSS, PHP and Javascript. Stop using platforms and templates full of unnecessary tripe. It’s a single page, for Pete’s sake. There’s no reason to waste a megabyte of code on it. Keep it slim. Make it responsive. Severely limit your offsite calls. If you just can’t confront code, try Dreamweaver, a great source for WYSIWYG webpage design tools. If you’ve got a form, find someone who does PHP and have them whip up some tasty code to deal with your forms (which can’t be processed by HTML and shouldn’t be processed by Javascript).

And if you think there’s really an argument left to be had on this subject, consider this: operating systems aren’t written in Java (they’re all written in C). There’s a reason for that. If you’re not sure how that argument might go, look up “glaciers” and “geological epochs”. Web pages are not operating systems to be sure. They’re a helluva lot simpler. And you should treat them that way.