Automated Reports

bad-page-speed-report-example

Today, I was asked to “take a quick look at [a client site] and determine if there are any potential speed issues that need to be resolved,” as the client is “most concerned with load time and optimizing in that area.”

Within GTmetrix, the report that was forwarded to us, the client website scored poorly. It is easy to empathize with their concern. They were most likely shown this by a competitor of their proprietary CMS and sought a non-partial opinion.

But these reports are easy for anyone, likes a salesperson, to produce and present to a prospect, even if that same salesperson is no more qualified to discuss render-blocking resources or “First Interactive” than the client they are attempting to woo. At a growing agency in Utah, our sales team loved these – a visual mechanism to sow discontent.

The same applies to SEO Audits. Page after page of automated reports from software like Moz, ahrefs, or SEMrush detailing how Title Tags are too long probably isn’t wowing potential clients.

With the above in mind, a mobile page load for the domain was throttled to the low range of Verizon’s 4G network speeds in Chrome DevTools. Above the fold content painted in less than two seconds, and the DOM was interactive in less than 4. Essentially, as far as a User is concerned, the page loads fast.

In addition to explaining the above, the client’s concern with page speed will be used as an opportunity to pursue working with their CMS provider to migrate to HTTPS, and finally to ensure resources are delivered over HTTP/2. We’ll likely talk about security and why Google cares about it, as well as the speed benefits of sending multiple requests for data in parallel over a single connection. Funnily enough, these items were not highlighted within the report.

I’m looking forward to it.

[1]https://blog.cloudflare.com/ttfb-time-to-first-byte-considered-meaningles/