Two days before the Super Bowl people are not only betting on the winner, but also on the best commercial. Will the millions of dollars spent really pay off for the advertisers? We took a closer look at the Super Bowl Ad landing pages for these Super Bowl Ads. Our synthetic monitoring showed huge differences ranking from 1.4 to 10s+ load time. If these pages are already slow prior to the big day, we wonder how they will do on Sunday and if there is anything that can be done to speed things up.
With this blog we hope to give a wake-up signal to some of these companies. They need to take another look into their current deployment because we see a lot of web performance mistakes all over the place like:
- CDN Configuration Problems
- NOT optimized for Mobile
- NOT following Best Practices such as Spriting.
For Business Owners: Talk with your IT Teams and make sure they have the time and resources to analyze and do last minute fixes – otherwise it is possible that even with the funniest ad, you won’t be able to convert viewers into customers because your website may crash or be slow. You can check out how fast your page is in the moment: Run an Instant Test with Dynatrace.
For the DevOps and Web Architect Team: Run a quick sanity check with tools such as Dynatrace AJAX Edition, PageSpeed, FireBug, … and follow the best practices we have been talking about in the recent years.
CDN Configuration Problems
One of the advertisers landing page loads 248 images on that page. Most of these images are served from the home domain (e.g: www.company.com). Others are severed from Amazon’s CDN. What’s interesting is that on this page, 46 of these image requests result in an HTTP 403. This is a lot of time wasted by the browser and impacts the end user because he has to wait longer for the full page to load:
Next Steps: Figure out if these image URLs are valid and really needed for the landing page. If so – check the CDN configuration. If they are not needed, they probably got onto the page by accident. Make sure to remove them from the HTML document so that they don’t impact page load time.
Not Optimized for Mobile
How large do you want a mobile web site to be? 100k, 1MB, 10MB? Even though many of us now have LTE or 3G, downloading large web sites on a mobile device will always impact user experience. One of the mobile versions of the landing pages that I analyzed had 20MB in unzipped content and took about 15s to load. I used a WiFi connection for this test. Here are the other Key Performance Indicators showing that this site is definitely NOT Optimized for Mobile:
Next Steps: I would ask the question: why it is necessary to download all these images on the initial landing page when only a handful of them are shown anyway? Loading images of a picture gallery in advance will speed up scrolling through the gallery, but it will also impact the first impression of that page. This will make end users wonder how much data they just downloaded to access a “mobile” web site.
Not Following WPO Best Practices
Some of these web sites provide links to their international sites by allowing the user to pick the country from a drop down menu. Next to the country’s name you also see a flag. One of the sites has 52 different locations and 52 flags. All of them are downloaded as individual images instead of one large sprite. That is 51 roundtrips that could be avoided – especially on the mobile version where we see the same pattern.
Next Steps: In addition to flag images, we also see other images such as a collection of user photos, smaller promotional or product photos. All of these are candidates for spriting which greatly reduces the number of roundtrips and therefore the time it takes to download these images.
Business Folks: Don’t waste your money – give IT more time to focus on web performance
After so many years of Web Performance Optimization Best Practices it still interesting to see “performance landmines” like the ones highlighted here. And – these are just a few of many that we found. If you want to learn more about what it takes to prevent these problems right from the start then check out some of our other blogs on Best Practices for DevOps and Avoiding the Classical Business War Room Scenario.