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 download extra kilobytes (sometime megabytes) of data that could be avoided. Don't do that, make sure you create multiple version of the same image serverside 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 use @media 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 head element will postpone the rendering of the page, because the browser need to do the request. Avoid loading JavaScript synchronously inside of 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 server push for a really fast rendering and 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 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 blocks rendering) and lazy load and cache the rest of the CSS. Using HTTP/2 it is a little more complicated. Does your server support HTTP push? Then maybe that can help. Do you have a lot of users on a slow connection and serving large chunks of HTML? Then it could be better to inline, 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 sites out there that uses multiple version of JQuery on the same page. You shouldn't do that because the user will then download extra amount of data that could be avoided. Cleanup the code and make sure you only use one version.

Avoid Frontend single point of failures (spof)

A page can be stopped to be loaded in the browser, if a single Javascript, CSS and in some cases a font couldn't be fetched or loading really slow (the white screen of death). That is something 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 showstoppers 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 downloand 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 Internet there where browsers that didn't support compressing (gzipping) text content. They do now. Make sure you compress HTML, JSON, Javacript, CSS and SVG. I 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 & 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 and create new ones, but shouldn't be applicable anymore.

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 a HTTPS version of the page. The coach check for that. :)

The favicon should be small and cacheable (favicon)

It is easy to make the favicon big but please avoid that, because every browser will download that. And make sure the cache headers is set for 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, 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 to 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 page. The images will not affect the first paint of the page but it will eat bandwith 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 14.5 kB. The browser can then download the CSS faster and that will make the page start render earlier.

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

Avoid having pages that have 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 bandwith.

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 & used by everyone, avoid setting the cache header to private.

Avoid missing and error requests (responseOk)

Your page you should never request assets that returns a 400 or 500 error. These requests are never cached, they will be done everytime from the browser. 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.

Avoid using Google Analytics (ga)

Google Analytics share private user information with Google that your user hasn't agreed on sharing.

Serve your content securely (https)

A page should always use HTTPS (https://https.cio.gov/everything/). You also need that for HTTP/2! You can get your free SSL/TLC certificate from https://letsencrypt.org/.

Serve your content using HTTP/2 (httpsH2)

Using HTTP/2 together with HTTPS is the new best practice. If you use HTTPS (you should), you should also use HTTP/2.

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.

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


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. If the browser support this metric (only supported in Chrome), we use that.


The time when all assets in the page is downloaded. Calculated using the Resource Timing API.

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.

First Visual Change

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

Visual Complete 85%

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

Visual Complete 95%

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

Visual Complete 99%

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

Last Visual Change

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


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.