A Pretty Website Isn’t Enough

So you’ve designed a beau­ti­ful, func­tion­al web­site, and you’ve just fin­ished nail­ing down the last lit­tle 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 beau­ti­ful new web­site for a promi­nent brand, from a high-pro­file agency, only to be dis­ap­point­ed. Like some­one 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 web­site I saw in my Twit­ter feed; it was­n’t cher­ry-picked at all. I’ll see some­thing like this, and die a lit­tle inside. I have a rea­son­able idea of how much the client was charged for the site, and it makes me cringe:

The web­site design and UX is great; but the per­for­mance is not (they could def­i­nite­ly ben­e­fit from the Cre­at­ing Opti­mized Images in Craft CMS arti­cle). This tells me that either:

1. The devel­op­ers don’t know how to build a per­for­mant website
2. There is no QA process to eval­u­ate the web­site performance
3. There was no bud­get in the project for build­ing a per­for­mant website
4. The devel­op­ers know how to build a per­for­mant web­site, but they just don’t care

I’m going to try to address all four points in this arti­cle. And yes, an addi­tion­al pos­si­bil­i­ty is that they just ran out of time; but that’s usu­al­ly a result of a bro­ken process. First, how­ev­er, let’s dive into the mind­set that many tra­di­tion­al agen­cies are com­ing from.

Link It’s All About Perspective

It’s instruc­tive to under­stand the pedi­gree of tra­di­tion­al agen­cies. Their ori­gins are in the mar­ket­ing & print world, so their focus is on mes­sage & design. They view how the web­site is put togeth­er as an after­thought; the ​“real work” in design­ing the visu­als, brand­ing and UX is already done.

Think­ing about how a web­site is put togeth­er would be akin to them think­ing about the mechan­i­cal print process that hap­pens when their ads are sent to press. Sure, they’ll do a QA review to make sure it looks like their orig­i­nal design, but that’s as far as it goes.

This is incred­i­bly back­wards. Cre­at­ing a web­site is not a sim­ple mechan­i­cal process like rolling a page off of a print­ing press. You are not build­ing a sta­t­ic thing that just needs to be visu­al­ly appeal­ing 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.

Tra­di­tion­al agen­cies have unwit­ting­ly mor­phed — at least par­tial­ly — into soft­ware devel­op­ment com­pa­nies. And like many things that hap­pen by acci­dent rather than by design, most of them don’t under­stand how this busi­ness works, or even the fact that they are in this busi­ness. Often the ​“dig­i­tal team” is thought of as assem­bly line work­ers who con­struct the design the’ve been fed.

While I def­i­nite­ly appre­ci­ate beau­ti­ful design, and on-point mar­ket­ing mes­sages, they are only part of the equa­tion when it comes to build­ing a web­site. It’s impor­tant that you learn how to inte­grate usabil­i­ty test­ing, qual­i­ty assur­ance, and per­for­mance opti­miza­tion into your work­flow, and into your proposals.

These are the hall­marks of soft­ware engi­neer­ing. Which is what you are real­ly doing, folks.

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

Link Why Does It Matter?

The tech­ni­cal under­pin­nings of the web­site you’re build­ing mat­ter because, ulti­mate­ly, peo­ple are going to be using your web­site. And peo­ple don’t like to wait.

Think about the rise of the self-check­out line at gro­cery stores. Peo­ple are will­ing to do the work for gro­cery stores if it means that they check out quick­er. It’s pret­ty remark­able if you think about it, and offers com­pelling anec­do­tal evi­dence that peo­ple just don’t like to wait.

Stud­ies have shown that 32% of con­sumers will start aban­don­ing slow sites between one and five sec­onds. Bounce rate can be improved by up to 30% with the reduc­tion of page size and result­ing speed improve­ments. A one sec­ond delay in page load time can result in 11% few­er page views, 16% decreased cus­tomer sat­is­fac­tion and 7% lost conversions.

None of this should be ter­ri­bly sur­pris­ing. The dig­i­tal world has result­ed in an explo­sion of choice. When some­one on a mobile phone search­es for a restau­rant while scram­bling to get into an Uber, it’s per­haps under­stand­able that they will hit the back but­ton and move on to the next result if it’s slow to load.

