As a former senior researcher, writer, and solution evangelist for Radware, Tammy Everts spent years researching the technical, business, and human factor sides of web/application performance. Before joining Radware, Tammy shared her research findings through countless blog posts, presentations, case studies, whitepapers, articles, reports, and infographics for Strangeloop Networks.
Every quarter at Radware, we measure and analyze the performance of the top 500 retail websites. And every quarter, I've grown accustomed to the persistence of two trends: pages are growing bigger and, not coincidentally, slower.
But while I expected to see some growth and slowdown in our latest research -- released this week in our State of the Union: Ecommerce Page Speed & Web Performance [Summer 2014] -- I have to admit that I wasn't expecting to see this much.
Our latest research into the performance and page composition of top retail sites finds that a typical ecommerce page takes 6.2 seconds to render its primary content, 10.7 seconds to fully load, and weighs in at 1677 KB. Keep reading to find out what this means for site owners who care about delivering the best possible user experience to their customers.
I talk a lot about page bloat, insidious third-party scripts, the challenges of mobile performance, and all the other things that make hitting these goals seem like an impossible feat. But rather than get discouraged, let me point you toward this great quote from Ilya Grigorik in his book High Performance Browser Networking:
“Time is measured objectively but perceived subjectively, and experiences can be engineered to improve perceived performance.”
Keep reading to find out about some tricks and techniques you can use to manipulate subjective time to your advantage.
Last week, I shared slides for my Velocity talk (and the report upon which the talk was based) about the impact of slow performance on user engagement and long-term brand satisfaction. But slow pages are just one way to irritate people who visit your site via a mobile device. Here are six more.
Earlier today, I had the privilege of speaking at Velocity Santa Clara on a topic near and dear to my heart: the mobile user experience. I presented research we conducted at Radware that I'm really excited about.
By now, most of us have internalized the fact that slow pages hurt mobile user metrics — from bounce rate to online revenues to long-term user retention. At Radware, we wanted to understand the neuroscience behind this in order to get a 360-degree view of mobile performance, so we engaged in the first documented study of the neurological impact of poor performance on mobile users. Here's how we did it, and what we learned.
Google recently announced changes to Googlebot that some people speculate could pave the way for the web crawler to gather more nuanced performance metrics for the sites it crawls -- and ultimately make performance a more critical ranking factor. This seems like a good time to review and update our FAQ on Google, page speed, and search engine optimization.
Last week, I had the great privilege of presenting an O'Reilly webcast as part of the lead-up to Velocity Santa Clara. The catch was that I didn't want to give away what I'll be presenting at Velocity, so I needed to come up with a brand-new topic. I decided to talk about third-party scripts, for two reasons...
My recent post about page growth (or page shrinkage, as the case may be) hit a nerve with a lot of people, so this week I thought I'd take my first dive into the Mobile HTTP Archive, the mobile counterpoint to the HTTP Archive I cited last week. The Mobile HTTP Archive tests the same list of URLs, but it does so using smartphones. This means that if a URL redirects to a mobile site, the Archive tests the mobile site.
Just like last week, I looked at the top 1,000 URLs. What I found won't come as a surprise to anyone who's been following this blog for a while. While there are many similarities between these findings and last week's, there are also a number of insights that are unique to mobile devices.
According to the HTTP Archive, the average top 1,000 web page is 1491 KB in size, 5% smaller than it was six months ago, when the average page reached a record size of 1575 KB.
But let's not start celebrating yet.
Does this finding represent the start of a new trend toward smaller pages, or is it just an isolated incident? To answer this question, we need to take a look into the Archive's other findings.
I talk to a lot of people who have taken on the role of in-house performance evangelist at their organization, and I know it can be a hard, lonely job. Often it's a self-appointed role because you're genuinely passionate about web performance. And often you're fighting a one-person battle in a workplace that's already struggling to cover a lot of other technical bases with limited resources.
Over the past few months, we've been slowly rolling out Expert Talks, a series of easy-to-digest, solution-agnostic videos that provide brief explainers of key performance concepts. One of our goals in creating this series is to make it easier for you to evangelize within your organization by offering videos that you can use to explain whatever performance issue you're trying to define or solve.