Site speed analyses 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.
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. Third-party codes, i.e. scripts that have to load, are the largest drain on page speeds.
The scores you receive will change each time you run a Google PageSpeed Insights (Lighthouse) test due to how Google combines data for the results, and due to individual elements that may change on a page, such as a new Sprocket or different image, from one hour or day to the next.
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.
- Core Web Vitals
- Third-Party Code
- Minimizing Main Thread Work
- Unused JavaScript
- Next Gen Image Formates
- Performance Settings in Metro Publisher
- More Help With PageSpeeds Suggestions
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.
SEO, Google's Page Speed Insights score, and site traffic are pieces of a complicated story that cannot be easily distilled into a numeric score. Google's PageSpeed Insights may not be the best tool to evaluate your efforts. At the very least that information needs to be qualified.
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.
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.
Example:
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 Compatibility & Other Settings option here (logged in as admin):
Settings > Other
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.
Enabling Progressive Web App can positively affect mobile performance. However, it caches heavily so you will need to review the mobile version of your site with and without PWA enabled and decide whether the trade-off is beneficial to you and your readers.
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.
Comments