PageSpeed Insights Report


Google PageSpeed Reports

Site speed reports issued to users by Google offer guidelines to make improvements when load times may potentially affect bounce rates. These reports are subject to change when Google adds or removes metrics.

NOTE: In speed tests using our standard themes without third-party code, Metro Publisher sites register consistent scores in the top 90s in all key areas measured by Google's developer tools.



At Metro Publisher we stay up to date with current web standards, best practices and requirements for website speeds, i.e. performance and SEO. We continuously evaluate and update our services in the background and routinely release improvements to our system outside of the releases we inform you about directly.

Metro Publisher is committed to the best balance between performance and user-friendliness. For example, we make sure our native Site Search feature finds the best matches to user keywords by scanning various items, e.g. titles, descriptions, tags, but still staying within an efficient amount of time for the results to appear.

In some cases, the suggestions in PageSpeed Insights reports are Google's way to nudge developers in a direction they want. Each metric may not be critical or the impact may be negligible to your business. In addition, there are some local issues that may affect the results at any given time. You will notice that the numbers change each time you run the PageSpeed Insights tool.

NOTE: Site Speed (performance) is not equivalent to SEO. Sites with a speed/performance score as low as 6 will easily still score in the 80s range or above if you apply the SEO best practices for publishers. Metro Publisher handles all the necessary system data for SEO in the background, so that you can focus on quality content, which is still the most important SEO factor.


Core Web Vitals

As of 2022, the PageSpeed Insights report summarized three (or four, depending on the reporting system you use) existing metrics into one. These metrics are Largest contentful paint (LCP), First input delay (FID), and Cumulative layout shift (CLS), in addition to First Contentful Paint (FCP) on some reports.

We have created a separate help document for this part of the report here: Core Web Vitals Google Report



Third-Party Code

The largest culprits of fluctuating or low scores are typically third party services, since these are scripts that load before pages are displayed. Google services, i.e. Ad Manager, Analytics, Progressive Web Apps, among others, almost always pose the largest drain on performance, with Facebook following or preceding closely.

The more third party scripts you run aside from Google and social media services, e.g. Pico, Adobe Typekit, WisePops, weather widgets, etc., the more time the browsers spend evaluating, executing, and rendering those scripts.

NOTE: Third-party code affects all user-centric performance metrics measured with the PageSpeed Insights tool.


Here are Google's definitions of those metrics.

  • First contentful paint (FCP): measures the time from when the page starts loading to when any part of the page's content is rendered on the screen.
  • Largest contentful paint (LCP): measures the time from when the page starts loading to when the largest text block or image element is rendered on the screen.
  • First input delay (FID): measures the time from when a user first interacts with your site (i.e. when they click a link, tap a button, or use a custom, JavaScript-powered control) to the time when the browser is actually able to respond to that interaction.
  • Time to Interactive (TTI): measures the time from when the page starts loading to when it's visually rendered, its initial scripts (if any) have loaded, and it's capable of reliably responding to user input quickly.
  • Total blocking time (TBT): measures the total amount of time between FCP and TTI where the main thread was blocked for long enough to prevent input responsiveness.
  • Cumulative layout shift (CLS): measures the cumulative score of all unexpected layout shifts that occur between when the page starts loading and when its lifecycle state changes to hidden.


Please note that Google's reports do not consider publisher-relevant factors such as the need for revenue, e.g. via ads and paywalls, or for additional services your target audience wants to see in the publications they read. The reports do not distinguish between the purposes and demographic of individual websites across the globe, nor do they consider necessary differences between the systems used to run those sites and their features.


In speed tests using Metro Publisher's standard themes without third-party code, we register consistent scores in the top 90s of all key areas measured by Google's developer tools, even on slow 4G networks.



Google metrics for Metro Publisher sites without third-party code on a slow 4G network.


Our integrations simplify the configuration process and communication process between the respective third-party services and Metro Publisher, but we cannot influence the amount of resources third-party code requires to be loaded and performed.


We made the following adjustments on a client site:

  • Stripped out all extra JavaScript in the header and footer
  • Turned off third party services such as Google Tag Manager, Google Analytics, Google Ad Manager
  • Removed third party widgets such as weather widget, Instagram widget on homepage, and the radio broadcast widget

