Web Perf/Ops Posts
Report from the DevOps Conference
There is a growing movement in the tech world, which over the past couple of years—and even more so in the past few months—has gained significant momentum and is changing the way organizations operate and do business. Much like the industrial revolution, there is a push to increase production speeds through automation and streamlined work processes. The only difference is that now the product is virtual. The movement is called DevOps, and while early adopters are already reaping the benefits of this methodology, it is quickly becoming not only an advantage for businesses, but a necessity.
A holistic approach to hiring for in-demand positions
Traditional recruiting is broken. The biggest problem is that goals and incentives of candidates, hiring managers, and recruiters are often misaligned. For instance, taken to the extreme, a headhunter’s best candidate is one who survives at a new job just long enough to collect the finder’s fee before being placed at another company. Clearly, this puts the recruiter at odds with both the candidate and the hiring manager.
The current unemployment rate for “computer and mathematical occupations” is 2.9%. It’s been dropping, and is now lower than the 4% level that is considered “full employment.” This means that every software engineer, database administrator, and “DevOps engineer” who wants to work—and, apparently, some who don’t—are all gainfully employed. Not surprisingly, salaries are also going up.
Given this information, it’s easy to get caught up in the hysteria of the so-called “war for talent,” with its violent language of “headhunting” and “poaching.” A natural reaction to this situation might be to have more recruiters send even more unsolicited emails to candidates through LinkedIn. However, this default recruiting tactic has diminishing returns: the higher the volume of recruiter spam on LinkedIn, the more engineers will ignore it or delete their profiles altogether.
Is there another way?
Rethinking CSS delivery
After the improvements, I thought it was time to move on but PageSpeed Insights advised there was more work to do.
Here are the WebPageTest results from my last article:
Eyes Above the Fold
PageSpeed Insights has helpful tips on optimizing your CSS delivery. Their rules suggest inlining critical Above-the-Fold (ATF) CSS rather than keeping all the CSS as an external resource. In addition, any Below-the-Fold (BTF) CSS can be deferred until after the ATF content has loaded.
The importance of network architecture on the Internet of Things
There are a lot of moving parts in the networking for the Internet of Things; a lot to sort out between WiFi, WiFi LP, Bluetooth, Bluetooth LE, Zigbee, Z-Wave, EnOcean and others. Some standards are governed by open, independent standards bodies, while others are developed by a single company and are being positioned as defacto standards. Some are well established, others are in the early adoption stage. All were initially developed to meet unique application-specific requirements such as range, power consumption, bandwidth, and scalability. Although these are familiar issues, they take on a new urgency in IoT networks.
To begin establishing the right networking technology for your application, it is important to first understand the network architecture, or the network topology, that is supported by each technology standard. The networking standards being used today in IoT can be categorized into three basic network topologies; point-to-point, star, and mesh.
The following figure illustrates these three topologies followed by a deeper discussion of each.
Network technologies appropriate for Internet of Things
An application developer has to consider numerous networking attributes when choosing a wireless network. The following five can help you understand the characteristics, capabilities, and behavior of the three topologies.
One source does not fit all
Like a lot of web teams, O’Reilly’s web group has increased its focus on using global components to better scale maintenance and optimize workflow. From a load-time measurement perspective, our performance ratings stay near benchmarks. However, after a recent analysis, using metrics other than load time, we found that our global efforts may have sacrificed performance on a handful of highly visible and heavily visited web pages.
Identifying the popular pages, we sought to improve the use of global components with server side logic, regex, and asynchronous loading. After re-measuring these popular pages, we arrived at faster load times with improved perception of speed.
Taking a closer look
After the Velocity 2014 site was produced, I got the following results from PageSpeed Insights and Webpagetest (WPT) while testing the homepage. These results are close to our average benchmarks for load time but revealed further elements to fix.
PageSpeed Insights pointed out render-blocking scripts and advised how I can optimize CSS delivery. WPT provided a visual UI to demonstrate the user’s perception of speed and gave me an average load time and start render time. Together, these tools gave many angles of approach to improving load times and the perception of speed.
Even though the load and start render times from WPT weren’t bad, the PageSpeed Insights score demonstrated that further improvements could be made.
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.