This is why Google made page speed a rank­ing indi­ca­tor for the search engine results page (SERP). Check out the Mod­ern SEO: Snake Oil vs. Sub­stance arti­cle for more on the SEO implications.

Google’s goal isn’t just to return search results for the lit­er­al thing was searched on, it’s also to return what peo­ple want. And peo­ple want a web­site that responds quick­ly, espe­cial­ly on mobile.

Mobile devices are not just slow­er, with small­er screens, and high­er laten­cy cel­lu­lar data Inter­net con­nec­tions. They are also used in real-world cir­cum­stances where wait­ing and patience are just not an option. And giv­en that the major­i­ty of many web­site’s traf­fic 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 build­ing per­for­mance opti­miza­tion and QA into your web­site pro­pos­als. This is high­ly skilled, valu­able work, and you should be paid for it. It’s your job as a pro­fes­sion­al to edu­cate your clients on the impor­tance of per­for­mance, and what it means to them as far as con­ver­sions, user expe­ri­ence, and brand prestige.

I start by look­ing at the clien­t’s Google Ana­lyt­ics, and show­ing the client the amount of traf­fic that they are receiv­ing from mobile devices. Then I look at their bounce rates from var­i­ous pages, and see if there is a cor­re­la­tion between load times, and bounce rates. I then present this in a clear, con­cise man­ner to the client.

A doc­u­ment I’ve found use­ful is The Need for Mobile Speed, from Google them­selves (Google owns Dou­bleClick). Once you’ve sold them on the fact that per­for­mance mat­ters, the next step is to take per­for­mance bench­marks on their cur­rent web­site, and show them the very same bench­marks when you’ve com­plet­ed 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 web­site, they may not under­stand all of the tech­ni­cal things you’ve done, but they def­i­nite­ly will under­stand the pos­i­tive rat­ing from a brand they know and trust. When you take their site from 40/100 to 92/100 on Google Page­Speed Insights, that’s mea­sur­able progress that they can grok. And it makes the bean­coun­ters happy.

Anoth­er key thing to keep in mind is that many peo­ple who are in posi­tions of pow­er at a com­pa­ny are smart, com­pet­i­tive peo­ple. They are dri­ven to suc­ceed, and love to have a way to mea­sure how they are doing rel­a­tive to their com­pe­ti­tion. That’s why I also rec­om­mend doing com­pet­i­tive analy­sis show­ing them how Google says their site per­forms not just rel­a­tive to their for­mer web­site, but rel­a­tive to their competition.

It’s all well and good to show them a 92/100 rat­ing from Google; but show them how their com­peti­tor Bob’s Hard­ware down the street only gets 45/100, and you’ll real­ly be hit­ting the plea­sure cen­ters of their brain.

If they are plan­ning to pro­mote their web­site via a mar­ket­ing cam­paign, it also mer­its men­tion­ing that the effec­tive­ness of their mar­ket­ing dol­lars cor­re­lates direct­ly with the per­for­mance & expe­ri­ence that the web­site 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 pitch­es inter­nal­ly to your project man­agers, design team, copy­writ­ers, qual­i­ty assur­ance, and oth­ers before you’re able to get your clients onboard. A uni­fied front is often nec­es­sary for real progress. If you’re a free­lancer, well, take your­self out for a beer and schmooze.

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

Link Objective Testing is the Key

The way to cre­ate a per­for­mant web­site is through test­ing. You test, then you revise the web­site based on the test results, and re-test in a con­tin­u­ous feed­back loop. There are any num­ber of tests out there that will help us eval­u­ate our work in a deter­min­is­tic, objec­tive man­ner. This is actu­al­ly fan­tas­tic when you think about it; there’s no objec­tive test to tell a writer how good his sto­ry is, or a painter how beau­ti­ful their por­trait 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 web­site I work on is con­tin­u­ous­ly test­ed as part of the work­flow process. I don’t just run the tests as an after­thought, when the site is ​“fin­ished” because often by that point all you can do is shrug your shoul­ders as you look at the launch deadline.

Per­for­mant web­sites are born out of effec­tive work­flows. I can look at var­i­ous web­page test results, and have a pret­ty good idea of how the web­site was built just by look­ing at the results. You may be required to learn new process­es, uti­lize new tools, and rethink your work­flow in order to build web­sites that are performant. 

