Three Types of Performance

When it comes to website performance, articles often only look at some types of performance.

The three types are:

  1. Server Speed: How fast can my server get its files sent to the network?
  2. Network Speed: How fast can I get my stuff to your browser?
  3. Browser Speed: How fast can your computer and browser make those files work on your local machine?

Quickly, to unpack this, let’s talk about each briefly.

Server Speed

Server speed comprises a number of things. As a top-level overview, consider:

  • What machine (or machines) are our websites stored on? Dual-core, quad-core, what CPU, what kind of storage (SSD, HD), how much memory, etc? In other words, let’s talk about the actual hardware of the server.
  • What Operating System is the server running?
  • What web server is “serving” the actual pages (Apache, Nginx) and far more importantly, how is that server is configured?
  • What database software (DBMS) , if any, is being called, how many queries, where is it located, and how is it setup?
  • What company is doing the hosting?
  • What other loads and taxes are on the machine(s) doing the serving? (shared hosting vs VPS vs Dedicated?)
  • What back-end language and version is being used (PHP, Ruby, Python, ASP.Net, etc) and more importantly, how is it setup and optimized?
  • How optimized is the code that is running prior to the “serve”? In other words, even if you’re just using PHP to grab the current date to insert directly into an HTML document, is there a faster way to write that code?
  • Plugin bloat. Theme cruft. The server is trying to create a page to serve, but the code keeps coming, and coming, and coming.

Network Speed

This is most often the crux of most articles talking about optimization and performance enhancements, particularly for WordPress.

  • What resources are being used? How many? Why? How many HTTP connections?
  • How fast?
  • Offloading resources to either CDNs or an (assumptive) call to the browser’s cache (by using common resource locators for such things as javascript libraries).
  • What headers are being sent/accepted?
  • We need more expiry dates! No sour milk for us!
  • Minify! (Or is this a bit of a myth, really?)
  • What compression is allowed? Whaddya mean some hosts don’t allow GZIP for HTTPS sites? Broccoli! Kids hate broccoli!
  • Speaking of HTTPS, we should avoid it, right? Because we heard that SSL stands for SSLowly, right?
  • Is our web host truly enabling keep-alive?
  • Media queries! Let’s not serve images bigger than needed.
  • It’s your caching, Marty! Something’s gotta be done about your caching!
  • Wait. Caching? You mean PHP Object Caching? Or caching web pages to avoid database calls? Browser caching? Does CDN mean “Caching” Delivery Network or “Content” Delivery Network? What’s the difference? Argh!

Browser Speed

Some website performance articles, particularly related to WordPress, touch on a few things regarding browser speed.

But many of them ignore some critical elements.

Here’s some common advice you’ll hear (and it’s worth heeding, but it’s also incomplete).

  • Don’t block the render! (I feel like this should be a bumper sticker). Maybe with a crying Firefox fox.
  • All your fonts are belong to Google. Maybe less of them? The CPUs of your visitors are melting.

Aaaaand that’s pretty much it. That’s all you typically hear on this factor of browser speed.

Here’s something to consider. You have complete control, as a web development freelancer or agency, on Server Speed and Network Speed. Within your client’s budget, of course. Maybe they don’t want to pay $110/month for managed WP hosting, so there’s that of course.

But you do not have much control over what computer and browser visitors to your clients’ websites will be using.

It could be a 9-year old, Windows 7 laptop.

According to StatCounter, 35% of computers on the web are running Windows, and a whopping 32% of those are still running Windows XP and Windows 7.

Yes, that’s roughly one out of 10 users.

That doesn’t count those that managed to upgrade their older machines with newer Windows versions (but are choking anyway).

That doesn’t count the many cheap Android phones worldwide that couldn’t hold a candle to an iPhone 4, much less iPhone 8s and up.

You know who these people are (unless you live in San Francisco). They are the families you visit where you see the dusty “desktop” in the corner with a (still) CRT monitor on top, and papers and bills strewn nearby.

These are the people you do not see in cafes and airports because they wouldn’t dare try to bring, in public, their 8-pound laptop and its massive cord (now required because their aging battery only lasts 30 minutes). Best just to leave it at home as a quasi-desktop.

These are the folks riding the bus in developing countries talking on WhatsApp and trying to visit your website.

So, what can you do to help those people? Hint: it’s not about shims for aging browsers.

It’s about being performant in what you actually deliver to the user.

  • Is your first delivery (your HTML page) under 5Kb?
  • Is your HTML page filled with divs so deep and twisted that only an archeologist could unearth your text from them?
  • Do you have a class on every tag? What about a half-dozen classes on every tag?
  • Is your CSS file 3,000 lines? 1,000 lines? Are you giving visitors CSS on tags with which the browser will never have to style? Because those tags don’t exist?
  • Do browsers have to wrestle with 7 CSS files and try to incorporate which styles are cascading to what?
  • Do you have validation errors in your HTML? Are you requiring browsers to “calculate” best rendering? Or could you just make sure that your HTML code keeps browser cycles minimal? (Valid HTML renders faster, in most cases).
  • Is your Javascript completely necessary? (Even for modern browsers, could you instead use HTML5 and CSS?)

All of the above help to keep your website from causing your visitors’ computers to spin up their fan and suck out the battery juice from their laptops.

We have all been on websites which we know is causing our CPUs to melt. Now that Adobe Flash is dead, we are still seeing the power grid sucked dry with massive 28Kb HTML files, 3 Mbs of Javascript (which has to be computed and processed), and 5,000 lines of CSS spread out over a dozen files.

Modern browsers will now even warn that a certain tab is using too much energy and pause or shutdown some of the page.

I’ve been on websites of major news and product companies only to have the page continual reload, crash, or just never fully render.

There is zero excuse for this. Well, except developer laziness. Not that any one developer is at fault. But the concerted silence and lack of developer resistance to these frameworks all has led to it.

When you look through most theme directories, what do you see? “Built on the latest Bootstrap with a modern UI and a plethora of slider options, icon fonts, and Google fonts”… for a marketing landing page. Really?

Focus on all 3 Performance Optimizations

Don’t just focus on network and server optimizations.

I’ll tell you one other secret reason why. They are becoming, and soon will be, completely automated.

That’s right. You won’t need to go read all those optimization articles anymore. Eventually, WordPress (or some other platform) will get it right.

Already, most build tools automate much of the tips in the first two sections. Hosts are wising up and offering much of this out of the box, too.

What’s the one thing they can not automate (i.e. replace you with robots)?

Proper coding of your websites.

Start with your HTML. Make it beautiful, readable, organized, and lovely even without CSS or Javascript or images.

Clean up your CSS (or, gasp, write it from scratch when possible).

Avoid unnecessary Javascript.

Test, fix, clean, test some more.

Focus on your enduser experience. Keep pushing the envelope.

And seriously think about every modal popup you allow. I’ve never met a performant popup that could do everything a stand-alone page could.

Leave a Reply

Your email address will not be published. Required fields are marked *