BrightonSEO April 2018 Recap
After an exciting evening at the Drum Search Awards, where we received two awards (including the big one of the night: the “GRAND PRIX” award!), we continued our journey to attend the BrightonSEO Event. When we arrived, we were greeted by a huge Banner at the entrance and Brighton’s fresh sea breezes, and we knew we were in for an excellent SEO treat with far over 100 speakers, spread onto five different tracks.
Tom Anthony – Diving into HTTP/2
Pull out your nerd glasses, because the Tech SEO block at the BrightonSEO conference was kicking things off in the auditorium 2. Tom Anthony shared his love for HTTP/2 with the audience and told us why we should all use it. Spoiler alert: HTTP/2 is blazingly fast compared to its old predecessor HTTP/1.1. No wonder its direct precursor was called SPDY. That is because HTTP/2 can handle several requests within one connection (multiplexing!), while HTTP/1.1 must open a new connection every time. The good thing about HTTP/2 from an SEO perspective is, that it’s not a migration unlike an HTTPS switch, as every change happens on a network level. So, what do you need to get your own HTTP/2 speed-up? Your website just needs to be on HTTPS. Considering this is something you should have probably done a long time ago, we assume you are already good to go! 😉
Rob Bucci – Featured Snippets From Then to Now, Volatility and Voice Search
Rob Bucci brought some interesting self-collected data of featured snippets to the SERPS block table. He was looking up one million keywords in November last year to see if they show any featured snippets. He and his team were able to gain some valuable insights. 31% of those keywords showed a feature snippet and were then tracked for nine days to see their behaviour with their feature snippets. Rob additionally compared the data with some old ones that they collected back in January 2016. With all this data, Rob was able to answer some interesting questions.
Position Zero: is a feature snippet always on top?
Seemingly not anymore! It was the case in January 2016, but the data from 2017 show that only 94% of all feature snippets where on “position zero”. This is due to some queries that have a Google shopping box on top.
Which source ranking position must I have, to be highlighted in a feature snippet?
99% of all feature snippets are drawn from a result that is ranked on page one of the SERPs. Within page one a simple rule can be applied: The higher you rank, the more likely it will be for your result to be the featured snippet.
How volatile are featured snippets?
To answer this question, Rob first had to define “volatility” in this context. He came up with the following set of rules, to determine if a feature snippet is volatile or not:
- The feature snippet disappeared from the search results.
- The feature snippet reappeared after its disappearing.
- The feature snippet switched its sourced URL.
Re-evaluating his data regarding volatility, 68% of the snippets didn’t show any changes (meaning they showed the same feature snippet for 20 days!). The remaining 32% showed volatility, which proved the majority of the featured snippets to be surprisingly stable.
What’s the most common occurrence of volatility?
Looking at the set of rules to define volatility, the change of the sourced URL was the most common one to appear. 99% of these returned up to three different URLs. Thus, with regular monitoring, you can find your feature snippet competitors.
To wrap things up, Rob pointed out that featured snippets will have its strongest growth for the long-tail. They are usually triggered by longer strings, starting with words like “what” and “how”.
Time for a quick break! How about some fast-paced good old Mario Kart action? Shout out to the Retro Gaming Spot.
Bastian Grimm – Web Performance Madness: Critical Rendering Path Optimisation
Speed lovers where not only playing Mario Kart but also attended Bastian Grimm’s “Web Performance Madness” talk, which took place in the Site Speed block. Bastian mainly focused on how to optimise loading time of the critical rendering path. The critical rendering path addresses everything that is needed to load the most important content of the page. That usually includes the content of the initial view, which is located above the fold. Of course, you should also be looking at the device most important to you, to determine the critical rendering path that needs your attention first.
To understand how to make it faster, Bastian examined some technical basics like the CSS Object Model (CSSOM). It defines APIs for selectors, media files and of course the CSS itself. Thus, it can be considered as a “map” to locate all your stylesheets. Together with the DOM to build the HTML, your browser needs the CSSOM to display anything. Long story short: CSS stylesheets block rendering! Up until the browser requested, received, loaded and parsed them, you will be staring at a blank page.
So, how to get them fast? By in-lining the CSS! Remember your first HTML course back in 2003? Having a proper CSS file without any inline CSS was top notch website building. Now we need to wield things back for the good of performance. Google has taken it to the extreme, by merely in-lining everything of the CSS. Sounds like a real mess to maintain, but for your critical rendering path to be fast, you don’t necessarily need to inline everything. Just inline the CSS which is required for your CRP! How do you check which CSS is part of it? Bastian recommends trying criticalcss.com.
— MJB (@MatthewJBrown) 27. April 2018
Another interesting topic when it comes to web performance: custom web fonts. At least 70% of all web pages use at least one, leading to additional data and on average three more HTTP requests. It’s slower, and even more so when requested using external CSS. Loading fonts asynchronously, unfortunately, leads to an annoying flickering of the text, worsening the UX. You can, however, try matching the style of the custom web font to your fall-back font with the Font Style Matcher. Alternatively, you can also try the relatively new font-display:option line in your CSS. This will lead to your custom font being downloaded in the background, and the font change will happen once it’s done loading.
— Nik Hudson (@nikhudsontweets) 27. April 2018
So Bastian gave us a lot of input on web performance to process at the BrightonSEO conference, the good news is, you can check out his whole Web Performance Madness-Deck on Slideshare or, if you are short on time, take a look at the following conclusions of every presentation on the BrightonSEO key takeaways slides:
BrightonSEO had a lot going on, and we had a blast seeing all these speakers in action. We can’t wait to be back at Brighton’s breezy cost for more!