Web Perf/Ops Posts
Building functionality that really delivers the expected customer value
By now, many of us are aware of the wide adoption of continuous delivery within companies that treat software development as a strategic capability that provides competitive advantage. Amazon is on record as making changes to production every 11.6 seconds on average in May of 2011. Facebook releases to production twice a day. Many Google services see releases multiple times a week, and almost everything in Google is developed on mainline. Still, many managers and executives remain unconvinced as to the benefits, and would like to know more about the economic drivers behind CD.
First, let’s define continuous delivery. Martin Fowler provides a comprehensive definition on his website, but here’s my one sentence version: Continuous delivery is a set of principles and practices to reduce the cost, time, and risk of delivering incremental changes to users.
Start with a baseline benchmark and measure continuously from there
The two most important tasks to ensure your site remains fast are benchmarking and iterating on your site’s page load time. Quick performance wins can be celebrated today, but the health of your site will thrive with routine check-ins and deliberately balancing performance and aesthetics.
Benchmarking Page Load Time
WebPagetest is many developers’ go-to tool for measuring performance. You can enter any live URL and choose a geographic location and which browser you want to test against. It’ll show you things like waterfalls, which diagram the images and other files that make up your total page load time and help you spot page load time issues.
Two additional tools that can analyze your site’s performance against a set of best practices and provides suggestions for improvement are YSlow and PageSpeed. As you get started with improving page load time, I recommend checking out all three of these tools to iron out performance basics on your site.
Design with mobile (and performance) in mind first
A recent study showed that mobile is the primary Internet access method for a vast number of global Internet users. Roughly 50% of Internet users in Africa and Asia are mobile-only, in contrast to 25% in the United States. This study called “mobile-only” users those who never or infrequently use the desktop Internet (though the study included tablets in the “desktop” category). The bottom line: lots of people are primarily using handsets to access the Internet, and these devices are so much slower than desktop machines.
Before a mobile device can transmit or receive data, it has to establish a radio channel with the network. This can take several seconds. The best part is, if there is no data transmitted or received, after a timeout the channel will go idle, which requires a new channel to be established. This can obviously wreak havoc on your web page load times.
On a typical United States desktop using WiFi, a request’s average round trip takes 50 milliseconds. On a mobile network, it’s over 300 milliseconds. This is as slow as old dial-up connections. Additionally, even WiFi is slower on handsets, thanks to antenna length and output power. This means you really need to prioritize performance as you optimize your site’s design for mobile devices.
Check for bad effects instead of suspicious traffic
Being a part of the security industry for many years, we loved to watch all of the traffic coming and going from a network or even the servers. There was never enough data and as security folks we wanted to watch every inbound and outbound packet, because, well, it could be malicious. We’d copy all of the traffic when necessary, sift through it, and try to find events that could be from hackers. We’d even throw tons of costly hardware at the problem just to review traffic in real-time. All of this was done to achieve one goal: find attacks before they entered the network and did damage.
Specifically, we would place sensors at key choke points in the network or places where we could see a great deal of the traffic. The sensors could be placed in what was called detection mode, where a copy of the data would be sent to the sensor, or in prevention mode, where all of the traffic would pass through the device. Either way, the sensor would review each packet, collection of packets, or user sessions against a set of known bad “signatures” or just try to identify anomalous behavior. The theory was very similar to anti-virus technology, where known bad packet flows would be detected and propagated to all customers. The industry worked so well at this they generated tens of thousands of signatures.
Efficient, reusable markup reduces development work while boosting page load time
Optimizing your markup can have a substantial impact on your site’s page load time. Bloated HTML leads to bloated CSS, and vice-versa. For example, during a semantics and reusability template cleanup, I was able to significantly reduce the file size of site-wide HTML, CSS, and stylesheet images.
I achieved this by simply renaming existing elements to have more semantic meaning and then removed unnecessary elements in the HTML (also known as divitis) to focus on reusability. Later in the same cleanup effort, I was able to cut CSS by 39% by removing unused selectors, combining and condensing styles, and normalizing the colors used across the site.
Optimizing images is likely the biggest win for performance on your site
[Ed note: This is the second in a series of posts on web design and performance. You can see the introductory post here.]
Images make up the majority of most sites’ page weight. Thanks to their size and the number of image requests made by an average site, optimizing images is arguably the easiest big win when it comes to improving your site’s page load time.
Let’s start by looking at the various image types available, and then work through the various options you have for optimizing them.
Efforts to optimize your site have an effect on the entire experience for your users
Think about how you search for things on the web. How quick are you to close a tab and go to the next search engine result if a site takes too long to load? Now consider doing that on your phone while waiting in line for your coffee order–you have even less time, so your expectations for a site to load quickly are even higher.
Web performance is user experience. Fast page load time builds trust in your site; it yields more returning visitors, more users choosing your site over a competitor’s site, and more people trusting your brand. Users expect pages to load in two seconds, and after three seconds, up to 40% of users will abandon your site. Similar results have been noted by major sites like Amazon, who found that 100 milliseconds of additional page load time decreased sales by one percent, and Google, who lost 20% of revenue and traffic due to half a second increase in page load time. Akamai has also reported that 75% of online shoppers who experience an issue such as freezing, crashing, taking too long to load, or having a convoluted checkout process will not buy from that site.
Web design trends often carry hefty performance costs
Web and mobile users continue to expect faster sites and apps–especially when it comes to mobile–and this year I’d like to see people who work on the web spend more time focusing on performance as a user experience priority instead of chasing trends.
I recently ran across this article in Forbes, which lists a number of web design goals/trends that Steve Cooper is eyeing for a site redesign of online magazine Hitched. My intention is not to pick on Hitched or Cooper per se, but the list is a molotov cocktail of potential performance woes:
- Continuous scrolling
- Responsive design
- Parallax sites
You can use most of those techniques without creating performance nightmares, but it is unfortunately rare. I feel like I’m living in an alternate reality where I’m hearing that users want simpler, faster sites, and yet the trends in web design are marching in the opposite direction.
Phil Dibowitz explains the challenges and the results they got with Chef
At OSCON, Phil Dibowitz reminded me how little I understand about large systems – as he puts it, really large systems, systems of systems, with some similarities but with different people controlling parts. His work at Facebook explores the challenges (and opportunities) of creating tools that work across a company’s many networks and computers.
If you deal with such challenges, he’s worth listening to as a model. If not, he’s worth listening to for a sense of just how different work at this scale can be, though much of what he accomplishes can be worthwhile at scales much smaller than the 17,000 servers he describes for Facebook at 26:42 in the session.
I talked with him in an interview:
and we’ve posted his OSCON session:
A Free Velocity Report
When I first started as a sysadmin many years ago, I quickly realized what a daunting task was before me. Like any good engineer, I took to finding the right tools to keep at hand to make light work out of the most difficult situations. This in itself was quite an endeavor, as over the years there has been a proliferation of tools and scripts. Many are of the artisanal, organic, hand-crafted variety, forged out of bash pipelines by our forefathers.
Much of that has changed now as the DevOps movement strengthens. With closer interaction between developers and operations, or even operations teams composed of developers, the tools have significantly improved. Treating infrastructure as code with automated configuration management and provisioning tools have freed many from the menial tasks of creating snowflake systems, and we’ve turned our attention to the more important matters of scaling and optimizing our systems.
In my Velocity report, 5 Unsung Tools of DevOps, I highlight a few of the tools that have gone unnoticed—or at least unrecognized—for some time. These are but a few of the tools that recognized needs early on and that successfully solve real-world problems that you’re likely to encounter today. Here is a brief synopsis: