Quality and Performance reporthttps://sites.google.com/view/muzicland/%D0%B6%D0%B8%D0%B7%D0%BD%D1%8C-%D0%B0%D0%BB%D0%BB%D1%8B-%D0%BF%D1%83%D0%B3%D0%B0%D1%87%D0%B5%D0%B2%D0%BE%D0%B9
Report generated on Apr 28, 2017 8:03:37 AM
But still far from perfection
Share this report by email
Feel free to share this report with your collaborators, by copying the URL from the address bar,
or by clicking below:
Share the report
Tips and best practices:
Things to improve
2 critical dependencies detected
The failure of a third-party content provider could bring an overall breakdown of your website.
Single Point Of Failure
A Frontend Single Point Of Failure (SPOF) is a critical dependency on a third-party content, that may block the entire display of your page in case of failure of the content provider.
As an example, if your web page uses a blocking script hosted by Google’s servers, then your page is reliant on any failure from this script. Please read our blog post dedicated to SPOF for more information.
How to avoid SPOF?
As far as possible, exclude any of these dependencies, even from renowned providers. If you have to use a third-party content, ensure that you choosed an asynchronous integration and that you have a fallback in case of problem.
We are checking if the tested web page depends (in a critical way) on some of most widespread external resources (googleapis, typekit,...). That are known as Frontend SPOF (Single Point Of Failure) cases.
The following resources represent a SPOF for this page:
How can I fix this?
- use the async attribute;
- use the defer attribute;
- make sure your scripts are placed at the bottom of the page (ideally at the end of the body).
Add <h2> titles in your content
We recommend putting page keywords in at least the h1 and h2 tags. Search engines use the h1, h2, and h3 tags for SEO purposes.
This page contains:
- 2 <h1> element(s)
- 1 <h3> element(s)
The Content Security Policy is missing
It is critical to restrict the origin of the contents of your webpage to protect your website from cross-site scripting attacks (XSS).
XSS attacks explained
An XSS attack aims to inject content into a page.
You can protect your pages against these attacks by implementing a content security policy that tells the web browser which servers are allowed to deliver resources on each page. If the browser makes a request to an unauthorized server, it must inform the user.
How can I prevent an XSS attack?
Set up a "Content-Security-Policy" (CSP) HTTP header. To specify a security policy on the source of your resources, configure your server so the response of the first resource contains the "Content-Security-Policy" HTTP header.
Here's an example:
Content-Security-Policy: script-src 'self' https://apis.google.com
In this case, the page loads correctly provided that all the scripts come from the current host or https://apis.google.com.
Please, be careful, if the header is misconfigured, some of your content, scripts, or styles may be blocked. That could cause unwanted side effects. Moreover, the restrictions apply to all pages of the website. We recommend you test the different pages of your website before deploying this header in your production environment.
No Content Security Policy on this page: it is more easily exposed to XSS attacks.
You should define a 'description' meta tag
The page should define a unique description.
Description in search engines
The description of the page may be directly displayed in search engine results pages (SERP):
It allows you to control at best the entry preview in search engines, and to improve the click rate to your page. Learn more.
How to define a page's description?
<meta name="description" content="page description"> and place it in the
description has been found on this page. Please provide a <meta>
1 cookie is not secured
A cookie sent from the server to a web browser via the HTTPs protocol should only transit on a secure connection (except for some specific cases).
HTTP cookies are set by the server to the web browser via the
Set-Cookie HTTP header. Then, the browser transmits the cookies to the server for the next requests by using the
Cookie HTTP header. When the server uses a secure connection (HTTPs), the cookie probably contains some sensitive data: you have to garantee that the cookie cannot be exploited on an insecure connection.
The Secure directive
By adding the
Secure instruction in the
Set-Cookie HTTP header, the server informs the browser that it is allowed to transmit the cookie over secure connection only. Read our blog post to learn more.
The following Cookies are not secure, you should add the
Secure instruction in the
Set-Cookie HTTP header:
set-cookie: NID=102=hroz2o0mC7f_hukoVh8J8H-5gZFSXzmG0VpZviAfEharRycWMjX4FLGGKiADWqyQd6DcxTQrNNAODRTHvAp6Ls9WYqWFhlFLb7Oo4CH_WdNrYhSwTonXYRDDf_VTf5Qv;Domain=.google.com;Path=/;Expires=Sat, 28-Oct-2017 08:03:30 GMT;HttpOnly
Did you know?
9 resources on this page are for public use
By default, the browser accepts to perform AJAX requests, or to retrieve web fonts, only on the same domain name of the page. So a font provided by toto.com can only be used by the pages of toto.com. This prevents misuse of your resources by any site.
Some resources are public, and explicitly want to be available to everyone (eg Google Fonts). In this case, the HTTP header
Access-Control-Allow-Origin can be used with the value "*". You should, however, use this property if your resource has aimed to be used by the greatest number. Otherwise, we recommend that you keep the default, or set a specific domain name in the "Access-Control-Allow-Origin" HTTP header.
You should be aware of the following resources, that use a
Access-Control-Allow-Origin: * HTTP header. Make sure they are actually intended to be used by pages from all domain names:
It appears these files are hosted by a third-party, so they may not be within your control. However, you should consider any alternative to these resources to improve your page performance.
1 domain sends 792 bytes of cookies
HTTP cookies are used to track a user to costumize the page according to their profile. They are sent as a HTTP header from the web server to the browser. Then, each time the browser accesses to the server, it sends a request containing the cookie received at the first response. See more information.
Here, 1 domain sends 792 bytes of cookies:
Domain name: google
NID: 792 bytes distributed on 6 request(s)
The Slowest Resources
The page load time is 2.2 seconds. Listed below, are your site's slowest loading requests:
- sites.google.com/view/muzicland/%D0%B6%[...]%D0%B2%D0%BE%D0%B9 (295ms)
- accounts.google.com/o/oauth2/postmessag[...]UsrYh6TVDGP3oWluHw (184ms)
- https://apis.google.com/js/client.js (149ms)
- apis.google.com/_/scs/apps-static/_/js/[...]w/cb=gapi.loaded_0 (116ms)
- https://sites.google.com/logImpressions?_reqid=29012&rt=j (98ms)
- https://apis.google.com/js/rpc:shindig_random.js?onload=init (59ms)
- apis.google.com/_/scs/apps-static/_/js/[...]w/cb=gapi.loaded_0 (45ms)
- csi.gstatic.com/csi?v=3&s=atari&action=[...]rt=ibm.667,vpr.759 (525ms)
- lh5.googleusercontent.com/ym3Y_TcmQLH0t[...]83p1QXW6lrQQ=w1176 (346ms)
- www.gstatic.com/_/atari/_/ss/k=atari.vw[...]bXT2zUMNrlFn_lWGZA (249ms)
- www.gstatic.com/_/atari/_/js/k=atari.vw[...]OZ_dszU0pGhktNkqXA (219ms)
- www.gstatic.com/_/atari/_/js/k=atari.vw[...]OZ_dszU0pGhktNkqXA (197ms)
- https://www.google-analytics.com/analytics.js (154ms)
- stats.g.doubleclick.net/r/collect?v=1&a[...]v=j52&z=1615518746 (152ms)
- fonts.googleapis.com/css?family=Lato%3A[...]%2C700%2C700italic (134ms)
- https://ssl.gstatic.com/atari/images/favicon_2.ico (120ms)
- https://fonts.gstatic.com/s/lato/v13/EsvMC5un3kjyUhB9ZEPPwg.woff2 (101ms)
Excessively slow response times can be due to any number of reasons, usually because of a heavy resource that's loading or a temporary network issue.
For more information on page load time, you can consult the timeline.
Do all third parties resources deliver the right content?
This page loads data from third parties, you should ensure their integrity.
SubResource Integrity (SRI)
Use SRI to ensure that a third party resource has not been tampered. Add the
integrity attribute to
<link> tags loading this kind of resource. Example:
integrity attribute value is equal to the base64-encoded hash (SHA) of the resource. The browser compares this hash with the downloaded content in order to determine if the resource matches the expected content.
You can create the SHA thanks to several tool. In command line, you can use openssl. You can also test some online tools, as srihash.org or report-uri.io. Learn more about SubResource Integrity.
Specify which SSL certificates can be accepted by the browser
Provide the list of valid public cryptographic keys to the web browser in order to avoid some Man-In-The-Middle attacks.
Public Key Pinning
The HTTP Public Key Pinning header allows to define all the public cryptographic keys supported to access your domain via SSL:
Public-Key-Pins: pin-sha256="base64=="; max-age=expireTime
[; includeSubdomains][; report-uri="reportURI"]
The browser stores this list. During the second visit, it will compare this list with the key provided by the certificate authority (CA). If they don't match, the browser will consider the certificate as corrupted and will block the access to the page.
Please, be careful while configuring this header: if the provided certificates are not up to date, your website will be unreachable (see a detailed feedback). Do specify several certificates, including (at least) one fallback certificate. It will allow to deal with the expiration or invalidation cases of a certificate.
Note: We advise you to deploy it progressively by using the report-only mode (Public-Key-Pins-Report-Only header) and limited cache validation times.
This page doesn't send a Public Key Pinning header.
Resources distribution by domain
This page loads data from 11 domains. This best practice retrieves the following metrics for each of these domains:
- Loading Time (Cumulative): total time spent to load all the resources
- Server Time (Cumulative): total time spent to retrieve the responses from the server (TCP connection + wait for first byte)
- Weight: data amount loaded
- Number of requests
Here is the list of all the domains used by the page:
|Domain||Time (ms)||Server Time (ms)||Weight (kB)||Requests|
Well done, these best practices are respected
All labels refer to an element
for attribute associates the label to an other element of the page, and help screen readers to better interpret your content.
Label and for attribute
A label describes an element (a text to fill, a checkbox, etc.). When a user click on a label associated with a radio button, the option will be directly selected, improving the user experience.
How to use a label?
Associate the label to an element of the page by indicating the ID of the element. Example:
<input type="radio" name="myOptions" id="myId" value="1" >
You do not use too long inline scripts
Any script with a significant size should let the browser cached them in order to reduce loading time/improve performance of your returning visitor.
Inline scripts / cache policy
"inline" scripts allow to integrate easily small portions of scripts directly in the HTML code. Example:
ga('create', 'UA-11111111-1', 'mywebsite.com');
By doing so, you avoid making a request to the server to retrieve the resource. So inline scripts represent a performance gain if you want to integrate small scripts.
However, once a script has a fairly substantial size, we advise you to outsource it and perform a request to retrieve it. So you will benefit from the cache mechanism.
What should I do?
Outsource your scripts with more than 1500 characters in one or more separate files.
No frameset, frame and noframes tags detected
These tags are obsolete, due to several issues related to the navigation consistency, SEO or browsers' bookmark features for example.
None of these tags is detected on this page.
The use of the iframe tag is prefered.
This page specifies a <title> tag
The page should define a unique title (using a <title> tag).
Use of titles by search engines
Once properly configured, the page title can be displayed in the search engine results page:
Using a suitable title is a major criterion for SEO. It allows you to control at best what is displayed in search results pages, and determine the keywords you want your site pops out.
How to define the title of a web page?
The title of the page is specified into the
<title> tag, which must be placed into the
<head> tag, at the beginning of the code.
This page defines a title the
Here is the page's title:
Все об Алле Пугачевой - Жизнь Аллы Пугачевой
No Java applets detected
Java applets are considered obsolete in 2015. HTML5 is powerful and more widely supported. Using Java applets can lead to compatibility issues and may send negative signals to your users (eg the browser indicating that content was blocked because it could be dangerous).
Congratulations, this page doesn't contain Java applets.
Do not use <bgsound> tag
bgsound tag detected. This is a good practice: this element is not a HTML standard. See more information.
Use the audio tag to deliver audio content on your page.
<audio src="my-audio-file.ogg" autoplay>
Your browser doesn't support the