ENTRIES TAGGED "performance"
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.
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.
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.
Velocity 2013 Speaker Series: Focus on Web Apps, Not Web Pages
We’re not making web pages anymore; we’re building web applications. Gone are the days of a few script tags in the <
head>. Apps today are a complex web of asynchronously-loaded content and functionality. In the past decade, we’ve progressed from statically-loaded HTML to AJAX-ifying all the things. However, the way we’ve been measuring real user performance of our apps hasn’t changed to reflect our new state of art.
At what point during page load do users consider an app to be “ready enough” to start using? If we use standard performance metrics, we have to choose one of the following:
1) When the HTML document has been completely loaded and parsed, but before stylesheets, images, and subframes have finished loading (
2) When all synchronous scripts, stylesheets, images, and subframes have finished loading (
If we pick
DOMContentLoaded, it quickly becomes clear that there’s no inherent correlation between the app state at that point and what a user would consider “ready.”
Velocity 2013 Speaker Series
You wake up one morning to discover your team has gotten a dreaded alert: your web application is performing badly. You dig through your code, but don’t see anything that stands out, until you open up Chrome’s memory performance tools, and see this:
One of your co-workers chuckles, because they realize that you’ve got a memory-related performance problem.
These blinders derail Drew Crawford’s detailed rant on Why mobile web apps are slow. It turns out that “slow for what?” is a key part of the question, as Crawford reveals near the very end:
It may also be true that the browser vendors have optimized their performance as far as they can, at least in the relatively stable fields of HTML parsing and processing, and CSS selectors and formatting. Adding
So how can we optimize mobile web development?
Velocity 2013 Speaker Series
One important thing that shapes the overall single-page application performance is instrumentation of the application code. The most obvious use-case is for analyzing code coverage, particularly when running unit tests and functional tests. Code that never gets executed during the testing process is an accident waiting to happen. While it is unreasonable to have 100% coverage, having no coverage data at all does not provide a lot of confidence. These days, we are seeing easy-to-use coverage tools such as Istanbul and Blanket.js become widespread, and they work seamlessly with popular test frameworks such as Jasmine, Mocha, Karma, and many others.
Instrumented code can be leveraged to perform another type of analysis: run-time scalability. Performance is often measured by the elapsed time, e.g. how long it takes to perform a certain operation. This stopwatch approach only tells half of the story. For example, testing the performance of sorting 10 contacts in 10 ms in an address book application doesn’t tell anything about the complexity of that address book. How will it cope with 100 contacts? 1,000 contacts? Since it is not always practical to carry out a formal analysis on the application code to figure out its complexity, the workaround is to figure out the empirical run-time complexity. In this example, it can be done by instrumenting and monitoring a particular part of the sorting implementation—probably the “swap two entries” function—and watch the behavior with different input sizes.
DevOps is as much about culture as it is about tools.
Operations professionals live in a wind tunnel. If you can imagine one of those game show glass boxes, where a contestant stands inside, the door shuts, and money blows around in a whirlwind, you’ve got a good idea of what Operations feels like much of the time. While you’re trying to grab one technology, another has forced itself across your eyes demanding attention.
The incredible growth of an industry that didn’t really even exist fifteen years ago has provided us with endless opportunity and innovations. It’s also required us to be on the forefront of many new technologies in a way other professions aren’t. The constant drive towards the next technology, the next platform, and the next idea has stratified our organizations, creating specializations in areas like networking, storage, security, data sciences, and a myriad of other functions that challenge our ability to work with our colleagues as a cohesive team.
Cultural shifts and handling large-scale growth among the emerging trends in the WPO and DevOps communities
More than 700 performance and operations engineers were in London last week for Velocity Europe 2012. Below, Velocity co-chairs Steve Souders and John Allspaw note high-level themes from across the various tracks (especially the hallway track) that are emerging for the WPO and DevOps communities.
Performance themes from Steve Souders
I was in awe of the speaker and exhibitor lineup going into Velocity Europe. It was filled with knowledgeable gurus and industry leaders. As Velocity Europe unfolded a few themes kept recurring, and I wanted to share those with you.
Performance matters more — The places and ways that web performance matters keeps growing. The talks at Velocity covered desktop, mobile (native, web, and hybrid), tablet, TV, DSL, cable, FiOS, 3G, 4G, LTE, and WiMAX across social, financial, ecommerce, media, games, sports, video, search, analytics, advertising, and enterprise. Although all of the speakers were technical, they talked about how the focus on performance extends to other departments in their companies as well as the impact performance has on their users. Web performance has permeated all aspects of the web and has become a primary focus for web companies. Read more…
Web ops and performance questions with Schlomo Schapiro.
A profile of web operations and performance expert Schlomo Schapiro, systems architect and open source evangelist at ImmobilienScout24.