The help file explains different metrics, so it easier to understand what sitespeed.io collects. When you need more information, you should checkout https://www.sitespeed.io.
The average combined performance, accessibility and best practices score from the Coach. If the score is 100 you are doing fantastic, there's no more you can do here.
The coach knows much about performance best practices and match your pages against them. Checkout the full advice list.
Make sure your site is accessible and usable for everyone. The coach can learn more about accessibility so please help out . You can read more about making the web accessible here.
You want your page to follow web best practice and the coach helps you with that. Making sure your page is set up for search engines, have good URL structure and more. Read all the advice.
It's easy to scale images in the browser and make sure they look good in different devices, however that is bad for performance! Scaling images in the browser takes extra CPU time and will hurt performance on mobile. And the user will download extra kilobytes (sometimes megabytes) of data that could be avoided. Don't do that, make sure you create multiple version of the same image server-side and serve the appropriate one.
Loading a specific stylesheet for printing slows down the page, even though it is not used. You can include the print styles inside your other CSS file(s) just by using an @media query targeting type print.
The critical rendering path is what the browser needs to do to start rendering the page. Every file requested inside of the head element will postpone the rendering of the page, because the browser need to do the request. Avoid loading JavaScript synchronously inside of the head (you should not need JavaScript to render the page), request files from the same domain as the main document (to avoid DNS lookups) and inline CSS or use server push for really fast rendering and a short rendering path.
Google Tag Manager makes it possible for non tech users to add scripts to your page that will downgrade performance.
In the early days of the Internet, inlining CSS was one of the ugliest things you can do. That has changed if you want your page to start rendering fast for your user. Always inline the critical CSS when you use HTTP/1 and HTTP/2 (avoid doing CSS requests that block rendering) and lazy load and cache the rest of the CSS. It is a little more complicated when using HTTP/2. Does your server support HTTP push? Then maybe that can help. Do you have a lot of users on a slow connection and are serving large chunks of HTML? Then it could be better to use the inline technique, becasue some servers always prioritize HTML content over CSS so the user needs to download the HTML first, before the CSS is downloaded.
There are sites out there that use multiple versions of jQuery on the same page. You shouldn't do that because the user will then unnecessarily download extra data. Cleanup the code and make sure you only use one version.
Long CPU tasks locks the thread. To the user this is commonly visible as a "locked up" page where the browser is unable to respond to user input; this is a major source of bad user experience on the web today. However the CPU Long Task is depending on the computer/phones actual CPU speed, so you should measure this on the same type of the device that your user is using.
A page can be stopped from loading in the browser if a single JavaScript, CSS, and in some cases a font, couldn't be fetched or is loading really slowly (the white screen of death). That is a scenario you really want to avoid. Never load 3rd-party components synchronously inside of the head tag.
Use JavaScript snippets that load the JS files asynchronously in order to speed up the user experience and avoid blocking the initial load.
A redirect is one extra step for the user to download the asset. Avoid that if you want to be fast. Redirects are even more of a showstopper on mobile.
The easiest way to make your page fast is to avoid doing requests to the server. Setting a cache header on your server response will tell the browser that it doesn't need to download the asset again during the configured cache time! Always try to set a cache time if the content doesn't change for every request.
Setting a cache header is good. Setting a long cache header (at least 30 days) is even better beacause then it will stay long in the browser cache. But what do you do if that asset change? Rename it and the browser will pick up the new version.
In the early days of the Internet there were browsers that didn't support compressing (gzipping) text content. They do now. Make sure you compress HTML, JSON, JavaScript, CSS and SVG. It will save bytes for the user; making the page load faster and use less bandwith.
Use keep-alive headers and don't close the connection when we have multiple requests to the same domain. There has been some hacks in the past that suggested closing the connection as fast as possible in order to create new ones, but that shouldn't be applicable anymore.
You need to be able to render the page fast. This metric depends on which computer/device you run on but the limit here is high: Spending more time than 500 ms will alert this advice.
Do not run too much JavaSript, that will slow down the page for your user. This metric depends on which computer/device you run on but the limit here is high: Spending more time than 1000 ms will alert this advice
Delivering a massive amount of CSS to the browser is not the best thing you can do, because it means more work for the browser when parsing the CSS against the HTML and that makes the rendering slower. Try to send only the CSS that is used on that page. And make sure to remove CSS rules when they aren't used anymore.
You should never ever redirect the main document, because it will make the page load slower for the user. Well, you should redirect the user if the user tries to use HTTP and there's an HTTPS version of the page. The coach checks for that. :)
It is easy to make the favicon big but please avoid doing that, because every browser will then perform an unnecessarily large download. And make sure the cache headers are set for a long time for the favicon. It is easy to miss since it's another content type.
How many fonts do you need on a page for the user to get the message? Fonts can slow down the rendering of content, try to avoid loading too many of them because worst case it can make the text invisible until they are loaded (FOIT—flash of invisible text), best case they will flicker the text content when they arrive.
Browsers have a limit on how many concurrent requests they can do per domain when using HTTP/1. When you hit the limit, the browser will wait before it can download more assets on that domain. So avoid having too many requests per domain.
Avoid a lot of cookies and other stuff that makes your headers big when you use HTTP/1 because the headers are not compressed. You will send extra data to the user.
Avoid having too many large images on the page. The images will not affect the first paint of the page, but it will eat bandwidth for the user.
A lot of JavaScript often means you are downloading more than you need. How complex is the page and what can the user do on the page? Do you use multiple JavaScript frameworks?
It's not a great idea to let browsers guess content types (content sniffing), in some cases it can actually be a security risk.
Make CSS responses small to fit into the magic number TCP window size of 14.5 KB. The browser can then download the CSS faster and that will make the page start rendering earlier.
Avoid having pages that have a transfer size over the wire of more than 2 MB (desktop) and 1 MB (mobile) because that is really big and will hurt performance and will make the page expensive for the user if she/he pays for the bandwidth.
If you set private headers on content, that means that the content are specific for that user. Static content should be able to be cached and used by everyone. Avoid setting the cache header to private.
Your page should never request assets that return a 400 or 500 error. These requests are never cached. If that happens something is broken. Please fix it.
The Unicode Standard (UTF-8) covers (almost) all the characters, punctuations, and symbols in the world. Please use that.
The <!DOCTYPE> declaration is not an HTML tag; it is an instruction to the web browser about what version of HTML the page is written in.
According to the W3C recommendation you should declare the primary language for each Web page with the lang attribute inside the <html> tag https://www.w3.org/International/questions/qa-html-language-declarations#basics.
Cumulative Layout Shift measures the sum total of all individual layout shift scores for every unexpected layout shift that occurs during the entire lifespan of the page. A layout shift occurs any time a visible element changes its position from one rendered frame to the next.
Use a page description to make the page more relevant to search engines.
Use Optimizely with care because it hurts your performance since JavaScript is loaded synchronously inside of the head tag, making the first paint happen later. Only turn on Optimzely (= load the javascript) when you run your A/B tests.
Use a title to make the page more relevant to search engines.
Chrome dropped supports for SPDY in Chrome 51, upgrade to HTTP/2 as soon as possible. The page has more users (browsers) supporting HTTP/2 than supports SPDY.
A clean URL is good for the user and for SEO. Make them human readable, avoid too long URLs, spaces in the URL, too many request parameters, and never ever have the session id in your URL.
Do not send response headers that are too long.
Avoid send too many response headers.
Do not load most of your content from third party URLs.
Do not send headers that you don't need. We look for p3p, cache-control and max-age, pragma, server and x-frame-options headers. Have a look at Andrew Betts - Headers for Hackers talk as a guide https://www.youtube.com/watch?v=k92ZbrY815c or read https://www.fastly.com/blog/headers-we-dont-want.
The time it takes for the network and the server to generate and start sending the HTML. Collected using the Navigation Timing API with the definition: responseStart - navigationStart
The time it takes for the browser to parse and create the page. Collected using the Navigation Timing API with the definition: loadEventStart - responseEnd
The time the browser takes to parse the document and execute deferred and parser-inserted scripts including the network time from the users location to your server. Collected using the Navigation Timing API with the definition: domContentLoadedEventStart - navigationStart
The time the browser takes to parse the document, including the network time from the users location to your server. Collected using the Navigation Timing API with the definition: domInteractive - navigationStart
The time it takes to do the DNS lookup. Collected using the Navigation Timing API with the definition: domainLookupEnd - domainLookupStart
How long time does it take to download the page (the HTML). Collected using the Navigation Timing API with the definition: responseEnd - responseStart
The time it takes for page to load, from initiation of the page view (e.g., click on a page link) to load completion in the browser. Important: this is only relevant to some pages, depending on how you page is built. Collected using the Navigation Timing API with the definition: loadEventStart - navigationStart
Time spent on redirects. Collected using the Navigation Timing API with the definition: fetchStart - navigationStart
How long time it takes to connect to the server. Collected using the Navigation Timing API with the definition: connectEnd - connectStart
The time it takes for the server to send the response. Collected using the Navigation Timing API with the definition: responseEnd - requestStart
This is when the first paint happens on the screen. In Firefox we use timeToNonBlankPaint (that is behind a Firefox preference).
First Contentful Paint (FCP) measures the time from navigation to the time when the browser renders the first bit of content from the DOM.
The Largest Contentful Paint (LCP) metric reports the render time of the largest content element visible in the viewport.
Internal Firefox metric activated by setting the preferencedom.performance.time_to_dom_content_flushed.enabled to true.
Firefox implementation of First Contentful Paint. Activated by setting the preferencedom.performance.time_to_contentful_paint.enabled to true.
Firefox implementation of Time to first interactive. Activated by setting the preferencedom.performance.time_to_first_interactive.enabled to true.
The time when the load event of the current document is completed.
The time when all assets in the page is downloaded. The value comes from the latest response in the HAR file.
The Speed Index is the average time at which visible parts of the page are displayed. It is expressed in milliseconds and dependent on size of the view port. It was created by Pat Meenan and you can checkout the full documentation here.
This new metric is developed by Bas Schouten at Mozilla which uses edge detection to calculate the amount of "content" that is visible on each frame. It was primarily designed for two main purposes: Have a good metric to measure the amount of text that is visible. Design a metric that is not easily fooled by the pop up splash/login screens that commonly occur at the end of a page load. These can often disturb the speed index numbers since the last frame that is being used as reference is not accurate.
The time when something for the first time is painted within the viewport. Calculated by analysing a video.
When the page is visually complete to 85% (or more). Calculated by analysing a video.
When the page is visually complete to 95% (or more). Calculated by analysing a video.
When the page is visually complete to 99% (or more). Calculated by analysing a video.
The time when something for the last time changes within the viewport. Calculated by analysing a video.
The time when the largest image within the viewport has finished painted at the final position on the screen. Calculated by analysing a video.
The time when the largest H1 heading within the viewport has finished painted at the final position on the screen. Calculated by analysing a video.
The time when the logo (configured with --scriptInput.visualElements) within the viewport has finished painted at the final position on the screen. Calculated by analysing a video.
The size of images per page.
The transfer size of CSS per page, meaning if the CSS is sent compressed the unpacked size is larger.
The transfer size of JavaScript per page.
The transfer size of fonts per page.
The transfer size of HTML per page.
The total transfer size of all assets on a page.
The number of image requests on a page.
The number of CSS requests on a page.
The number of JavaScript requests on a page.
The number of font requests on a page.
The total amount of requests on a page.
The number of critical accessibility violations on your page found by Axe. A critical violation means that you should fix it now.
The number of serious accessibility violations on your page found by Axe. A serious violation means that you should fix it now.
The number of monir accessibility violations on your page found by Axe.
The number of moderate accessibility violations on your page found by Axe.
The blocking time of a given long task is its duration in excess of 50 ms (or the time you have configured with --browsertime.minLongTaskLength). And the total blocking time for a page is the sum of the blocking time for each long task that happens after first contentful paint.
The worst-case First Input Delay that your users might experience during load. This is calculated using CPU long tasks.
First Input Delay measures the time from when a user first interacts with your site (when they click a link, tap on a button etc) to the time when the browser is actually able to respond to that interaction. You need to use scripting to actively do something with the page for this metric to be collected.