As a result, the performance score changed dramatically – raising from 26 to 86

In other words, websites across the world running third-party code will all see similar effects on their page speeds.

For reference, newspapers such as The New York Times have low to mediocre performance scores by Google's metrics for these same reasons:



Sample Google Page Speed scores for mobile (16) and desktop (40) versions of the New York Times (January 2021)


You should regularly review your header and footer scripts in your HTML Embed settings (and your Design Center JavaScript settings for Pro accounts) to make sure you know exactly what those scripts are for, whether they are from a reputable source, and whether they are necessary.

As a test, you can remove all the custom JS you have entered entirely, or step-by-step, making sure you save a copy (!), to see how your speeds improve.



Minimizing main thread work

Under the listed potential improvement opportunities for some site metrics, you will find a suggestion to "Minimize main thread work" which includes the following points, among others:

  • Code splitting
  • Minify CSS
  • Remove unused code

Code splitting is applied to the code we can influence wherever it is appropriate. Minifying CSS and/or JavaScript is not always possible. For example, we provide access to the screen.css for Pro Accounts. If we were to minify that CSS, custom adjustments would not be possible for clients.

We are aware of the options to minify code and continuously work on improving performance for our clients. Please be aware that we cannot implement code splitting or minify any third-party code you add to your site.

Unused JavaScript is explained below.



Unused JavaScript

This metric can occasionally refer to code that has been commented out, for example. Even though that code isn't being executed, its data must still load in the browser. Removing such code entirely, after saving a copy for potential future use (!), can resolve this issue.

Additional scripts labeled "unused" by these reports are render-blocking or asynchronous ones.

Some of Metro Publisher's JavaScript is necessarily render-blocking, meaning browsers must execute the script before displaying the page. In other words, some site features have to be loaded before the visual part of the page loads. That is labeled "unused" and not distinguished from truly superfluous script.

We apply code-splitting to any asynchronous scripts (= non render blocking) we run wherever we can. That is also termed "Unused JS" even though it is not possible to offer the features we provide without some of these kinds of scripts.

Since these reports are generic and not reviewed by humans before being generated, you will find suggestions that cannot be applied across the web.



Next-Gen (AVIF) Image Formats

Google is pushing for the WebP format in particular with this metric, which currently is not natively supported by all versions of Safari, so we cannot recommend a switch from the current standard of JPG and PNG. Please note that PNG images will always be of a larger file size than the same image as a JPG.

Browser support may be improving, but that is only for the newest versions, meaning any user without the most updated systems will not see be able to view WebP images.

In addition, many graphics editing and image display/organizing programs do not read the WebP format without plugins, or cannot read it at all. This is a format Google invented and is currently pushing for.

As for JPEG 2000 (developed in the year 2000) and JPEG XR (developed in 2007) formats, you are welcome to speak with your image sources and look into browser and applications support, file sizes, and resolutions to decide for yourself whether you wish to switch, of course.

In particular, you need to be aware that JPEG 2000 can be saved as a compressed or lossless file, which will affect file size. It also makes sense to understand the limits of the human eye when it comes to resolution. You should also make sure that photo and graphics sharing sites (e.g. Flickr, Deviant Art) and image editing programs support JPEG 2000 and/or JPEG XR.



Settings in Metro Publisher

Please make sure you have the "Don't load requirejs and only load jquery on pages that need it." feature activated in our Beta Settings option here (logged in as admin):

Settings > Beta Features



Ticking that checkbox will keep JavaScript/JQuery from loading on all pages and restrict it to loading only on the pages that need it to function.

For mobile devices, we have outlined the pros and cons of Google AMP (Accelerated Mobile Pages) for you here: Google AMP



Need More Help?

If you would like us to search for ways to improve performance beyond the information in our help documents, we can provide that service via custom support packages under the conditions outlined here: Custom Support

It is usually a process of elimination by turning off services and/or taking out third party code to see the effect. Then you can evaluate the importance of certain services vs. the impact on site performance.


Have more questions? Submit a request


Powered by Zendesk