As a digital marketer, keeping up-to-speed on the latest and greatest trends is a full-time job in itself.  I don’t know about you, but it’s getting harder to filter the hype.  Even my typical networking channel LinkedIn has become a bit spammy.  That’s why I’ve found Inbound.org – a community for inbound marketers – so useful.

Two inbound titans, Dharmesh Shah (HubSpot) and Rand Fishkin (Moz), built Inbound.org to be a place for inbound pros to share ideas and opportunities, connect with each other individually and stay on top of this fast moving industry.  Recently, I noticed a discussion there about another one of my favorite industry topics – website performance.

Defining Website Load Speed and How It Can Affect Search Rankings

Things were kicked off by an Inbound.org contributor, Mary Green, who asked,

As a marketer and employee of a performance related company, I was excited to see the topic because it combines two topics that are right in my wheelhouse.  And there was a lot of good advice going around.  But I also noticed that many of the well-meaning respondents were missing some crucial aspects of performance. They can’t be blamed: performance is tough, and many developers aren’t even up on the latest practices, never mind us lowly marketers.

So, continuing our effort to rid the world of slow applications and improve user experiences, I wanted to address (and correct) some misconceptions we noticed, and also highlight the good stuff.

Idea #1: Google’s Page Timings features are reliable (false!)

Google is a performance-obsessed organization and has employed some of the finest thought leaders in the performance industry. But as of now, the page timing feature in Google Analytics is too flawed to use reliably without some extra legwork. We have two posts on how to use the Page Timings feature that cover several issues, and how to resolve them:

• The tests often result in errors (zero values) that are not accounted for in the results
• The sampling rate defaults to a very low rate, and the data is noisy due to little segmenting control

The tool can be useful, but unless you take these steps, it could show you misleading data.

Idea #2: SEO should take a backseat to user experience (true!)

A contributor (@nchimonas) noted “Regarding if [performance] hurts your ranking or not, I’d say it probably can. But who cares? What is the point of ranking well with a slow site?” Others were in agreement.

That’s a great sentiment. It’s true, Google’s algorithm DOES include performance as a factor.  But it’s a case where following the guidelines will “help you help yourself”. UX should be the top priority; SEO should be considered a luxury, something to tune up only when your experience is top notch.

Idea #3: Google’s PageSpeed Insights tool always provides the right suggestions (false!)

Like the site speed tool in Analytics, this tool is potentially useful, but also a bit misleading. It makes suggestions for ways you can improve performance by auditing your site’s code for obvious breaks in best practices.
This is perfect for gaining a high-level understanding of where you stand and how much work you have ahead of you. But it could also send you down some unfortunate rabbit holes.  Some best practices — minifying a script, for example — are good advice in general, but can extend development cycles for little upside. If your site is loaded down with heavy images, minifying a single script won’t budge performance. It takes a deeper level of testing and analysis to really understand what’s slowing down your site, and what projects will yield the greatest benefit. Use PageSpeed insights as a reference, but don’t let it dictate your projects.

Idea #4: You don’t necessarily need a CDN to get a faster site – optimizing content is cheaper and more effective (true!)

A contributor (@timsoulo) told the story of how he got his site to perform brilliantly. He reduced images, compressed images, leveraged local caching, and optimized scripts — and never implemented a CDN.

The truth is today CDNs are more useful to marketers for their ability to offload bandwidth and thus reduce server costs and increase scale. Geographic latency (the performance problem solved by CDNs) is a smidgen compared with the heavy lifting browsers are forced to do with today’s complex, heavy site content. Always start and end with optimizing the content — it’s likely what’s contributing most to any performance problems. Once you have your site content tuned to perfection like the contributor above does, then a CDN may be a lever to push performance even further.

Idea #5: Performance is Key to SEO (true…and false!)

On the thread, the prevailing idea seemed to be that performance is very important for SEO. One of the top factors, in fact. This idea was shared by marketers and pro SEOs alike.

That performance is key to SEO is only true to a point. It’s a factor in Google’s algorithm, and if your site is slow when bots come a-crawlin’, you’re liable to get dinged for it. But the bots don’t account for user experience. The only performance metric correlated with page rank is “time to first byte” – essentially the ping time for a round trip of a request traveling to the server and back. This can be improved by tuning server performance or by using a CDN to improve middle-mile route efficiency. But it has little to do with user experience. Most of the load time experienced by actual human visitors is the result of downloading and rendering content long after the “first byte” has arrived.

So I believe some of the contributors have overstated the effect performance has on SEO – it should instead be considered as two different concepts. Optimizing “backend” performance will help SEO but have a marginal effect on user experience. Optimizing front-end performance will greatly improve user experience, but have little effect on SEO. And there are very different solutions for optimizing each. So choose where you want to put your efforts based on your most important goal.  Hint: that goal should probably be user experience 🙂

I hope you join the discussion, and connect with me on Inbound.org!