It’s been a few weeks since Google’s algorithm was updated with what they’ve dubbed as the “Speed Update”. As detailed in Part I of this blog series, the Speed Update is a change to Google’s algorithm that made pagespeed a ranking factor for mobile searches for the first time. The update went into effect July 9th 2018, and since the rollout, we want to update you on how the Speed Update has affected website owners.
Based on our conversations with customers and non-customers, the verdict is….page rankings have not been affected much. Because Google’s update was established to seek out only the slowest-of-the-slow web pages on the internet, the vast majority of our customers have not felt much of a change in their websites’ performance. As mentioned in Part I, Google had stated:
The “Speed Update,” as we’re calling it, will only affect pages that deliver the slowest experience to users and will only affect a small percentage of queries.
Google has also said that there is no single tool that can determine if a page has been affected specifically by this new ranking factor. Therefore, it is extremely difficult to attribute any change in ranking solely on performance.
That being said, performance is a hot topic right now, and we understand that site performance is business critical. Here are some general recommendations for making improvements and avoiding pitfalls:
Don’t Always Trust Site Speed Tools
You may have been using either Lighthouse or another site speed tool to measure site performance. In terms of Optimizely’s snippet, it’s important to note that these tools aren’t necessarily 100% accurate. For example, the Lighthouse performance test takes into account other Optimizely events after that first client activation event, and reports Optimizely is hurting performance more than it really is. This could be true for other snippets or tags implemented on your website as well, so be cognizant of that before fully trusting the results from site speed tools. Another thing to keep in mind when using these tools is to be sure you’re looking at the correct script (for Lighthouse, look for cdn.optimizely) for the most accurate reading on site performance.
Audit Your Trackers
Adding trackers or tags to websites is extremely common. There are many reasons to include trackers or tags on a website, such as advertising, monitoring customer interactions, site analytics, etc. These are all great reasons to have trackers or tags, but it’s important that you strike a balance between performance and data collection/revenue. Perhaps you do not have a robust purchase process for software and have tags that overlap, or maybe you stopped working with a partner whose tag you were using. Make sure to review your trackers regularly to weed out superfluous or repetitive tags, or archive tags that you no longer use to improve site performance.
Keep Your Assets Minimal
Like trackers, snippets can get out of control if they are not monitored intermittently. With any snippet (including Optimizely’s snippet), the more code in the snippet the higher the impact on performance there will be. Review each snippet you have on your site and make sure that any code that’s written is code you definitely need. Archive any code that’s not being used rather than leaving it in the snippet to improve speed and maximize your visitors’ experiences.
After being asked on several occasions, “Do Optimizely’s Web experimentation and personalization products have an effect on performance?”, here’s the answer. The fact is, any addition to your site is most likely going to have some effect on performance. Implemented with performance in mind, the Optimizely snippet will have minimal effect on your site performance. We’ve provided tools to minimize your performance impact that include the ability to reduce your snippet size and provide granular control over caching and event timing.
With Optimizely’s snippet, there’s no doubt that you’ve read somewhere on our website that the snippet should be placed as high up in the head tag as possible to maximize performance. To add to that, the snippet should also be set to load synchronously with the page. Doing so will prevent flashing and will load the page seamlessly for visitors. To clear up any confusion, if you’re interested in implementing asynchronous changes, you can still do so even if the snippet is set to load synchronously. We are cognizant that many websites are single page apps with dynamic pages where asynchronous loading works well. As long as the snippet is loading synchronously, load time will be minimal.
One final tip that we leave you with is the power of our newest product, Full Stack. There are a multitude of benefits to using this solution, but one of the most relevant is its speed. Full Stack is a server-side experimentation solution, and makes decisions in memory without blocking page load. With all changes running in the backend, there is no network latency from calling up to an outside server, allowing for maximum performance.
As mentioned earlier, any addition to a website will most likely affect performance in some way. With Optimizely, that affect will depend upon many things, from client-side to server-side products, to the code in the snippet. We feel a responsibility as the leader of the digital optimization space to provide guidance on the best practices in achieving optimal performance. Our goal is to ensure all clients can be wildly successful with their Optimizely products. For this reason, we are shortly launching a new whitepaper dedicated to the topic of understanding and improving site performance. The whitepaper focuses on best practices for optimizing the performance impact specifically with client-side experimentation and provides actionable guidelines for improving your Optimizely performance. If you are a website owner, it’s definitely worth a read.
In Part III of the performance blog series, we’ll look at this whitepaper a little more in depth.