Welcome to the wonderful world of performance

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.

Overall score

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.

Performance score

The coach knows much about performance best practices and match your pages against them. Checkout the full advice list.

Accessibility score

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.

Web best practice score

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.

Performance advice

Don't scale images in the browser (avoidScalingImages)

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.

Do not load specific print stylesheets. (cssPrint)

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.

Avoid slowing down the critical rendering path (fastRender)

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.

Avoid using Google Tag Manager (googletagmanager)

Google Tag Manager makes it possible for non tech users to add scripts to your page that will downgrade performance.

Inline CSS for faster first render (inlineCss)

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.

Avoid using more than one jQuery version per page (jquery)

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.

Avoid Frontend single point of failures (spof)

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.

Always load third-party JavaScript asynchronously (thirdPartyAsyncJs)

Use JavaScript snippets that load the JS files asynchronously in order to speed up the user experience and avoid blocking the initial load.

Avoid doing redirects (assetsRedirects)

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.

Avoid extra requests by setting cache headers (cacheHeaders)

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.

Long cache headers is good (cacheHeadersLong)

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.

Always compress text content (compressAssets)

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.

Don't close a connection that is used multiple times (connectionKeepAlive)

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.

Avoid spend too much CPU time to render the page (cpuTimeSpentInRendering)

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.

Avoid executing too much JavaScript (cpuTimeSpentInScripting)

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

Total CSS size shouldn't be too big (cssSize)

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.

Avoid redirecting the main document (documentRedirect)

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. :)

The favicon should be small and cacheable (favicon)

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.

Avoid too many fonts (fewFonts)

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.

Avoid too many requests per domain [HTTP/1] (fewRequestsPerDomain)

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.

Response headers should't be too big [HTTP/1] (headerSize)

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.

Total image size shouldn't be too big (imageSize)

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.

Total JavaScript size shouldn't be too big (javascriptSize)

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?

Avoid using incorrect mime types (mimeTypes)

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 each CSS response small (optimalCssSize)

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.

Total page size shouldn't be too big (pageSize)

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.

Don't use private headers on static content (privateAssets)

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.

Avoid missing and error requests (responseOk)

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.

Best practice advice

Declare a charset in your document (charset)

The Unicode Standard (UTF-8) covers (almost) all the characters, punctuations, and symbols in the world. Please use that.

Declare a doctype in your document (doctype)

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.

Declare the language code for your document (language)

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.

Meta description (metaDescription)

Use a page description to make the page more relevant to search engines.

Only use Optimizely when you need it (optimizely)

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.

Page title (pageTitle)

Use a title to make the page more relevant to search engines.

EOL for SPDY in Chrome (spdy)

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.

Have a good URL format (url)

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 too long headers (longHeaders)

Do not send response headersthat are too long.

Avoid use too many response headers (manyHeaders)

Avoid send too many response headers.

Avoid use too many third party responses (thirdParty)

Do not load most of your content from third party URLs.

Avoid Unnecessary Headers (unnecessaryHeaders)

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.

Accessibility advice

Always use an alt attribute on image tags (altImages)

All img tags require an alt attribute. This goes without exception. Everything else is an error. If you have an img tag in your HTML without an alt attribute, add it now. https://www.marcozehe.de/2015/12/14/the-web-accessibility-basics/

Use heading tags to structure your page (headings)

Headings give your document a logical, easy to follow structure. Have you ever wondered how Wikipedia puts together its table of contents for each article? They use the logical heading structure for that, too! The H1 through H6 elements are unambiguous in telling screen readers, search engines and other technologies what the structure of your document is. https://www.marcozehe.de/2015/12/14/the-web-accessibility-basics/

Always set labels on inputs in forms (labelOnInput)

Most input elements, as well as the select and textarea elements, need an associated label element that states their purpose. The only exception is those that produce a button, like the reset and submit buttons do. Others, be it text, checkbox, password, radio (button), search etc. require a label element to be present. https://www.marcozehe.de/2015/12/14/the-web-accessibility-basics/

Structure your content by using landmarks (landmarks)

Landmarks can be article, aside, footer, header, nav or main tag. Adding such landmarks appropriately can help further provide sense to your document and help users more easily navigate it. https://www.marcozehe.de/2015/12/14/the-web-accessibility-basics/

Don't suppress pinch zoom (neverSuppressZoom)

A key feature of mobile browsing is being able to zoom in to read content and out to locate content within a page. http://www.iheni.com/mobile-accessibility-tip-dont-suppress-pinch-zoom/

