Andrew Welch

Andrew Welch · Insights · #frontend #performance #devops

Making the web better one site at a time, with a focus on performance, usability & SEO

· 5 min read ·

A Pretty Website Isn’t Enough

Your job is not done when you’ve created a beautiful, well-designed, up-to-spec website. It’s only just begun


So you’ve designed a beautiful, functional website, and you’ve just finished nailing down the last little bit of it. Your client is thrilled with how it looks, so you’re ready to ship it, right? Not even close.

I can’t tell you how many times I’ve checked out a beautiful new website for a prominent brand, from a high-profile agency, only to be disappointed. Like someone who has seen how sausage is made, I don’t look at things the same way anymore.

I’m ruined, because I look at how a site was put together, as well as the performance characteristics of the website, not just the beautiful design and user experience.

This is from a recent website I saw in my Twitter feed; it wasn’t cherry-picked at all. I’ll see something like this, and die a little inside. I have a reasonable idea of how much the client was charged for the site, and it makes me cringe:

Beauty Gpsi

The website design and UX is great; but the performance is not (they could definitely benefit from the Creating Optimized Images in Craft CMS article). This tells me that either:

  1. The developers don’t know how to build a performant website
  2. There is no QA process to evaluate the website performance
  3. There was no budget in the project for building a performant website
  4. The developers know how to build a performant website, but they just don’t care

I’m going to try to address all four points in this article. And yes, an additional possibility is that they just ran out of time; but that’s usually a result of a broken process. First, however, let’s dive into the mindset that many traditional agencies are coming from.

Link It’s All About Perspective

It’s instructive to understand the pedigree of traditional agencies. Their origins are in the marketing & print world, so their focus is on message & design. They view how the website is put together as an afterthought; the “real work” in designing the visuals, branding and UX is already done.

Thinking about how a website is put together would be akin to them thinking about the mechanical print process that happens when their ads are sent to press. Sure, they’ll do a QA review to make sure it looks like their original design, but that’s as far as it goes.

This is incredibly backwards. Creating a website is not a simple mechanical process like rolling a page off of a printing press. You are not building a static thing that just needs to be visually appealing and on-message.

When you’re building a website, you’re actually building a very specialized, custom software app. Unlike print or video ads, you need to be concerned with accessibility, performance, and user experience.

Traditional agencies have unwittingly morphed—at least partially—into software development companies. And like many things that happen by accident rather than by design, most of them don’t understand how this business works, or even the fact that they are in this business. Often the “digital team” is thought of as assembly line workers who construct the design the’ve been fed.

While I definitely appreciate beautiful design, and on-point marketing messages, they are only part of the equation when it comes to building a website. It’s important that you learn how to integrate usability testing, quality assurance, and performance optimization into your workflow, and into your proposals.

These are the hallmarks of software engineering. Which is what you are really doing, folks.

A website is emphatically not just a “digital brochure.” Stop thinking of it that way.

Link Why Does It Matter?

The technical underpinnings of the website you’re building matter because, ultimately, people are going to be using your website. And people don’t like to wait.

Think about the rise of the self-checkout line at grocery stores. People are willing to do the work for grocery stores if it means that they check out quicker. It’s pretty remarkable if you think about it, and offers compelling anecdotal evidence that people just don’t like to wait.

Checkout Line

Studies have shown that 32% of consumers will start abandoning slow sites between one and five seconds. Bounce rate can be improved by up to 30% with the reduction of page size and resulting speed improvements. A one second delay in page load time can result in 11% fewer page views, 16% decreased customer satisfaction and 7% lost conversions.

None of this should be terribly surprising. The digital world has resulted in an explosion of choice. When someone on a mobile phone searches for a restaurant while scrambling to get into an Uber, it’s perhaps understandable that they will hit the back button and move on to the next result if it’s slow to load.

This is why Google made page speed a ranking indicator for the search engine results page (SERP). Check out the Modern SEO: Snake Oil vs. Substance article for more on the SEO implications.

Google’s goal isn’t just to return search results for the literal thing was searched on, it’s also to return what people want. And people want a website that responds quickly, especially on mobile.

Mobile devices are not just slower, with smaller screens, and higher latency cellular data Internet connections. They are also used in real-world circumstances where waiting and patience are just not an option. And given that the majority of many website’s traffic is from mobile devices, they are ignored at your own peril.

Link It Starts with the Proposal

So how do we do it? The first step is building performance optimization and QA into your website proposals. This is highly skilled, valuable work, and you should be paid for it. It’s your job as a professional to educate your clients on the importance of performance, and what it means to them as far as conversions, user experience, and brand prestige.

I start by looking at the client’s Google Analytics, and showing the client the amount of traffic that they are receiving from mobile devices. Then I look at their bounce rates from various pages, and see if there is a correlation between load times, and bounce rates. I then present this in a clear, concise manner to the client.

A document I’ve found useful is The Need for Mobile Speed, from Google themselves (Google owns DoubleClick). Once you’ve sold them on the fact that performance matters, the next step is to take performance benchmarks on their current website, and show them the very same benchmarks when you’ve completed your work.

Impress upon them that best looking design & wittiest marketing message mean absolutely nothing if the user never sees it. The slower your website is, the more likely it is the user will not wait for it to load.

When you can show a client that Google says they have a good website, they may not understand all of the technical things you’ve done, but they definitely will understand the positive rating from a brand they know and trust. When you take their site from 40/100 to 92/100 on Google PageSpeed Insights, that’s measurable progress that they can grok. And it makes the beancounters happy.

Another key thing to keep in mind is that many people who are in positions of power at a company are smart, competitive people. They are driven to succeed, and love to have a way to measure how they are doing relative to their competition. That’s why I also recommend doing competitive analysis showing them how Google says their site performs not just relative to their former website, but relative to their competition.

