Oh, that unicorn so many teams chase. Everyone and their mom has told you site speed matters. Your boss told you page speed is the single most important metric and anything reducing page load takes priority over other features. In fact, the monitor in front of the CMO’s office shows a grim red line indicating server response time has increased by four milliseconds over the last week. To combat this, a developer dedicates three sprints to write a push-button script generating a report of Google PageSpeed Insights scores for the entire site.
If your head is in your hands right now, I’m with you. All too often, someone attends a conference or read an article (not this one) and convinced leadership that your site needs to load in under three seconds and the company is not realizing sixty million a year due to this blatant disregard to speed. The annual report you just read indicates your company broke forty last year.
Let’s be clear. Site speed is absolutely important, but if you are not measuring the right things, I guarantee you will be chasing that mythical creature. This is why I have decided to share my shortlist of Gibbs rules… er Greg rules for speed success.
Rule 1: Measure What Matters
There is even a book with this title. In my completely fictitious story (wink wink, nudge nudge) you will notice there are several metrics listed. So which should you focus on? Well, unfortunately, I am not going to tell you which to choose; you need to decide for yourself!
Consider the following scenarios:
- GreenMermaidInACircle coffee company’s website is visited by thousands of customers a day looking for a physical store, buying gift cards, and perusing the menu.
- Greg’s personal blog has hundreds of daily visits. Ha ha. Visitors view new content and sometimes comment on posts.
- Amazoom is a large e-commerce company. Their site is mostly geared toward selling products with constantly changing information. They do have a subdomain for a blog that they update once a week with new content.
Do you think all of these web presences have the same loose goal of being fast? Probably, but they likely measure success differently. Greg cares more about page load than he does time to interactive, whereas Amazoom cares about how quickly someone can start interacting with the page and purchase products. Between the three sites, who is more impacted by a five-second load time due to some back-end inefficiency? When it comes to caching content, who can offload portions of their site to a content delivery network(CDN) and potentially care slightly less about server response time?
Do your research and understand what each metric means in your tools. Be aware, the definitions sometimes differ between those tools.
Choose one, maybe two numbers that represent overall success where all teams involved can contribute to improvments. We will talk more about this in rule three.
Rule 2: Communicate the Right Metrics
This might be confusing for some, but the CMO likely should not and does not care about the server response time. Let’s go with something more useful, such as the average page load speed of three hundred milliseconds. Yes, this is a real result! You can happily report that you are significantly under your two-second goal and your competitive analysis reveals we are in the lead. Better yet, our investment in a new search provider is eight hundred percent more performant and provides users personalized search results.
Great, so who cares about all those weird sounding metrics like first CPU idle and time to first byte(TTFB)? The technical folks! You might hear a front-end developer caring about the first contentful paint while the infrastructure team and back-end developers are concerned the CPU is at eighty percent.
If you are a leader of leaders who just said, “I don’t know what you just said,” that is ok. Know that there are a lot of smaller pieces that make up the puzzle. For you, I introduce rule number three.
Rule 3: Shared Goals
Shared goals provide separate teams the organizational alignment necessary for success. It is as simple as that.
You might think this a no-brainer, but not having these shared goals plagues both large and small organizations. Here are some example situations lacking alignment:
- A developer can not view the logs on the production environment without submitting a ticket to IT which has an SLA of twenty-four hours.
- The infrastructure team notices CPU saturation after a recent deployment and has identified the responsible web service. The development team will not have time to review until the next sprint.
- The digital marketing team adds a new script via Google Tag Manager that causes the homepage to load an additional four seconds. The script is not removed as it is needed for the new campaign.
- The development team has created secret web services to get around the infrastructure team’s strict policies put in place after multiple site outages.
- The CRM development manager is held responsible for the site being down even after infrastructure has been offloaded to another IT group who in turn hired a vendor to manage the environment.
I am truly sorry if any of these hit home for you. I know I suffered some minor PTSD just writing them.
Shared goals provide separate teams the organizational alignment necessary for success. I said this already, right? Do it. Don’t wait for the next review cycle. Take your two hundred dollars and press go now.
I often share with my colleagues the idea that we are all responsible, or none of us are. There’s nothing more infuriating than trying to reach your goals, yet it feels as if you are in it alone.
If your goals suck, please make some SMART goals.
What Now?
Creating shared goals means you need to identify your shared metrics. Again, likely not going to be TTFB, but maybe something like a particular speed index. If you are just starting out or struggling with your journey to speed nirvana, I highly recommend investing in a consultant, or several. Care about what is in Google Analytics? There are consultants for that. Don’t know anything about front-end performance? There are consultants for that. Azure web apps are slow and you need to implement a content delivery network(CDN)? You get the point.
But Seriously, Three Hundred Milliseconds?
Yes, seriously! Utilizing a CDN, all of your content can be cached on an edge server which delivers it that much faster to your users.
Using solutions like Akamai, Cloudflare, and Azure CDN, you can cache images, CSS, JS, or the entire kitchen sink! My personal blog is using Cloudflare and I am doing just that. All of the content is served from an edge server and not the host, assuming folks have read my post in the last seven days.
The trick is knowing not only what to cache, but when to cache. Check out my next post on Basic Web Performance Strategies.