Or, “Never put salt on your Wheaties.”
Once, when we were kids, my brother emptied the sugar bowl and filled it with salt. When I sat down to eat my regular breakfast of sugar with Wheaties, I ignorantly piled on spoon after spoon of the crystallized white stuff. You can probably imagine my reaction, about two seconds after putting the first bite in my mouth. What looked so good certainly tasted very bad! I’ve since forgiven my big brother, but I haven’t forgotten the taste.
Looks can be deceiving. Salt and sugar look enough alike to fool a teenager. The same is true for websites. What looks good at first glance may actually be very bad.
Broadband + 4G = a false Sense of security
It’s easy to assume that a good-looking website is also a good-performing website. We’re driven by visuals, and most of us know nothing about the code that makes a website.
What makes a good website?
That’s a good question. The answer depends on the goals of the website’s owner. If the goal is to have a kooky, quirky website with an experimental design, then having a kooky, and quirky website means success. That’s not the most common goal for having a website, though. Most often, those needing a website have goals related to the goals of their organization: to sell products, to explain how they might benefit their customers, or to simply spread their message to the public.
When getting stuck in traffic is good
Whether it’s selling products or ideas, one of the primary goals for most websites is for people – more people, obviously – to come and see. Unless you have a giant advertising budget like McDonald’s or Ford or the never-ending stream of new prescription drugs, it’s up to you to figure out how to bring the masses in. That’s where good code comes in.
Search engines are very complex. There’s a lot we don’t know about how each one works, but there’s plenty we do know. One of the key factors in internet search success is each website’s code to content ratio. To simplify the process, let’s do a little quick math. Imagine two competing websites, each with the same 1,000 words of content on their home page. Imagine that they look exactly alike as well. Now imagine that Website A was written by a competent web professional, and Website B was written by an amateur. Which will rank higher in an internet search?
The one with the better code-to-content ratio.
The WordPress import plugins are very helpful. Unfortunately, some clients have a LOT of blog posts to import, and the WP importer chokes on them. When that happens, you’ll often get this error:
Fatal error: Maximum execution time of 30 seconds exceeded…
Edit your wp-config.php file (in the top-level directory of your WordPress website). Right above the line that says That’s all, stop editing!, paste the following:
UPDATE: testing has revealed that data URIs are six times slower on mobile devices than simple images. Be aware that every situation may be different, and that you should make decisions based on YOUR website and YOUR clientele.
I spent some time this morning reading a good article about speeding up web pages by looking at their critical render path. It’s a good article, and I recommend it. It outlines a smart look at how web pages work.
One of the improvements that the author suggests is to remove your header image (for example, the logo at the top of your page). You would then encode the image as base64, reducing the time it takes to download. Sounds great, right? Not so fast!
Before you implement any changes to your own website, you must ask yourself an important question: does this apply to me? Suggestions like this one should be taken on a case-by-case basis. For example: the header on my personal blog weighs in at 94kb. That seems pretty big to me, but I haven’t optimized it. Here’s what it looks like:
When you convert that image to base64 (using an encoder like this one), it will look something like this:
…except that it goes on and on and on and on. Encoding an image into base64 means turning all of the visible bits into code bits. The idea is that you’ll reduce the amount of data your visitors will have to download. The problem? Encoding my own header image makes it larger! My header went from 94kb to around 120kb. That’s a 20% increase.
The lesson here is to avoid knee-jerk reactions about technical things. A lot of people might read this article and figure they should encode ALL of their images…but that could turn out to be bad instead of good. Test everything for yourself, on your own website. That’s the only way to know what will work best for you!
For most web designers, posting an image is a one-step process: you post an image, as-is. Because a lot of designers are very, very clever, it’s becoming clear that we can do much more. Here’s an image:
We display this with the following CSS:
background: url(http://straightstreetdesign.com/images/fish-tint.jpg) no-repeat 0 0;
How can we add some color to the photo using CSS? We typically add color to an element using background-color. Unfortunately, that won’t work here. While we can use multiple backgrounds in CSS3, we can’t use background-color that way.
Fortunately, we can use background gradients! If we code a semi-transparent gradient with only one color, it will tint our photo, like this:
background: linear-gradient(rgba(236, 254, 79, 0.3), rgba(236, 254, 79, 0.3)), url(http://straightstreetdesign.com/images/fish-tint.jpg) no-repeat 0 0;