It’s all well and good to show them a 92/100 rating from Google; but show them how their competitor Bob’s Hardware down the street only gets 45/100, and you’ll really be hitting the pleasure centers of their brain.

If they are planning to promote their website via a marketing campaign, it also merits mentioning that the effectiveness of their marketing dollars correlates directly with the performance & experience that the website delivers.

Dumping a pile of money into promoting a website that isn’t performant is like running a massive promotion for a restaurant that has only one server attending to all of the tables. No matter how tasty the food is, some people are going to be turned off.

You may also need to make these pitches internally to your project managers, design team, copywriters, quality assurance, and others before you’re able to get your clients onboard. A unified front is often necessary for real progress. If you’re a freelancer, well, take yourself out for a beer and schmooze.

So, okay, we’ve got the job, our team has our back, and we sold our client on performance. How do we do it?

Link Objective Testing is the Key

The way to create a performant website is through testing. You test, then you revise the website based on the test results, and re-test in a continuous feedback loop. There are any number of tests out there that will help us evaluate our work in a deterministic, objective manner. This is actually fantastic when you think about it; there’s no objective test to tell a writer how good his story is, or a painter how beautiful their portrait is.

It’s important to understand that we’re not just trying to do well on the tests to get a good score. We’re trying to do well on the tests because they give us meaningful, actionable feedback on how to improve our websites.

Every website I work on is continuously tested as part of the workflow process. I don’t just run the tests as an afterthought, when the site is “finished” because often by that point all you can do is shrug your shoulders as you look at the launch deadline.

Performant websites are born out of effective workflows. I can look at various webpage test results, and have a pretty good idea of how the website was built just by looking at the results. You may be required to learn new processes, utilize new tools, and rethink your workflow in order to build websites that are performant.

However, that’s a mindset issue as much as it is a skillset issue. Technology continually and inexorably marches forward. What are the best practices today will not be the best practices several years from now, or even next year. If you don’t keep up with it, someone else will, and the sought-after skills are ones that are not commodity.

Additionally, once performance is part of your workflow, it isn’t any harder to produce performant sites. It’s just what you do.

So, without further ado, here are the tests that I use, and what I use them for. There is some overlap between the tests, which is fine, but it’s important to understand what each tool is testing.

  • Google Lighthouse - this combines a number of performance, progressive WebApp, and accessibility testing into one tool. You can download the Chrome extension, or it’s also built into Chrome 60 or later.
  • Google PageSpeed Insights - this primarily measures in-browser rendering performance, that is, how the webpage is delivered to the client browser, and how long it takes it to render once it is all there.
  • Google Mobile-Friendly Website Test - tests the mobile friendliness of your website, as well as the mobile performance of it. It creates some very client-friendly result pages as well.
  • WebPageTest - this is incredibly helpful at measuring time to first byte (TTFB), how long it takes before your website starts rendering, and the waterfall view shows you exactly how resources are delivered. The fact that you can choose the device, browser, and location where the tests are run from make it invaluable.
  • GTMetrix -  these tests are primarily helpful for ensuring that you have the server-side settings nailed. It tests other things as well, but most valuable to me are the devops-ish server-side checks it runs.
  • W3C Markup Validation Service - if our markup isn’t valid, there may be issues with it rendering in various browsers, and it also may make it less likely that GoogBot et al will be able to parse and index your site well.
  • Structured Data Testing Tool - helps me validate that all of the JSON-LD structured data on the website is complete and correct.
  • Pingdom - another testing tool that lets you pick multiple locations to test from, and gives us a nice bullet pointed list of things we can improve upon from a performance POV.
  • SecurityHeaders - validates that we have set up our headers properly from a security POV, to guard against XSS attacks and the like. report-uri is useful for constructing these as well.
  • Twitter Card Validator - makes sure that our Twitter cards are set up right, and gives us a nice preview of how they will look to the end-user.
  • Facebook Open Graph Debugger - validates the Open Graph meta tests on our website, and gives us a preview of how the data will look when shared on Facebook.
  • WooRank - this is a paid SEO service that I use to monitor the effectiveness of the site SEO, as well as monitor it on an ongoing basis. For clients who opt-in, I charge them to send them a monthly WooRank report with analysis.
  • SSL Server Test - to ensure that your SSL certificates are properly set up and not vulnerable to known attack vectors.
  • http/2 Test - verify that your server is properly running http2 with ALPN supported.

If that seems like a long list, it is. But it doesn’t take much work to incorporate them as part of your development & QA process.

Well, sure. I can hear you say. But not every project has the budget for this type of thing. And that’s true. But don’t you want to work on the ones that do? You will become what you do.

Link Eating My Own Dogfood

The website you’re viewing right now adheres to the best practices that these tests recommend. Hopefully you noticed that the website loaded quickly for you, and maybe that even made you smile.

But don’t take my word for it; feel free to run this website through the tests listed above. While it will not be perfect, that isn’t the point. The point is that the tests were used as an iterative part of the development process, and acted upon appropriately.

If you run the blog index page through Google PageSpeed Insights, you’ll see that it scores pretty well:

Pagespeed Insights

The article pages do a little less well, because the Disqus commenting system I’m using adds some JavaScripts that ding the score, but it’s still in the mid-90’s, which is great. There are also Google AMP versions of each blog entry, so that when they show up on the Google SERP, people will know they are getting a fast webpage.

In a future article, I’ll show you the nuts and bolts of how it’s done. Until then… when you build websites, try to adhere to the camper’s motto:

Leave things a little bit better than how you found them.

That will make both you and your clients happy little campers.

${ category } · ${ blog.postDate }

${ blog.title }

#${ tag.title }