A Pretty Website Isn't Enough
Tags: frontend, performance, devops, webperf
Published: 2020-02-14 22:59:08

---
title: A Pretty Website Isn't Enough
published: true
date: 2016-12-12 12:14:00 UTC
tags: frontend,performance,devops,webperf
canonical_url: https://nystudio107.com/blog/a-pretty-website-isnt-enough
---

# 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](https://nystudio107.com)

![Beauty](https://nystudio107-ems2qegf7x6qiqq.netdna-ssl.com/img/blog/_1200x675_crop_center-center_82_line/beauty.jpg)

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.

<aside>
                                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.
                            </aside>

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:

![Beauty Gpsi](https://nystudio107-ems2qegf7x6qiqq.netdna-ssl.com/img/blog/_1200x861_crop_center-center_100_line/beauty_gpsi.png)

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](https://dev.to/gaijinity/creating-optimized-images-in-craft-cms-2hc5-temp-slug-2354251) 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.

<aside>
                                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.
                            </aside>

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.

<aside>
                                A web­site is emphat­i­cal­ly not just a <span></span>​<span>“</span>dig­i­tal brochure.” Stop think­ing of it that way.
                            </aside>
## 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.

![Checkout Line](https://nystudio107-ems2qegf7x6qiqq.netdna-ssl.com/img/blog/_1200x675_crop_center-center_82_line/checkout-line.jpg)

Stud­ies have shown that 32% of con­sumers will start [aban­don­ing slow sites](https://blog.mozilla.org/metrics/2010/03/31/firefox-page-load-speed-part-i/) between one and five sec­onds. Bounce rate can be [improved by up to 30%](https://www.digitalrealty.com/blog/the-cost-of-latency/) with the reduc­tion of page size and result­ing speed improve­ments. [A one sec­ond delay](https://blog.kissmetrics.com/loading-time/?wide=1) 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](https://webmasters.googleblog.com/2010/04/using-site-speed-in-web-search-ranking.html) for the search engine results page (SERP). Check out the [Mod­ern SEO: Snake Oil vs. Sub­stance](https://nystudio107.com/blog/modern-seo-snake-oil-vs-substance) 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](https://docs.google.com/viewerng/viewer?url=https://storage.googleapis.com/doubleclick-prod/documents/The_Need_for_Mobile_Speed_-_FINAL.pdf), 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.

<aside>
                                Impress upon them that best look­ing design <span>&amp;</span> 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.
                            </aside>

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 <kbd>40/100</kbd> to <kbd>92/100</kbd> on [Google Page­Speed Insights](https://developers.google.com/speed/pagespeed/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 <kbd>92/100</kbd> rat­ing from Google; but show them how their com­peti­tor Bob’s Hard­ware down the street only gets <kbd>45/100</kbd>, 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.

<aside>
                                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.
                            </aside>

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.

<aside>
                                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.
                            </aside>

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.

<aside>
                                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.
                            </aside>

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](https://developers.google.com/web/tools/lighthouse/) — this com­bines a num­ber of per­for­mance, [pro­gres­sive WebApp](https://nystudio107.com/blog/service-workers-and-offline-browsing), 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](https://developers.google.com/speed/pagespeed/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](https://testmysite.thinkwithgoogle.com/) — 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](https://www.webpagetest.org/) — 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](https://gtmetrix.com/) — 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 <kbd>devops</kbd>-ish serv­er-side checks it runs.
- [W3C Markup Val­i­da­tion Ser­vice](https://validator.w3.org/) — 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](https://search.google.com/structured-data/testing-tool/u/0/) — 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](https://tools.pingdom.com/) — 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](https://securityheaders.io/) — 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](https://report-uri.io/home/tools) is use­ful for con­struct­ing these as well.
- [Twit­ter Card Val­ida­tor](https://cards-dev.twitter.com/validator) — 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](https://developers.facebook.com/tools/debug/) — 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](https://www.woorank.com/) — 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](https://www.ssllabs.com/ssltest/) — 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](https://tools.keycdn.com/http2-test) — ver­i­fy that your serv­er is prop­er­ly run­ning <kbd>http2</kbd> with <kbd>ALPN</kbd> 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](/blog) through [Google Page­Speed Insights](https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fnystudio107.com%2Fblog), you’ll see that it scores pret­ty well:

![Pagespeed Insights](https://nystudio107-ems2qegf7x6qiqq.netdna-ssl.com/img/blog/_768x700_crop_center-center_100_line/pagespeed_insights.png)

The arti­cle pages do a lit­tle less well, because the [Dis­qus](https://disqus.com/) 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](https://dev.to/gaijinity/google-amp-should-you-care-3din-temp-slug-933989) 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:

<aside>
                                Leave things a lit­tle bit bet­ter than how you found them.
                            </aside>

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](https://twitter.com/nystudio107) on Twitter._

<small>Copyright ©2020 nystudio107. Designed by nystudio107</small>