Quality and Performance reporthttps://descontrol.pro/obrabotka-ot-kleschey/
Report generated on May 13, 2019 12:48:02 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
14 images are resized on browser side
Images must not be delivered larger than they are actually displayed to avoid loading unnecessary data.
Resizing images explained
Resizing images on browser side to reduce their rendering size is not recommended.
For instance, if your image is set to render at 300px by 300px on a particular page, don't upload the original 1000px by 1000px version of that image to your page. Instead, resize/crop the image to fit the display size and then upload it to your site to decrease the page weight and loading time.
Using images with responsive designs or retina screens?
Responsive website designs and retina screens do not justify an image resizing. Even in such cases, some methods exist to deliver your pictures to the right size. We recommend reading the following resources:
- Introduction to responsive images
- Picturefill, to start using the <picture> element
- RICG, group of developers working on responsive images
Don't resize the following images:
- descontrol.pro/data/picture[...]?rand=7772 (displayed size: 90x90)
- descontrol.pro/data/picture[...]?rand=8096 (displayed size: 30x30)
- descontrol.pro/data/picture[...]?rand=9688 (displayed size: 30x30)
- descontrol.pro/data/picture[...]?rand=5681 (displayed size: 20x20)
- descontrol.pro/data/picture[...]?rand=2509 (displayed size: 70x70)
- descontrol.pro/data/picture[...]?rand=1330 (displayed size: 20x20)
- descontrol.pro/data/picture[...]?rand=9649 (displayed size: 30x30)
- descontrol.pro/data/picture[...]?rand=6401 (displayed size: 30x30)
- descontrol.pro/data/picture[...]?rand=6378 (displayed size: 30x30)
- descontrol.pro/data/picture[...]?rand=9884 (displayed size: 30x30)
- descontrol.pro/data/picture[...]g?rand=394 (displayed size: 70x70)
- descontrol.pro/data/picture[...]?rand=6963 (displayed size: 30x30)
- descontrol.pro/data/picture[...]?rand=1067 (displayed size: 30x30)
- descontrol.pro/data/picture[...]?rand=7862 (displayed size: 70x70)
On this page, 2 images are resized by less than 35%. This can be consistent in a Responsive Web Design website, so this best practice does not penalize the following resources, but please make sure that they do not affect the page performance:
Reduce resources response time
The server response time has to be as fast as possible.
The server response time explained
This time corresponds to the period between when the server receives the request and when the network returns the response. This response time can be reduced because of slow application logic, slow database queries, slow routing, frameworks, libraries, resource CPU starvation, or memory starvation.
How can I fix this?
Identify the cause of the slowdown and make sure the server response time is as short as possible. According to Google, a response time under 200ms is acceptable.
The server's response time takes too long with the following resources:
- descontrol.pro/data/pictures/icons/2[...]7f.png?rand=1067 (waiting 1,94 seconds)
- descontrol.pro/data/pictures/icons/2[...]6f.png?rand=6963 (waiting 1,94 seconds)
- descontrol.pro/data/pictures/icons/2[...]cf.png?rand=6378 (waiting 3,97 seconds)
- descontrol.pro/data/pictures/icons/2[...]81.png?rand=9649 (waiting 2,32 seconds)
- descontrol.pro/data/pictures/icons/2[...]f3.png?rand=1330 (waiting 3,98 seconds)
- descontrol.pro/data/pictures/icons/2[...]6a.png?rand=8096 (waiting 2,94 seconds)
- descontrol.pro/data/pictures/icons/2[...]67.png?rand=9884 (waiting 3,96 seconds)
- descontrol.pro/data/pictures/icons/2[...]ae8.png?rand=394 (waiting 2,94 seconds)
- descontrol.pro/data/pictures/icons/2[...]31.png?rand=2509 (waiting 3,95 seconds)
- descontrol.pro/data/pictures/icons/2[...]be.png?rand=7862 (waiting 2,57 seconds)
- descontrol.pro/data/pictures/c7fead1[...]67.png?rand=3609 (waiting 2,94 seconds)
- descontrol.pro/data/pictures/5f8a517[...]18.png?rand=8535 (waiting 2,93 seconds)
- descontrol.pro/data/pictures/de6f649[...]e5.png?rand=2117 (waiting 3,97 seconds)
- descontrol.pro/data/pictures/d18afc0[...]10.png?rand=4949 (waiting 3,96 seconds)
- descontrol.pro/data/pictures/0a0c163[...]d0109e9085.jpg?1 (waiting 3,95 seconds)
- https://descontrol.pro/data/fonts/RoubleSans.ttf (waiting 3,92 seconds)
- descontrol.pro/data/libs/jquery/jque[...]3.1.min.js?39099 (waiting 4,70 seconds)
How can I fix this?
First of all, distinguish what portions of your JS is critical and must be loaded as soon as possible, and put them in a specific external file. Keep this file as streamlined as possible, and defer the parsing or execution of all other JS files (learn more).
- 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).
The Content Security Policy is missing
Protect you website from cross-site scripting (XSS) attacks by setting up a restrictive Content-Security-Policy.
XSS attacks explained
XSS attacks are a type of attack in which malicious data is maliciously added to websites. The number of vulnerabilities allowing these attacks is quite large, which is why it is as useful to prevent them as to limit their harmful effects.
You can protect your pages against these attacks and their effects by restricting execution to code portions either legitimized by the domain to which they belong or by a unique integrity token. The code that does not corresponding to this security policy will not be executed and the user will be informed.
You can learn more about XSS attacks on the Open Web Application Security Project (OWASP) Website.
Configure a "Content-Security-Policy" (CSP) HTTP header
Set up a "Content-Security-Policy" (CSP) HTTP header to prevent or limit damage caused by an XSS attack. To specify a security policy 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, only scripts coming from the current host or https://apis.google.com will be executed.
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.
4 cookies are not secure
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 guarantee 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 this 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: PHPSESSID=e2snseijm9p60s2a6c88mcisq5; path=/
Set-Cookie: yandexuid=7919537801557708492; Expires=Tue, 12-May-2020 00:48:12 GMT; Domain=.yandex.ru; Path=/
Set-Cookie: yabs-sid=127061881557708492; Path=/
Set-Cookie: yp=1589244492.yrts.1557708492#1589244492.yrtsi.1557708492; Expires=Thu, 10-May-2029 00:48:12 GMT; Domain=.yandex.ru; Path=/
This page is exposed to "clickjacking" type attacks
Keep malicious people from integrating your pages into their websites.
This kind of attack happens when your page gets integrated with a malicious website via <frame> or <iframe> tags. By doing this, attackers can persuade users that they are on your own page when they are not. The unsuspecting user may enter personal information that is visible on and thus vulnerable to the malicious website.
To avoid this, always indicate which domains have permission to integrate your pages.
How to prevent clickjacking?
There are two main ways to prevent that behavior.
1/ Configure a "X-Frame-Options" HTTP header. Configure your server so the main resource response includes the "X-Frame-Options" HTTP header.
Three values may be defined:
DENYto prevent any frame or iframe from integrating the page;
SAMEORIGINto authorize only frames from the same domain name;
ALLOW-FROM urito indicate the domains allowed to integrate a page into frame (however is not compatible with some browsers)
2/ Define an explicit
frame-ancestors directive into a Content-Security-Policy HTTP Header. "frame-ancestors" directive is a newer, hence supported by fewer browsers, approach that will allow your website to authorize multiple domains instead of only the current origin. Setting this directive to 'none' is similar to
Which approach to choose? If you only have the current domain to allow, do set up the two security features, for better compatibility with older browsers. If you want to allow multiple domains, you should only implement the frame-ancestors security policy.
Neither the "X-Frame-Options" HTTP header nor the "frame-ancestors" security police are configured on this page; you are more likely to be exposed to clickjacking.
Did you know?
Your SSL certificate will expire on 01/17/2020. Update your certificate before that date.
What happens if my certificate expires?
Letting a certificate expire can have consequences for end users who will then see many error or alert messages while browsing the site, warning them of possible frauds, identity thefts or traffic interceptions. These alerts can have a very negative impact on the user's perception of the visited domain.
More informations about jQuery performance
1 domain sends 183 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 183 bytes of cookies:
Domain name: yandex
i: 92 bytes distributed on 1 request(s)
yp: 54 bytes distributed on 1 request(s)
yandexuid: 19 bytes distributed on 1 request(s)
yabs-sid: 18 bytes distributed on 1 request(s)
This page does not load too much data (1.4MB)
A too high page weight slows down the display, especially on low speed connections. This can lead to frustration for users paying for data (see whatdoesmysitecost.com).
Evaluate the Weight of my Web Page
In February 2016, the average weight of 100 most visited websites in the world was 1,38MB.
How to reduce the weight of my page?
You can report to our "Data amount" category to discover the possible optimizations in your case. Images are often involved.
Moreover, make sure to build your web pages in order to load data that is essential to the user experience (rendering optimization of the critical path).
For other contents (social networking plugins, advertising, content at the bottom of the page ...), it is better to delay the loading (asynchronous, lazy-loading ...), so they don't override priority contents.
We strongly recommend that you define performance budgets before you carry out your web projects. These budgets can be settled through the Dareboost monitoring feature.
We have established the weight distribution of the page by resource type:
- Font : 48,47% of total weight
- Images : 41,07% of total weight
- Texts : 1,12% of total weight
- CSS : 0,49% of total weight
- JSON : 0,05% of total weight
Here is the weight of the 10 heaviest resources over the network, and that are necessary to load the page:
- https://descontrol.pro/data/fonts/SegoeUI.ttf (426 kB)
- descontrol.pro/data/pictures/ab9314c[...]8ceaa7217097.jpg (169 kB)
- descontrol.pro/data/pictures/0a0c163[...]d0109e9085.jpg?1 (158 kB)
- descontrol.pro/data/pictures/f15ae84[...]12bb70a970ad.jpg (139 kB)
- descontrol.pro/data/libs/fontAwesome[...]ont.woff?v=4.7.0 (98 kB)
- https://mc.yandex.ru/metrika/tag.js (88 kB)
- https://descontrol.pro/data/fonts/RobotoCondensed.ttf (69 kB)
- https://descontrol.pro/data/fonts/OpenSans.ttf (64 kB)
- descontrol.pro/data/libs/jquery/jque[...]3.1.min.js?39099 (30 kB)
- descontrol.pro/data/pictures/7a02c8d[...]1ea770365804.png (19 kB)
This page contains 28 links
Two kind of links exist:
- Internal links that refer to pages with the same domain name;
- External links that point to other websites (must be relevant and point towards quality content).
If you reference many links, you can ask the SEO crawlers to consider only some of them, by adding the
rel=nofollow attribute to the irrelevant ones (e.g., advertisements).
Here is the distribution of 28 links present in the page:
- 24 internal links (85,71%)
- 4 "follow" external links (14,29%)
- No "nofollow" external link (0,00%)
Your server should be able to communicate with HTTP while it uses a HTTPS connection
Take precautionary measures against attacks like "man in the middle" by making sure to only communicate in HTTPS with the server.
The HTTP Strict Transport Security (HSTS) Header
When you communicate with a server through a secure connection, every sent request towards this server should use the HTTPS protocol. The HTTP HSTS header allows to indicate to the browser that all the requests sent to the domain concerned must be done via HTTPS. If the URL is presented under "http://...", the web browser is automatically going to replace it by "https://...".
However, we advise you to not set this header unless your entire website serves its resources in HTTPS.
For further information, you can read this article.
No HSTS header has been detected on this page.
Well done, these best practices are respected
Your HTML response is not too heavy
Why reduce the code amount of a page?
Before a web page can be displayed, the browser must, among other things, download it, parse it and model it into a document that can be understood by the rendering engine. If the amount of code contained in the page is too large, these steps are slowed down and the rendering is delayed.
How to reduce the amount of code?
Your HTML response should contain only the information that is immediately necessary to display the visible area of the page. Move inline information to external files (JS for scripts, CSS for styles, asynchronous queries for additional content) and simplify the HTML structure of your page.
No empty element detected
<quote> elements must not be empty because if they are, some screen readers will have difficulties interpreting their presence.
Remove these empty elements from you code or decorate them with the
aria-hidden attribute so that the screen readers ignore them.
Your <img> tags use an alt attribute, but 5 are empty
alt attribute is also an important criterion for SEO. Indeed, search engines crawlers cannot parse graphic contents. That is why they use the alternative text to return consistent results, like in Google images.
<img src="product.jpg" alt="My product description"/>
alt attribute is used in several cases unrelated to SEO:
- When a screen reader is in use for accessibility purposes;
- While image is loading, particularly for slow connections;
- When the image file is not found.
You have 24
img tags and they all have the
Warning, you should also note that 5 of your images contain an
alt attribute, but they are empty:
<img src="/data/pictures/c7fead191bfa7758b72cc762f58ac667.png?rand=3609" alt="" title="">
<img src="/data/pictures/5f8a5175e441ce53b0df4377ed428318.png?rand=8535" alt="" title="">
<img src="/data/pictures/de6f64994e60c7f33f4f8f77cff571e5.png?rand=2117" alt="" title="">
<img src="/data/pictures/d18afc0cbc293e182d032d8aac74f110.png?rand=4949" alt="" title="">
<img src="https://mc.yandex.ru/watch/51955022" style="position:absolute; left:-9999px;" alt="" />
If nothing seems appropriate for describing an image, you might set an empty text. We advise you to make sure the majority of your images define a relevant text. Read the W3C recommendations here.
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.
<noscript> tag detected
This page uses
This page defines <h1> and <h2> tags
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:
- 1 <h1> element(s)
- 3 <h2> element(s)
- 2 <h3> element(s)