from the worst...
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
6 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:
- http://ortodoncjakabaty.pl/images/box5.jpg (displayed size: 370x247)
- http://ortodoncjakabaty.pl/images/box2.jpg (displayed size: 370x247)
- http://ortodoncjakabaty.pl/images/box1.jpg (displayed size: 370x247)
- http://ortodoncjakabaty.pl/images/box6.jpg (displayed size: 370x247)
- http://ortodoncjakabaty.pl/images/box3.jpg (displayed size: 370x247)
- http://ortodoncjakabaty.pl/images/box4.jpg (displayed size: 370x247)
On this page, 1 image is resized by less than 35%. This can be consistent in a Responsive Web Design website, so this best practice does not penalize the following resource, but please make sure that it does not affect the page performance:
- http://ortodoncjakabaty.pl/images/logo.jpg (displayed size: 270x66)
1 critical dependency 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.
This resource represents a SPOF for this page:
Consider using jQuery 1.12
You webpage uses jQuery 1.7.2. You should migrate to the latest version of the 1.x branch: jQuery 1.12, that contains several bug and security fixes.
Should I migrate to the last version of jQuery ?
Migrating from a 1. x version of jQuery to the latest version (3.x) can have many unintended impacts and means losing compatibility with older browsers. You should only consider abandoning jQuery 1.x as a part of a complete overhaul of your Front-End infrastructure. As you reflect on it, you will surely discover that you might not need jQuery.
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).
You should use a secured connection (HTTPS)
HTTPS guarantees the confidentiality and security of communications over the internet: data is encrypted, so protected against attacks and data corruption.
Google is multiplying its actions to push more and more websites towards HTTPS. Google first added HTTPS in its SEO criteria (see the announcement). Since then, Chrome has been evolving and now highlights the absence of a secure environment in various cases where information is collected from users. Other browsers are also following this trend.
Setting up HTTPS on a website sometimes causes some reservations (cost, impacts on performance, compatibility with technical partners…). But the market has changed in recent years and you should not worry about migrating to HTTPS. You should consider switching your site to HTTPS.
How to set up the HTTPS protocol
You have to set up a certificate you got from a reliable certification authority. Learn more by contacting your website host who can help you getting this certificate. Besides, the following page help you in your migration procedure to the HTTPS protocol.
A free certificate? Try Let's Encrypt!
Let's Encrypt is a free, automated, and open certificate authority. Many hosting providers offer to enable the generation and automatic renewal of free certificates directly from the administration interface of your domain. Contact your website host for more information.
Define at least <h1> and <h2> tags in your page
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.
No h1, h2 or h3 tag detected on this page.
Did you know?
Do "target=_blank" links introduce a security leak on this page?
target=_blank attribute is rarely recommended. Nevertheless, if you need to use this attribute, note that a security leak could cause harm to your visitors, particularly if your site is open to visitor contributions.
It allows the targeted page to manipulate the window.opener.location property, and thus to perform a redirect within the parent tab. When the user gets back to the parent tab, he can be facing a malicious website (phishing, etc).
We recommend you to add the rel=noreferrer attribute when using a
target = _blank to an external website. This will block access to "window.opener".
If your website allows users to publish contributive content (eg comments, customer reviews, etc.), be sure to automate the addition of this protection. Otherwise, a user could easily exploit this breach.
The following links may be exposed to this vulnerability:
<a target="_blank" href="https://maps.google.com/maps?ll=52.131199,21.062831&z=16&t=m&hl=fr-FR&gl=US&mapclient=apiv3" title="Cliquez ici pour afficher cette zone sur Google Ma...
<a href="https://www.google.com/intl/fr-FR_US/help/terms_maps.html" target="_blank" style="text-decoration: none; cursor: pointer; color: rgb(68, 68, 68);">Conditions d'utilisation</a>
1 domain sends 780 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 780 bytes of cookies:
Domain name: ortodoncjakabaty
PHPSESSID: 780 bytes distributed on 30 request(s)
No <noscript> tag is detected
When a web page uses scripts, it is advised to set at least one
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.
1 cookie may be corrupted on the client side
A cookie must be manipulated on the server side. It is not recommended to use it on the browser.
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 during the following requests by using the
Cookie HTTP header.
You should ensure that the cookie cannot be exploited on the client side.
The HttpOnly directive
By adding the
HttpOnly instruction in the
Some HTTP cookies could be exploited during a XSS attack. You should consider adding the
HttpOnly directive for additional security:
Set-Cookie: PHPSESSID=sb7kopsvirmcht37g0arrcg1e5; path=/
Resources distribution by domain
This page loads data from 6 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
Your font formats are well used
Be sure to deliver the most suitable font format for each platform.
Declaring several font formats
The web browsers (Firefox, Chrome, Safari, Internet Explorer, Opera ...) do not support all the same font formats. Your goal is to use the lightest possible format for each platform. When you use a font, you can specify several formats, via the @font-face CSS instruction: so the browser will use the first compatible format that it supports.
How to declare your font formats?
Check if your formats are well ordered in the
src property. Here's an article about this topic to help you to determine the right order to declare your fonts. TL; DR order to respect for your webfont formats: EOT, WOFF2, WOFF, TTF, and SVG.
All fonts are well ordered in the
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.
This page uses only standard image formats
The images that use a non-standard format may not be indexed by search engines.
Only these image formats are considered standard on the web: jpeg, jpg, png, gif, svg, ico, webp. You should consider an alternative to any other format.
Moreover, remember to treat the text around your images: some search engines analyze approximately the 10 words preceding and following the image in order to add a context to the image.
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:
Dobry ortodonta Warszawa - Ursynów
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.