"performance" entries

Roll-your-own database architecture

Making the case for blended architectures in the rapidly evolving universe of advanced analytics.

Kenny_Louie_Squares_Circles

Two years ago, most of the conversations around big data had a futuristic, theoretical vibe. That vibe has been replaced with a gritty sense of practically. Today, when big data or some surrogate term arises in conversation, the talk is likely to focus not on “what if,” but on “how do we get it done?” and “what will it cost?”

Real-time big data analytics and the increasing need for applications capable of handling mixed read/write workloads — as well as transactions and analytics on “hot” data — are putting new pressures on traditional data management architectures.

What’s driving the need for change? There are several factors, including a new class of apps for personalizing the Internet, serving dynamic content, and creating rich user experiences. These apps are data driven, which means they essentially feed on deep data analytics. You’ll need a steady supply of activity history, insights, and transactions, plus the ability to combine historical analytics with hot analytics and read/write transactions. Read more…

Comment

Tailoring CSS for performance

Rethinking CSS delivery

In my last article, I demonstrated how improved performance and a lower PageSpeed Insights score were accomplished by removing unnecessary external JavaScript and CSS requests. YepNope was also used to manage the asynchronous loading of external requests.

After the improvements, I thought it was time to move on but PageSpeed Insights advised there was more work to do.

Read more…

Comment

Tailoring for performance

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…

Comments: 2

The altar of shiny

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.

Read more…

Comments: 3
Four short links: 7 November 2013

Four short links: 7 November 2013

Help Searching, Offline First, AWS Tips, and Awesome Fonts

  1. Learn to Search — cheeky but spot-on help for people running conferences.
  2. Offline Firstno, the mobile connectivity/bandwidth issue isn’t just going to solve itself on a global level anywhere in the near future. THIS!
  3. 10 Things You Should Know About AWS — lots of specialist tips for hardcore AWS users.
  4. The League of Moveable Type — AWESOME FONTS. Me gusta.
Comment

Going beyond Onload: Measuring performance that matters

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.

Defining “Done”

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 (DOMContentLoaded)

2) When all synchronous scripts, stylesheets, images, and subframes have finished loading (onload)

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.”

Read more…

Comment: 1

The Joys of Static Memory JavaScript

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:

sawtooth01

One of your co-workers chuckles, because they realize that you’ve got a memory-related performance problem.

Read more…

Comment
Four short links: 6 August 2013

Four short links: 6 August 2013

Modern Security Ethics, Punk'd Chinese Cyberwarriors, Web Tracing, and Lightweight Server OS

  1. White Hat’s Dilemma (Google Docs) — amazeballs preso with lots of tough ethical questions for people in the computer field.
  2. 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.
  3. Web Tracing FrameworkRich tools for instrumenting, analyzing, and visualizing web apps.
  4. CoreOSLinux 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.
Comment
Four short links: 23 July 2013

Four short links: 23 July 2013

Security Sensor, Mobile Speed, Rate Limiting, and Self-Assembling Drone

  1. Canary (IndieGogo) — security sensor with video, motion, temperature, microphone, speaker, accelerometer, and smartphone remote control.
  2. Page Speed is Only The Beginning73% 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.
  3. 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)
  4. 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)
Comment

JavaScript Is Way Too Slow – for What?

There's more to mobile web apps than JavaScript

I keep finding that programmers—even web programmers—frequently think “web application” means “JavaScript application.” Programmers are, of course, used to working with programming languages, and often see application environments from the perspective of the programming language in use.

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:

JavaScript is too slow for mobile app use in 2013 (e.g., for photo editing, etc.).

Do we need to run Photoshop on our mobile phones using JavaScript underneath? I agree that cramming everything into an interpreted language on a memory-, processing-, and bandwidth-constrained device is a stupid idea—but “photo editing” is an extreme case, to put it mildly. Perhaps critics will move on to video editing when we eventually get to the next round.

Despite that flaw, if the rant had been titled “Why mobile JavaScript apps are slow,” it would have done better. His lists of benchmarks, discussions of processor challenges, and recognition that the easy work in JavaScript optimization is already done, are all tremendously useful. There is little reason to expect JavaScript performance to improve in the future at the rate is has achieved for the last decade.

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 querySelector to the DOM was a massive one-time speed upgrade, letting JavaScript developers drop most of their tree walking in favor of a more declarative approach relying on native code in which vendors had already invested heavily.

So how can we optimize mobile web development?

The first answer is pretty simple: don’t try to use JavaScript for tasks (like photo or video editing) that push it past its limits. As far as JavaScript has come, it wasn’t built for that. Native apps are indeed good for more than building browsers.

The second answer is trickier: it means recognizing that web applications include much more than JavaScript. JavaScript began as a scripting language for gluing together objects written in other languages, and it still excels at that. Build your application from the HTML—the easiest stuff to process!—up. (If you want graphics, SVG might be a better path.) Then layer CSS on top of that. Rely on APIs built into the browser whenever you can, using JavaScript to connect with their much faster processing. HTML5 keeps making that a better and better option.

When I was programming our HTML 4 & 5: The Complete Reference, I marveled regularly at how tasks that seemed huge, like loading a new CSS stylesheet, moved rapidly compared to implementing smaller changes using JavaScript. More broadly, Estelle Weyl’s JavaScript: You Don’t Need a Framework For That (slides) resonates both because it shows how to use smaller chunks of JavaScript and because it explores how to use CSS creatively to avoid using JavaScript at all.

Building great applications using JavaScript, especially great mobile web applications, often means using JavaScript itself as sparingly as possible. That’s always been a feature of JavaScript, not a bug.

Comments: 28