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 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.
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.
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.
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 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.
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.
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.
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 showstoppers 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 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.
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 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.
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.
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 a HTTPS version of the page. The coach check for that. :)
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.
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.
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.
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 page. The images will not affect the first paint of the page but it will eat bandwith 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 14.5 kB. The browser can then download the CSS faster and that will make the page start render earlier.
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.
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.
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.
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.
Google Analytics share private user information with Google that your user hasn't agreed on sharing.
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/.
Using HTTP/2 together with HTTPS is the new best practice. If you use HTTPS (you should), you should also use HTTP/2.
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.
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.
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/
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/
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/
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/
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/
Section tags should have at least one heading element as a direct descendant.
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/
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.
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.
The time when something for the first time is painted within the viewport. Calculated by analyzing a video.
When the page is visually complete to 85% (or more). Calculated by analyzing a video.
When the page is visually complete to 95% (or more). Calculated by analyzing a video.
When the page is visually complete to 99% (or more). Calculated by analyzing a video.
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.
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.
