A Pretty Website Isn’t Enough

Your job is not done when you’ve cre­at­ed a beau­ti­ful, well-designed, up-to-spec web­site. It’s only just begun

Andrew Welch / nystudio107

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 togeth­er, as well as the per­for­mance char­ac­ter­is­tics of the web­site, not just the beau­ti­ful 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.

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 build­ing a web­site, you’re actu­al­ly build­ing a very spe­cial­ized, cus­tom soft­ware app. Unlike print or video ads, you need to be con­cerned with acces­si­bil­i­ty, per­for­mance, 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 web­site is emphat­i­cal­ly not just a ​“dig­i­tal brochure.” Stop think­ing of it that way.

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.

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 look­ing design & wit­ti­est mar­ket­ing mes­sage mean absolute­ly noth­ing if the user nev­er sees it. The slow­er your web­site is, the more like­ly 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.

Dump­ing a pile of mon­ey into pro­mot­ing a web­site that isn’t per­for­mant is like run­ning a mas­sive pro­mo­tion for a restau­rant that has only one serv­er attend­ing to all of the tables. No mat­ter how tasty the food is, some peo­ple 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?

Objec­tive Test­ing 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 impor­tant to under­stand that we’re not just try­ing to do well on the tests to get a good score. We’re try­ing to do well on the tests because they give us mean­ing­ful, action­able feed­back 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.

Addi­tion­al­ly, once per­for­mance is part of your work­flow, it isn’t any hard­er to pro­duce per­for­mant 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.

Eat­ing 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 lit­tle bit bet­ter than how you found them.

That will make both you and your clients hap­py lit­tle campers.

Further Reading

If you want to be notified about new articles, follow nystudio107 on Twitter.

Copyright ©2020 nystudio107. Designed by nystudio107