Use headings tags within section tags to better structure your page (sections)

Section tags should have at least one heading element as a direct descendant.

Use caption and th in tables (table)

Add a caption element to give the table a proper heading or summary. Use th elements to denote column and row headings. Make use of their scope and other attributes to clearly associate what belongs to which. https://www.marcozehe.de/2015/12/14/the-web-accessibility-basics/

Timing metrics

BackEndTime / TTFB

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

FrontEndTime

The time it takes for the browser to parse and create the page. Collected using the Navigation Timing API with the definition: loadEventStart - responseEnd

DOMContentLoadedTime

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

DOMInteractiveTime

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

DomainLookupTime

The time it takes to do the DNS lookup. Collected using the Navigation Timing API with the definition: domainLookupEnd - domainLookupStart

PageDownloadTime

How long time does it take to download the page (the HTML). Collected using the Navigation Timing API with the definition: responseEnd - responseStart

PageLoadTime

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

RedirectionTime

Time spent on redirects. Collected using the Navigation Timing API with the definition: fetchStart - navigationStart

ServerConnectionTime

How long time it takes to connect to the server. Collected using the Navigation Timing API with the definition: connectEnd - connectStart

ServerResponseTime

The time it takes for the server to send the response. Collected using the Navigation Timing API with the definition: responseEnd - requestStart

FirstPaint

This is when the first paint happens on the screen. In Firefox we use timeToNonBlankPaint (that is behind a Firefox preference).

First Contentful Paint

First Contentful Paint (FCP) measures the time from navigation to the time when the browser renders the first bit of content from the DOM.

Largest Contentful Paint

The Largest Contentful Paint (LCP) metric reports the render time of the largest content element visible in the viewport.

Time To DOM Content Flushed

Internal Firefox metric activated by setting the preferencedom.performance.time_to_dom_content_flushed.enabled to true.

Time To Contentful Paint

Firefox implementation of First Contentful Paint. Activated by setting the preferencedom.performance.time_to_contentful_paint.enabled  to true.

Time To First Interactive

Firefox implementation of Time to first interactive. Activated by setting the preferencedom.performance.time_to_first_interactive.enabled to true.

Load Event End

The time when the load event of the current document is completed.

FullyLoaded

The time when all assets in the page is downloaded. The value comes from the latest response in the HAR file.

Speed Index

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.

Contentful Speed Index

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.

First Visual Change

The time when something for the first time is painted within the viewport. Calculated by analysing a video.

Visual Complete 85%

When the page is visually complete to 85% (or more). Calculated by analysing a video.

Visual Complete 95%

When the page is visually complete to 95% (or more). Calculated by analysing a video.

Visual Complete 99%

When the page is visually complete to 99% (or more). Calculated by analysing a video.

Last Visual Change

The time when something for the last time changes within the viewport. Calculated by analysing a video.

Largest Image

The time when the largest image within the viewport has finished painted at the final position on the screen. Calculated by analysing a video.

Heading

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.

RUM-SpeedIndex

A browser version also created by Pat Meenan that calculates the SpeedIndex measurements using Resource Timings. It is not as perfect as Speed Index but a good start.

Image transfer size per page

The size of images per page.

CSS transfer size per page

The transfer size of CSS per page, meaning if the CSS is sent compressed the unpacked size is larger.

JavaScript transfer size per page

The transfer size of JavaScript per page.

Font transfer size per page

The transfer size of fonts per page.

HTML transfer size per page

The transfer size of HTML per page.

Total transfer size per page

The total transfer size of all assets on a page.

Image requests per page

The number of image requests on a page.

CSS requests per page

The number of CSS requests on a page.

JavaScript requests per page

The number of JavaScript requests on a page.

Font requests per page

The number of font requests on a page.

Total amount of requests per page

The total amount of requests on a page.

Critical Axe violations

The number of critical accessibility violations on your page found by Axe. A critical violation means that you should fix it now.

Serious Axe violations

The number of serious accessibility violations on your page found by Axe. A serious violation means that you should fix it now.

Minor Axe violations

The number of monir accessibility violations on your page found by Axe.

Moderate Axe violations

The number of moderate accessibility violations on your page found by Axe.

Total Blocking Time

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.

Max Potential First Input Delay

The worst-case First Input Delay that your users might experience during load. This is calculated using CPU long tasks.

First Input Delay

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.