- Learn to Search — cheeky but spot-on help for people running conferences.
- Offline First — no, the mobile connectivity/bandwidth issue isn’t just going to solve itself on a global level anywhere in the near future. THIS!
- 10 Things You Should Know About AWS — lots of specialist tips for hardcore AWS users.
- The League of Moveable Type — AWESOME FONTS. Me gusta.
Rethinking CSS delivery
After the improvements, I thought it was time to move on but PageSpeed Insights advised there was more work to do.
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. Read more…
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.
Help Searching, Offline First, AWS Tips, and Awesome Fonts
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.
Modern Security Ethics, Punk'd Chinese Cyberwarriors, Web Tracing, and Lightweight Server OS
- White Hat’s Dilemma (Google Docs) — amazeballs preso with lots of tough ethical questions for people in the computer field.
- Chinese Hacking Team Caught Taking Over Decoy Water Plant (MIT Tech Review) — Wilhoit went on to show evidence that other hacking groups besides APT1 intentionally seek out and compromise water plant systems. Between March and June this year, 12 honeypots deployed across eight different countries attracted 74 intentional attacks, 10 of which were sophisticated enough to wrest complete control of the dummy control system.
- Web Tracing Framework — Rich tools for instrumenting, analyzing, and visualizing web apps.
- CoreOS — Linux kernel + systemd. That’s about it. CoreOS has just enough bits to run containers, but does not ship a package manager itself. In fact, the root partition is completely read-only, to guarantee consistency and make updates reliable. Docker-compatible.
Security Sensor, Mobile Speed, Rate Limiting, and Self-Assembling Drone
- Canary (IndieGogo) — security sensor with video, motion, temperature, microphone, speaker, accelerometer, and smartphone remote control.
- Page Speed is Only The Beginning — 73% of mobile internet users say they’ve encountered Web pages that are too slow. A 1 second delay can result in a 7% reduction in conversions.
- Rate Limiting and Velocity Checking (Jeff Atwood) — I was shocked how little comprehensive information was out there on rate limiting and velocity checking for software developers, because they are your first and most important line of defense against a broad spectrum of possible attacks. It’s amazing how many attacks you can mitigate or even defeat by instituting basic rate limiting. (via Alex Dong)
- Self-Assembling Multicopter (DIY Drones) — The true accomplishment of this research is that there is not one robot in control – each unit in itself decides what actions to take to keep the group in the air in what’s known as Distributed Flight Array. (via Slashdot)
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.