A high number of DOM elements means a lot of work for the browser to render the page.
It also slows down Javascript DOM queries, as there are more elements to search through.
A deep DOM makes the CSS matching with DOM elements difficult.
It also slows down Javascript modifications to the DOM because changing the dimensions of an element makes the browser re-calculate the dimensions of it's parents. Same thing for Javascript events, that bubble up to the document root.
iFrames are the most complex HTML elements. They are pages, just like the main page, and the browser needs to create a new page context, which has a cost.
IDs of HTML elements must be document-wide unique. This can cause problems with getElementById returning the wrong element.
Working with the DOM in Javascript triggers layout calculations and slows down the page.
Try, as much as possible, to have an HTML page fully generated by the server instead of making changes with JS.
DOM queries are like looking in a large catalog of items. Even if the browsers made progress on the performances of queries, websites often make hundreds of them.
Try to reduce the number of queries by refactoring your Javascript code.
Avoid also to have a read query between two write queries. To be able to reduce the number repaints and optimize performances, browsers buffer the DOM writing operations and treat them in bulk. But each time a DOM reading is asked, the browser needs to empty the buffer. This can be particularly slow inside a loop.
This is the number of queries that could be avoided by removing all duplicated queries.
Simply save the result of a query in a variable. Ok it is not always simple, especially with third-party scripts, but at least do it with your own code.
Binding too many events has a cost.
It can be avoided by using "event delegation". Instead of binding events on each element one by one, events delegation binds them on the top level document element and uses the bubbling principle. It will imperceptibly slow down the event when it occurs, but the loading of the page will speed-up.
Just to let you know there are some errors on the page.
Please note that some errors only occur in the PhantomJS browser, so you might need to double check on other browsers.
The 'eval' function is slow and a bad coding practice. Try to get rid of it.
They slow down the page construction, especially if they are used to insert scripts in the page. Remove them ASAP.
If you cannot remove them because they come from a third-party script (such as ads), have a look at PostScribe.
Try to keep your console clean when in production. Debugging is good for development only.
Writing in the console has a cost, especially when dumping large object variables.
There is also a problem with Internet Explorer 8, not knowing the console object.
It is a bad practice because they clutter up the global namespace. If two scripts use the same variable name in the global scope, it can cause conflicts and it is generally hard to debug.
Global variables also take a (very) little bit longer to be accessed than variables in the local scope of a function.
This metric counts the number of DOM queries, DOM inserts, binds, etc. made by the Javascript before the DOMContentLoaded event.
Wait for this event before manipulating the DOM. Do not execute Javascript in the middle of the BODY as it slows down the construction of the DOM and makes a poor maintainability. This is what i call spaghetti code.
The JS Timeline tab can help you identify what's happening.
Current latest versions of jQuery are 1.11 (with support for old IE versions) and 2.1 (without).
Each new version of jQuery optimizes performances. Do not keep an old version of jQuery. Updating can sometimes break a few things, but it is generally quite easy to fix them up. So don't hesitate.
jQuery is a heavy library. You should **never** load jQuery more than one on the same page.
Having a huge number of CSS rules hurts performances. If the number of CSS rules is higher than the number of DOM elements, there is clearly a problem.
Huge stylesheets generally occur when the different pages of a website load all the CSS, concatenated in a single stylesheet, even if a large part of the rules are page-specific. Solution is to create one main CSS file with global rules and one custom files per page.
Complex selectors are CSS selectors with 4 or more expressions, like "#header ul li .foo".
They are adding more work for the browser, and this could be avoided by simplifying selectors.
Complex attributes selectors are one of these:
Their matching process needs more CPU and it has a cost on performances.
Yellow Lab Tools failed to parse a CSS file. I doubt the problem comes from the css parser.
Maybe a CSS validator can help you.
It’s bad for performance to use @import because CSS files don't get downloaded in parallel.
You should use <link rel='stylesheet' href='a.css'> instead.
This is when two or more selectors are strictly identical and should be merged.
This is the number of property definitions duplicated within a selector.
Very easy to fix.
Such as: expression( document.body.clientWidth > 600 ? "600px" : "auto" )
This is a bad practice as it slows down browsers. There are some simpler CSS3 methods for doing this.
It can be useful, but only as a last resort. It is a bad practice because it overrides the normal cascading logic. The more you use !important, the more you need it again to over-override. This conducts to a poor maintainability.
What browser do you need to support? Once you've got the answer, take a look at these old rules that pollute your CSS code and remove them.
IE6:
IE7:
IE9:
Many property prefixes such as -moz- or -webkit- are not needed anymore, or by very few people. You can remove them or replace them with the non-prefixed version. This will help reducing your stylesheets weight.
Universal selectors are the most expensive CSS selectors.
More informations here.
This is one way to remove complexity from a CSS rule. Generally, when "body" is specified in a rule it can be removed, because an element is necessarily inside the body.
Some tags included inside other tags are obvious. For example, when "ul li" is specified in a rule, "ul" can be removed because the "li" element is always inside a "ul". Same thing for "tr td", "select option", ...
Lowering compexity in CSS selectors can make the page load a little faster.
This is one of the most important performance rule. Every request is slowing down the page loading.
There are several technics to reduce their number:
404 errors are never cached, so each time a page ask for it, it hits se server. Even if it is behind a CDN or a reverse-proxy cache.
This counts the number of requests not keeping the connection alive (specifying "Connection: close" in the response headers). It is only counting a request if it is followed by another request on the same domain.
This is slowing down the next request, because the brower needs to open a new connection to the server, which means a additional round-trip.
Correct the problem by setting a Keep-Alive header on the guilty server.
This only happens when the asset has no cache and is requested more than once on the same page. Be very careful about it.
Counts responses with caching disabled (max-age=0)
Fix immediatly if on static assets.
Responses with no caching header sent (either Cache-Control or Expires).
Every request should have a cache time specified. If you really don't want cache, specify "max-age=0", otherwise some browsers will try to cache.
Responses with too short caching time (less than a week).
The longer you cache, the better. Add versionning to your static assets, if it's not already done, and set their cache time to one year.
For each domain met, the browser needs to make a DNS look-up, which is slow. Avoid having to many different domains and the page should render faster.
By the way, domain sharding is not a good practice anymore.
This graph gives a quick view of when the Javascript interactions with the DOM occur during the loading of the page.
The table below shows the interactions between Javascript and the DOM. It is useful to understand what happens while the page loads.
Useless function call, as the jQuery object is empty.
The .bind() method attaches the event listener to each jQuery element one by one. Using the .on() method is preferable if available (from v1.7).
First one is: {{node.data.callDetails.context.firstElementPath}}
The query returned 0 results. Could it be unused or dead code?