Improve Site Speed with Publisher Ads Audits for Lighthouse

This post was most recently updated on September 6th, 2021

There’s been an increase in requests from publishers regarding their page load speed and the general behavior of their sites. In today’s post, we will look at some of the questions publishers have been bringing up, and later we will show you how to make your own reports, and better assess your page load situation.

#1 – The site loads slow and has a low score on reporting tools

It’s important to understand that the final behavior of a site is the result of several factors: technology used to build the page, how many elements are shown on the site, how those elements are stored, calculations made at runtime, etc. Reporting tools (such as LightHouse, which we will discuss later) will pinpoint these issues. Note that these problems are unrelated to our code since they are a consequence of how the site is built.

#2 – MonetizeMore’s code made the site slow

The higher the number of ad units on a page, the more elements that need to be loaded, so there is always a tradeoff between page speed and revenue that needs to be considered. Publishers need to be aware of this at all times. Our code doesn’t impact significantly on site performance. The MonetizeMore ad script runs asynchronously, meaning that, while the header bidding process is running, the rest of the site continues to load as it would without our code. When running Header bidding, it is inevitable for the ad load script to delay ad render until the bidding timeout is reached, another tradeoff that needs to be addressed. The default recommended timeout is 2000ms for striking a healthy balance between page load speed and good Header Bidding fill rates. Lowering this timeout might help with reducing the load time, only if the page is loading up faster than the timeout being set. The lowering of your header bidding timeout increases the chances where the header bidding auction might end before all the configured bidders return their final bids.

Lighthouse

We will be using the Publisher ads audits for Lighthouse moving forward, and you can find it here: https://developers.google.com/publisher-ads-audits

Even though our script may not be the main culprit in page performance, page performance does impact traffic, and so it becomes an important issue for us. Make your own assessment of the site, and try to address the suggestions/warnings.

With Chrome:

1.- Open the target webpage

2.- Right-click and select Inspect

3.- Among the dev tools, look for the last one, called Audits

4.- Select relevant categories and click “Generate report”. After several refreshes of the site, a report will be generated and shown.

You will be shown several categories in which the page was evaluated:

• Performance: technical execution of the page, which includes interactivity, speed, and coding.
• Accessibility: design elements that allow people with specific disabilities to engage with the content more comfortably
• Best Practices: general recommendations, mainly to improve navigation and security
• SEO: optimizations for search engines to engage with the site
• Progressive Web App: PWA is a specific type of site that heavily resembles a mobile app, in presentation, and under the hood. Here are optimization suggestions for this type of website.

Most of this information is pretty straightforward. One that we should pay close attention to is performance -> Diagnostics, where we can see the performance of js codes, and in particular, ours.

In the picture above (Diagnostics -> Reduce the impact of third-party code), we see that our code blocks less than a third of a second in the main thread (the thread that is responsible for loading the page). None of these codes are blocking the main thread a lot, but the whole group of third-party codes uses an entire second of the main thread, which is ultimately what the users experience.

In the picture above (Diagnosis -> Reduce JavaScript execution time), we see that our code falls in line with the rest of the codes in execution time. Even if the execution time was higher, this is being done in another thread asynchronously, so it doesn’t impact performance.

Considerations

• You can perform a simple test, by running this report without our tags, and then add our tags and run the report again. As mentioned, tradeoffs will make the total score drop, but this is expected.
• Most of the page speed tests/scores don’t account for the required delay when running header bidding and are designed to assess hardcoded ad tags. So when running on a page with Header bidding active, they’ll not account for the custom functionality and cut down the score for it.
• Your own Chrome plugins can heavily alter the performance of the report itself. You can try to test the page in a cleaner environment:
  • Go to the following page: https://developers.google.com/publisher-ads-audits.
  • Paste the site’s address
  • On Advanced Settings, activate Run Additional Lighthouse Audits.
  • Click on Generate Report
  • *This report will also give you the Publisher Ads report. If the site is configured correctly, the score should be high, so it can be a good way to show publishers that any performance problem probably lies elsewhere
• If improving performance is a must you can consider:
  • Reducing the number of ad units on a page
  • Moving the MonetizeMore script call to the end of the page or higher up, based on the implementation of other heavy JS/resource calls
  • Reduce the Header bidding timeout to a value where there are no significant loss of incoming bids (Can be tested via PGAI: Under bidders tab, color coding of received bids)
  • Lazy load all ad positions on all pages. (Enable SPA in dbAdmin and switch DIVs to lazy format)

Other, more technical suggestions can be:

• Improve JavaScript load: a single call to a heavy script or many calls to small scripts will impact negatively on performance. Strike a balance between tasks and calls in JS. This can only be done with JS files that the pub can manipulate (not our wrapper, GA, or facebook script for example)
• Make sure that any script that can run asynchronously does so. Our script already does
• Make sure that resources (images, videos) are encoded with the latest technologies. This allows the elements to be compressed while they travel, and decompress when it loads on the page.

 

Need more help? Sign up for a Professional account at MonetizeMore today!