Nine web performance predictions for 2014

It wouldn’t be January without a crop of predictions for the new year, would it? I wouldn’t call these predictions, exactly. I’m not a prophet. No crystal ball here. I’m just looking at trends, and perhaps applying a little hopeful thinking.

1. We’re going to finally nail the m.site versus RWD question.

Last month, I wrote a post calling for the demise of m.sites in 2014, which provoked some really excellent discussion in the comments. I stand by that call. You may disagree, but I’m sure we both agree that it would be great to nail down this issue and move on.

2. Performance will stop being the sole domain of developers.

If I keep saying this, it’ll happen, right? When I was at Velocity Europe in November, I had a great conversation with O’Reilly publisher Laurie Petrycki. Among other things, we talked about the fact that performance optimization, up till now, has been primarily the domain of developers — and to be blunt, why this is unfair. Essentially, what’s happening is that IT is inheriting pages with performance problems caused by lack of foresight during the UX design phase, and now IT is forced to go backwards to identify and fix the problems, rather than taking a planning-first, forward-looking approach. Not only is this unfair, it’s also inefficient. Performance shouldn’t be kept in an IT silo or treated as an afterthought. It needs to be considered as an integral part of user experience design from stage one.

On the conference front, I’m hoping to see performance take the stage at events other than Velocity. While Velocity will always be the lodestone for our community, it’s essential to get out and speak to other communities. (On a personal note, I’m super excited about being invited to speak at IRCE’s Forward Mobility conference in February, and at eMetrics in June.)

3. Site owners will begin using more sophisticated techniques to measure page load and engagement.

It’s a well-discussed fact within the performance community that load time is a crude, imperfect method for measuring performance success or failure. Finding a more meaningful metric that can be measured easily is a huge challenge. At Radware, we’ve been looking at time to interact (TTI) in our quarterly performance state of the union reports. We define TTI as the moment that a page’s primary content — in the case of ecommerce sites, this is usually some sort of feature banner or carousel — renders in the browser and becomes interactive, i.e. has a usable call-to-action button or link. This is helpful, because it forces us to first prioritize the value of a page’s content, and then focus on measuring how long it takes that content to render. It’s a good first step, but it’s still just a first step.

I believe that savvy site owners are going to start making inroads into more refined ways of looking at how pages render and how this affects the user experience. After I presented the findings from our mobile engagement research at Velocity, I talked with a few site owners who were intrigued to learn more about how we conducted our EEG and eyetracking research. Applying eyetracking technology to measuring performance isn’t new — Jakob Nielsen did some interesting work in this arena back in 2010 — but it hasn’t been widely adopted. It’s a shame, because Nielsen’s findings were significant: Users who had to endure an 8-second download delay spent only 1% of their total viewing time in the feature slideshow space. In contrast, users who received instantaneous page rendering spent 20% of viewing time within the slideshow space.

While eyetracking technology has been around for a while, it’s only very recently that EEG technology has been lightweight, affordable, and relatively easy to use. While I won’t go so far as to say that it’s going to become a standard tool in your performance toolbox, I do believe we’re going to see it emerge occasionally during the application development process.

Don’t you wish you could travel back to 1995 and blow your own mind with this graph?

5. Embedded mobile browser performance will start getting attention.

This is a fascinating — and mostly overlooked — aspect of performance, but I believe this is going to change soon. Luke Wroblewski wrote a great post about this back in September, and I was surprised to see how few people jumped on it. He wrote, “When you consider Facebook users consume Web content inside a web view within the Facebook app, then Facebook is the second most popular Web browser on iOS and Android.”

Facebook isn’t the only embedded mobile browser. Twitter and Pinterest also embed web content. Just by way of illustrating this point, and not to single out any one app, here’s what it looks like when you’re waiting for a page to load within the Pinterest app. Yes, there’s a progress bar. No, it doesn’t move very quickly.

As a regular user of all three of these mobile apps, I’m very aware of the varying performance penalties they incur when they serve as a browser. The kicker, of course, is that as a site owner, you have no control over this performance obstacle. It’ll be interesting to see if and how these apps rise to the challenge of delivering a faster browser experience.

6. Third-party and fourth-party scripts will return to the main stage as a performance challenge.

It feels like this topic fell off the table in 2013, but it’s every bit as relevant — if not more so — than ever. Third-party scripts are continuing to proliferate, and the general public is slowly getting wind of the existence of forth-party scripts (which, in addition to posing performance challenges, also pose security challenges).

7. CMS vendors will step up to the plate.

From WordPress to enterprise CMSes, we all know that content management systems cause performance hits that are hard — or downright impossible — to mitigate. This year, I think we’re going to see more CMS vendors realize that offering a product that enables better performance is a serious competitive differentiator.

8. Enterprise performance will become a hot-button issue.

Ecommerce is sexy, public-facing, and relatively easy to measure, which is why a lot of the performance conversation revolves around it. Personally, I think the enterprise is pretty sexy, too, but it’s a walled garden. My goal for the year ahead is to get further inside this garden and tell more sexy enterprise stories.

9. Site owners will gain a better understanding of what a CDN can and can’t do for performance.

Content delivery is now available as a service at every price point. Today, more site owners than ever are taking advantage of a CDN’s ability to reduce latency by caching page resources closer to users. Yay. However, too many site owners now believe that they’ve done all they can do to fix performance. Boo. Between 80 to 90% of response time happens at the front end — at the browser. This is where site owners can find opportunities to make major performance gains by leveraging front-end optimization (FEO) techniques, such as resource consolidation, prefetching, preloading, advanced resource compression, and more aggressive browser-side caching (to name just a few). By combining a good CDN with a good FEO solution (*cough*), site owners can make pages up to four times faster and reduce total payload by up to 70%. This is huge. I’m calling this the year when companies that rely exclusively on their CDN to fix their performance woes will realize they can still get much faster.

What do you think? (Disclosure: In the past, I’ve been accused of being an optimist.) Am I way off the mark with any of these? What are your predictions/hopes/wishes/dreams for 2014? Let me know in the comments.

Share this:

I’m Kent Alstad, a tech innovator & performance researcher with a (seemingly) simple goal: to make the Internet faster. I obsess over the many sides of web performance as VP of Acceleration at Radware.More...