"web performance" entries
Key insights from DevOps, Web operations, and performance.
People from across the Web operations and performance worlds are coming together this week for the 2015 O’Reilly Velocity Conference in Santa Clara. Below, we’ve assembled notable keynotes, interviews, and insights from the event.
Think like a villain
Laura Bell outlines a three-step approach to securing organizations — by putting yourself in the bad guy’s shoes (without committing actual crime, she stresses):
- Think like a villain and be objective: identify why and how someone would attack your company; what is the core value they’d come to steal?
- Create a safe place to create a little chaos: don’t do it live, but find a safe place without restriction and without fear to break things, to practice creative chaos.
- Play like you’ve never read the the rule book: Not everyone plays by the same rules as you, so to protect yourself and your company, you have to think more like the person willing to break the rules.
Hacking performance across your organization.
I’ve given Web performance talks where I get to show one of my favorite slides with the impact of third-party dependencies on load time. It’s the perfect use case for “those marketing people,” who overload pages with the tracking pixels and tags that make page load time go south. This, of course, would fuel the late-night pub discussrion with fellow engineers about how much faster the Web would be if those marketing people would attend a basic Web performance 101 course.
I’ve also found myself discussing exactly this topic in a meeting. This time, however, I was the guy arguing to keep the tracking code, although I was well aware of the performance impact. So what happened?
An introduction to multi-level caching.
Since a content delivery network (CDN) is essentially a cache, you might be tempted not to make use of the cache in the browser, to avoid complexity. However, each cache has its own advantages that the other does not provide. In this post I will explain what the advantages of each are, and how to combine the two for the most optimal performance of your website.
Why use both?
While CDNs do a good job of delivering assets very quickly, they can’t do much about users who are out in the boonies and barely have a single bar of reception on their phone. As a matter of fact, in the US, the 95th percentile for the round trip time (RTT) to all CDNs is well in excess of 200 milliseconds, according to Cedexis reports. That means at least 5% of your users, if not more, are likely to have a slow experience with your website or application. For reference, the 50th percentile, or median, RTT is around 45 milliseconds.
So why bother using a CDN at all? Why not just rely on the browser cache?
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.
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.
Cruftifying web pages is not what Velocity is about.
There’s been a lot said and written about web performance since the Velocity conference. And steps both forward and back — is the web getting faster? Are developers using increased performance to add more useless gunk to their pages, taking back performance gains almost as quickly as they’re achieved?
I don’t want to leap into that argument; Arvind Jain did a good job of discussing the issues at Velocity Santa Clara and in a blog post on Google’s analytics site. But, I do want to discuss (all right, flame) about one issue that bugs me.
I see a lot of pages that appear to load quickly. I click on a site, and within a second, I have an apparently readable page.
“Apparently,” however, is a loaded word because a second later, some new component of the page loads, causing the browser to re-layout the page, so everything jumps around. Then comes the pop-over screen, asking if I want to subscribe or take a survey. (Most online renditions of print magazines: THIS MEANS YOU!). Then another resize, as another component appears. If I want to scroll down past the lead picture, which is usually uninteresting, I often find that I can’t because the browser is still laying out bits and pieces of the page. It’s almost as if the developers don’t want me to read the page. That’s certainly the effect they achieve.
Benefits of a Velocity diet, data journalism's history, it's evolution time for booksellers.
This week on O'Reilly: We learned how the Velocity Conference site got a big makeover thanks to Velocity practices, Liliana Bounegru offered a brief history of data journalism, and Joe Wikert explained how booksellers can reinvent themselves.