Web Performance Matters

The Cost of Poor Performance

Web obesity, slow downloads, and poor performance hit everyone—site users, online business owners, and even those who’ve never accessed the Web.

User Costs

At the start of 2020, the average web page comprises:

• 27KB of HTML content
• 64KB of CSS split over seven style sheets
• four fonts, totaling 122KB
• 410KB of JavaScript in 20 source files
• 31 images, requiring 980KB of bandwidth (a third of these are off screen and may never be viewed!)

The total: 1,940KB of data made over 74 HTTP requests, which takes seven seconds to fully appear on the average user’s desktop worldwide. This increases to a frustrating 20 seconds on mobile devices. (Source: HTTP Archive, which analyzes five million popular content websites.)

Downloading this web page on a typical mobile phone costs US users $0.20. Those browsing in Vanuatu, Mauritania, and Madagascar pay more than 1% of their daily income for the privilege of viewing a single page—despite it containing a mere 27KB of potentially readable content. (Source: whatdoesmysitecost.com.)

Business Costs

Slow, bloated pages are bad for business:

1. The larger the page download, the slower the user experience, and the less likely that person will consider making a purchase or returning.
2. 55% of visitors use a mobile device. These have more limited capabilities and may be connected to a slower network, which exacerbates the problem. (Source: statcounter.com.)
3. Google’s page speed algorithms downgrade slower sites, which harms search engine optimization efforts.
4. More data results in higher hosting, storage, and bandwidth costs.
5. The larger your codebase, the longer it takes to update and maintain.

Environmental Costs

The Internet consumes 420TWh— or up to 10% —of the world’s electricity consumption. This accounts for 4% of global greenhouse gas emissions, which is comparable to the aviation industry. Taking the web infrastructure and traffic into account, a single page load is estimated to emit 1.3g of CO². (Source: websitecarbon.com.)

While the Web has reduced energy use by providing a virtual alternative to travel and postage, those 1MB hero images still have an environmental impact.

The Reason for the Woeful Web

How have badly performing sites become ubiquitous when they cost more money to run, receive fewer visitors, and decrease conversions?

The main reason: performance is a lower priority compared to other features.

It’s easy to add more stuff. Optimizing or removing unnecessary junk is more difficult. We fear breaking the site or visitor usage patterns, so it becomes easier to make excuses for not addressing performance.

Excuse #1: “We Don’t Have a Performance Problem!”

Are you using the latest PC or smartphone on a fast network? Try a mid-range, two-year-old device. Try limiting bandwidth to your country’s average speed. Try using your site on a VPN or hotel Wi-Fi.

Excuse #2: “Our Users Never Complain?”

Possibly because they abandon your site and never return. Few people bother to make a complaint when competing content and services are a few clicks away.

Excuse #3: “Our Users Have High-end Devices”

This presumption becomes a self-fulfilling prophecy when a site can only be viewed by those with a recent device on a fast connection.

Would your revenues increase if more people could access your service? Are you considering explosive web growth in markets such as Asia, Africa, and South America, where smartphone and network capacity may be more limited?

Excuse #4: “Our Customers Use Modern Browsers”

There’s a common myth that 1% of users disable JavaScript or block other browser features such as images or CSS—for example, those using screen readers. This could be a considerable number, yet it’s used as an excuse to discriminate against certain groups in order to make development easier and avoid addressing performance on less capable devices.

In reality, it’s not 1% of users blocking assets, but 1% of visits. Every user will eventually encounter a situation where something breaks, such as when:

• one or more files fail to download
• firewalls or ISPs block certain assets
• a screen reader or older device is used
• the browser doesn’t support specific features
• a browser extension blocks, breaks, or modifies code
• the browser disables JavaScript on slow connections

It is possible to build robust, high-performance applications that can cope with these situations. Does yours?

Excuse #5: “We’ll Address Performance Later”

Premature optimization is the root of all evil.

This quote is attributed to Donald Knuth, from his paper “Structured Programming with go to Statements”. It relates to programmers wasting time on efficiencies that aren’t an immediate problem—such as a small start-up trying to ensure their application scales to millions of users.

The full quote in context:

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

Before you reach millions of users, you need to ensure the first few dozen people want to use your product. Back-end server or database inefficiencies are unlikely to be a major issue in the early days.

However, front-end performance can make or break an application. It could be part of your “critical 3%”, and it’s easier to address optimization from the start.

Excuse #6: “Some Systems Require More Bandwidth and Processing”

Complex web apps such as Gmail, maps, social networks, games, and image galleries will require more bandwidth and processing capacity than content websites. Performance remains a critical issue, but a higher page weight and slower load time can be expected.

However, the HTTP Archive crawls articles and online shops. It’s not looking at web applications. The average 2MB website page weight is the equivalent of half of all Shakespeare’s plays, or the 1993 disk-based distribution of DOOM — on a single page often containing only a few paragraphs of content. There’s little excuse for not addressing performance.

Excuse #7: “Expanding Page Weight is the Price of Progress”

This may be true for some edge cases. However, developers strived to keep pages under 100KB during the dial-up days of the late 1990s. Has web content become 20x better or faster since that time?

Excuse #8: “Slimming Pages Means Dumbing Down, with Fewer Features and Effects”

Performance can often be improved with minimal effort and no loss of functionality.

You can do more with less as web browsers evolve. Consider the CSS3 border-radius property: adding rounded corners now requires a few bytes of code compared to the multiple image shenanigans of a decade ago.

Excuse #9: “Improving Performance Increases Complications and Maintenance”

Removing unused or unnecessary images, videos, fonts, CSS, and JavaScript will simplify your site. It should result in fewer complications and less maintenance.

Excuse #10: “Our Client is Happy!”

Clients employ you for your expertise, and pitching optimization as a selling point will differentiate your business from others.

Web performance is an essential part of a web developer’s job. A little effort can reap considerable rewards for everyone:

• less code is required
• users receive a slicker experience
• search engine rankings improve
• conversions increase
• hosting costs decrease

No one will criticize you for building a super-fast, responsive site!

Where do I Start?

The next chapter introduces tools to help you identify issues. This is followed by a delicious buffet of food-inspired chapters:

Chapter 3: Quick Snacks A selection of simple, practical, cost-effective performance solutions that can be implemented on any site in minutes.

Chapter 4: Simple Recipes Some more complex development options that may take a few hours or days to implement but could have a larger positive impact.

Chapter 5: Life-changing Diets More radical development considerations and techniques that are best adopted from the start of your project.

Page weight reduction and optimization tips are generally grouped into similar concepts, with the easiest or most beneficial covered first.

Those attempting to improve an existing site should read each chapter in order. Those starting a new project may benefit from reading the chapters in reverse order, since more radical approaches then become viable.