How­ev­er, that’s a mind­set issue as much as it is a skillset issue. Tech­nol­o­gy con­tin­u­al­ly and inex­orably march­es for­ward. What are the best prac­tices today will not be the best prac­tices sev­er­al years from now, or even next year. If you don’t keep up with it, some­one 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, with­out fur­ther ado, here are the tests that I use, and what I use them for. There is some over­lap between the tests, which is fine, but it’s impor­tant to under­stand what each tool is testing.

• Google Light­house — this com­bines a num­ber of per­for­mance, pro­gres­sive WebApp, and acces­si­bil­i­ty test­ing into one tool. You can down­load the Chrome exten­sion, or it’s also built into Chrome 60 or later.
• Google Page­Speed Insights — this pri­mar­i­ly mea­sures in-brows­er ren­der­ing per­for­mance, that is, how the web­page is deliv­ered to the client brows­er, and how long it takes it to ren­der once it is all there.
• Google Mobile-Friend­ly Web­site Test — tests the mobile friend­li­ness of your web­site, as well as the mobile per­for­mance of it. It cre­ates some very client-friend­ly result pages as well.
• Web­PageTest — this is incred­i­bly help­ful at mea­sur­ing time to first byte (TTFB), how long it takes before your web­site starts ren­der­ing, and the water­fall view shows you exact­ly how resources are deliv­ered. The fact that you can choose the device, brows­er, and loca­tion where the tests are run from make it invaluable.
• GTMetrix — these tests are pri­mar­i­ly help­ful for ensur­ing that you have the serv­er-side set­tings nailed. It tests oth­er things as well, but most valu­able to me are the devops-ish serv­er-side checks it runs.
• W3C Markup Val­i­da­tion Ser­vice — if our markup isn’t valid, there may be issues with it ren­der­ing in var­i­ous browsers, and it also may make it less like­ly that Goog­Bot et al will be able to parse and index your site well.
• Struc­tured Data Test­ing Tool — helps me val­i­date that all of the JSON-LD struc­tured data on the web­site is com­plete and correct.
• Ping­dom — anoth­er test­ing tool that lets you pick mul­ti­ple loca­tions to test from, and gives us a nice bul­let point­ed list of things we can improve upon from a per­for­mance POV.
• Secu­ri­ty­Head­ers — val­i­dates that we have set up our head­ers prop­er­ly from a secu­ri­ty POV, to guard against XSS attacks and the like. report-uri is use­ful for con­struct­ing these as well.
• Twit­ter Card Val­ida­tor — makes sure that our Twit­ter cards are set up right, and gives us a nice pre­view of how they will look to the end-user.
• Face­book Open Graph Debug­ger — val­i­dates the Open Graph meta tests on our web­site, and gives us a pre­view of how the data will look when shared on Facebook.
• WooRank — this is a paid SEO ser­vice that I use to mon­i­tor the effec­tive­ness of the site SEO, as well as mon­i­tor it on an ongo­ing basis. For clients who opt-in, I charge them to send them a month­ly WooRank report with analysis.
• SSL Serv­er Test — to ensure that your SSL cer­tifi­cates are prop­er­ly set up and not vul­ner­a­ble to known attack vectors.
• http/​2 Test — ver­i­fy that your serv­er is prop­er­ly run­ning http2 with ALPN supported.

If that seems like a long list, it is. But it does­n’t take much work to incor­po­rate them as part of your devel­op­ment & QA process.

Well, sure. I can hear you say. But not every project has the bud­get 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 web­site you’re view­ing right now adheres to the best prac­tices that these tests rec­om­mend. Hope­ful­ly you noticed that the web­site loaded quick­ly for you, and maybe that even made you smile.

But don’t take my word for it; feel free to run this web­site through the tests list­ed above. While it will not be per­fect, that isn’t the point. The point is that the tests were used as an iter­a­tive part of the devel­op­ment process, and act­ed upon appropriately.

If you run the blog index page through Google Page­Speed Insights, you’ll see that it scores pret­ty well:

The arti­cle pages do a lit­tle less well, because the Dis­qus com­ment­ing sys­tem 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 ver­sions of each blog entry, so that when they show up on the Google SERP, peo­ple will know they are get­ting a fast webpage.

In a future arti­cle, I’ll show you the nuts and bolts of how it’s done. Until then… when you build web­sites, 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 hap­py lit­tle campers.