We are setting up a CDN to serve CSS, JS and the images. We are wondering what will be the ideal number of hostnames to distribute the ressources across. This technique is use by many websites to increase parallelize downloads and page loading. However, DNS lookups slow down the page loading so the rule is not the more hostname you have, the more performance you will get.
I've read somewhere that the ideal number is between 2 and 4. I wonder if there is a rule of thumbs that apply to all webpages or if there is a rule of thumbs according to the number of ressources being served and the size of them.
Specific case : Our websites are composed of two kinds of pages. One kind serve a list of thumbnails (15-20 or so images, varying) and the other serve a flash or shockwave application (mostly games) with a lot less images. Obviously, we have regular JS, images and CSS on all pages. When I mean regular, that correctly optimized elements, 1 CSS, a few images of the UI, 2/3 JS...
I will love to have answers for our specific case but I will be also very interested to have general answers too!
We (Yahoo!) did a study back in 2007 that showed that 2 is a good number, and anything more than that doesn't improve page performance, in some cases having more than 2 domains degraded performance.
What I would recommend is - if you have a A/B testing infrastructure then go ahead and try it out on your site, use different number of domains and measure the page load time from your end users.
If you don't have a A/B testing framework then just try a different value for few days, measure it, try a new one, measure that ... do this till you find that point where performance starts to degrade.
There is no silver bullet for this recommendation. This is something that depends a lot on how many assets are there on each page and what browser (number of parallel downloads) your end users use. Hope that helps.
Related
Is it worth worrying about CSS rendering performance? Or should we just not worry about efficiency at all with CSS and just focus on writing elegant or maintainable CSS instead?
This question is intended to be a useful resource for front-end developers on which parts of CSS can actually have a significant impact on device performance, and which devices / browsers or engines may be affected. This is not a question about how to write elegant or maintainable CSS, it's purely about performance (although hopefully what's written here can inform more general articles on best-practice).
Existing evidence
Google and Mozilla have written guidelines on writing efficient CSS and CSSLint's set of rules includes:
Avoid selectors that look like regular expressions
..
don't use the complex equality operators to avoid performance penalties
but none of them provide any evidence (that I could find) of the impact these have.
A css-tricks.com article on efficient CSS argues (after outlining a load of efficiency best practices) that we should not .. sacrifice semantics or maintainability for efficient CSS these days.
A perfection kills blog post suggested that border-radius and box-shadow rendered orders of magnitude slower than simpler CSS rules. This was hugely significant in Opera's engine, but insignificant in Webkit. Further, a smashing magazine CSS benchmark found that rendering time for CSS3 display rules was insignificant and significantly faster than rendering the equivalent effect using images.
Know your mobile tested various mobile browsers and found that they all rendered CSS3 equally insignificantly fast (in 12ms) but it looks like they did the tests on a PC, so we can't infer anything about how hand-held devices perform with CSS3 in general.
There are many articles on the internet on how to write efficient CSS. However, I have yet to find any comprehensive evidence that badly considered CSS actually has a significant impact on the rendering time or snappiness of a site.
Background
I offered bounty for this question to try to use the community power of SO to create a useful well-researched resource.
The first thing that comes to mind here is: how clever is the rendering engine you're using?
That, generic as it sounds, matters a lot when questioning the efficiency of CSS rendering/selection. For instance, suppose the first rule in your CSS file is:
.class1 {
/*make elements with "class1" look fancy*/
}
So when a very basic engine sees that (and since this is the first rule), it goes and looks at every element in your DOM, and checks for the existence of class1 in each. Better engines probably map classnames to a list of DOM elements, and use something like a hashtable for efficient lookup.
.class1.class2 {
/*make elements with both "class1" and "class2" look extra fancy*/
}
Our example "basic engine" would go and revisit each element in DOM looking for both classes. A cleverer engine will compare n('class1') and n('class2') where n(str) is number of elements in DOM with the class str, and takes whichever is minimum; suppose that's class1, then passes on all elements with class1 looking for elements that have class2 as well.
In any case, modern engines are clever (way more clever than the discussed example above), and shiny new processors can do millions (tens of millions) of operations a second. It's quite unlikely that you have millions of elements in your DOM, so the worst-case performance for any selection (O(n)) won't be too bad anyhow.
Update: To get some actual practical illustrative proof, I've decided to do some tests. First of all, to get an idea about how many DOM elements on average we can see in real-world applications, let's take a look at how many elements some popular sites' webpages have:
Facebook: ~1900 elements (tested on my personal main page).
Google: ~340 elements (tested on the main page, no search results).
Google: ~950 elements (tested on a search result page).
Yahoo!: ~1400 elements (tested on the main page).
Stackoverflow: ~680 elements (tested on a question page).
AOL: ~1060 elements (tested on the main page).
Wikipedia: ~6000 elements, 2420 of which aren't spans or anchors (Tested on the Wikipedia article about Glee).
Twitter: ~270 elements (tested on the main page).
Summing those up, we get an average of ~1500 elements. Now it's time to do some testing. For each test, I generated 1500 divs (nested within some other divs for some tests), each with appropriate attributes depending on the test.
The tests
The styles and elements are all generated using PHP. I've uploaded the PHPs I used, and created an index, so that others can test locally: little link.
Results:
Each test is performed 5 times on three browsers (the average time is reported): Firefox 15.0 (A), Chrome 19.0.1084.1 (B), Internet Explorer 8 (C):
A B C
1500 class selectors (.classname) 35ms 100ms 35ms
1500 class selectors, more specific (div.classname) 36ms 110ms 37ms
1500 class selectors, even more specific (div div.classname) 40ms 115ms 40ms
1500 id selectors (#id) 35ms 99ms 35ms
1500 id selectors, more specific (div#id) 35ms 105ms 38ms
1500 id selectors, even more specific (div div#id) 40ms 110ms 39ms
1500 class selectors, with attribute (.class[title="ttl"]) 45ms 400ms 2000ms
1500 class selectors, more complex attribute (.class[title~="ttl"]) 45ms 1050ms 2200ms
Similar experiments:
Apparently other people have carried out similar experiments; this one has some useful statistics as well: little link.
The bottom line: Unless you care about saving a few milliseconds when rendering (1ms = 0.001s), don't bother give this too much thought. On the other hand, it's good practice to avoid using complex selectors to select large subsets of elements, as that can make some noticeable difference (as we can see from the test results above). All common CSS selectors are reasonably fast in modern browsers.
Suppose you're building a chat page, and you want to style all the messages. You know that each message is in a div which has a title and is nested within a div with a class .chatpage. It is correct to use .chatpage div[title] to select the messages, but it's also bad practice efficiency-wise. It's simpler, more maintainable, and more efficient to give all the messages a class and select them using that class.
The fancy one-liner conclusion:
Anything within the limits of "yeah, this CSS makes sense" is okay.
Most answers here focus on selector performance as if it were the only thing that matters. I'll try to cover some spriting trivia (spoiler alert: they're not always a good idea), css used value performance and rendering of certain properties.
Before I get to the answer, let me get an IMO out of the way: personally, I strongly disagree with the stated need for "evidence-based data". It simply makes a performance claim appear credible, while in reality the field of rendering engines is heterogenous enough to make any such statistical conclusion inaccurate to measure and impractical to adopt or monitor.
As original findings quickly become outdated, I'd rather see front-end devs have an understanding of foundation principles and their relative value against maintainability/readability brownie points - after all, premature optimization is the root of all evil ;)
Let's start with selector performance:
Shallow, preferably one-level, specific selectors are processed faster. Explicit performance metrics are missing from the original answer but the key point remains: at runtime an HTML document is parsed into a DOM tree containing N elements with an average depth D and than has a total of S CSS rules applied. To lower computational complexity O(N*D*S), you should
Have the right-most keys match as few elements as possible - selectors are matched right-to-left^ for individual rule eligibility so if the right-most key does not match a particular element, there is no need to further process the selector and it is discarded.
It is commonly accepted that * selector should be avoided, but this point should be taken further. A "normal" CSS reset does, in fact, match most elements - when this SO page is profiled, the reset is responsible for about 1/3 of all selector matching time so you may prefer normalize.css (still, that only adds up to 3.5ms - the point against premature optimisation stands strong)
Avoid descendant selectors as they require up to ~D elements to be iterated over. This mainly impacts mismatch confirmations - for instance a positive .container .content match may only require one step for elements in a parent-child relationship, but the DOM tree will need to be traversed all the way up to html before a negative match can be confirmed.
Minimize the number of DOM elements as their styles are applied individually (worth noting, this gets offset by browser logic such as reference caching and recycling styles from identical elements - for instance, when styling identical siblings)
Remove unused rules since the browser ends up having to evaluate their applicability for every element rendered. Enough said - the fastest rule is the one that isn't there :)
These will result in quantifiable (but, depending on the page, not necessarily perceivable) improvements from a rendering engine performance standpoint, however there are always additional factors such as traffic overhead and DOM parsing etc.
Next, CSS3 properties performance:
CSS3 brought us (among other things) rounded corners, background gradients and drop-shadow variations - and with them, a truckload of issues. Think about it, by definition a pre-rendered image performs better than a set of CSS3 rules that has to be rendered first. From webkit wiki:
Gradients, shadows, and other decorations in CSS should be used only
when necessary (e.g. when the shape is dynamic based on the content) -
otherwise, static images are always faster.
If that's not bad enough, gradients etc. may have to be recalculated on every repaint/reflow event (more details below). Keep this in mind until the majority of users user can browse a css3-heavy page like this without noticeable lag.
Next, spriting performance:
Avoid tall and wide sprites, even if their traffic footprint is relatively small. It is commonly forgotten that a rendering engine cannot work with gif/jpg/png and at runtime all graphical assets are operated with as uncompressed bitmaps. At least it's easy to calculate: this sprite's width times height times four bytes per pixel (RGBA) is 238*1073*4≅1MB. Use it on a few elements across different simultaneously open tabs, and it quickly adds up to a significant value.
A rather extreme case of it has been picked up on mozilla webdev, but this is not at all unexpected when questionable practices like diagonal sprites are used.
An alternative to consider is individual base64-encoded images embedded directly into CSS.
Next, reflows and repaints:
It is a misconception that a reflow can only be triggered with JS DOM manipulation - in fact, any application of layout-affecting style would trigger it affecting the target element, its children and elements following it etc. The only way to prevent unnecessary iterations of it is to try and avoid rendering dependencies. A straightforward example of this would be rendering tables:
Tables often require multiple passes before the layout is completely established because they are one of the rare cases where elements can
affect the display of other elements that came before them on the DOM.
Imagine a cell at the end of the table with very wide content that
causes the column to be completely resized. This is why tables are not
rendered progressively in all browsers.
I'll make edits if I recall something important that has been missed. Some links to finish with:
http://perfectionkills.com/profiling-css-for-fun-and-profit-optimization-notes/
http://jacwright.com/476/runtime-performance-with-css3-vs-images/
https://developers.google.com/speed/docs/best-practices/payload
https://trac.webkit.org/wiki/QtWebKitGraphics
https://blog.mozilla.org/webdev/2009/06/22/use-sprites-wisely/
http://dev.opera.com/articles/view/efficient-javascript/
While it's true that
computers were way slower 10 years ago.
You also have a much wider variety of device that are capable of accessing your website these days. And while desktops/laptops have come on in leaps and bounds, the devices in the mid and low end smartphone market, in many cases aren't much more powerful than what we had in desktops ten years ago.
But having said that CSS Selection speed is probably near the bottom of the list of things you need to worry about in terms of providing a good experience to as broad a device range as possible.
Expanding upon this I was unable to find specific information relating to more modern browsers or mobile devices struggling with inefficient CSS selectors but I was able to find the following:
http://www.stevesouders.com/blog/2009/03/10/performance-impact-of-css-selectors/
Quite dated (IE8, Chrome 2) now but has a decent attempt of establishing efficiency of various selectors in some browsers and also tries to quantify how the # of CSS rules impacts page rendering time.
http://www.thebrightlines.com/2010/07/28/css-performance-who-cares/
Again quite dated (IE8, Chrome 6) but goes to extremes in inefficient CSS selectors * * * * * * * * * { background: #ff1; } to establish performance degradation.
For such a large bounty I am willing to risk the Null answer: there are no official CSS selectors that cause any appreciable slow-downs in the rendering, and (in this day of fast computers and rapid browser iteration) any that are found are quickly solved by browser makers. Even in mobile browsers there is no problem, unless the unwary developer is willing to use non-standard jQuery selectors. These are marked as risky by the jQuery developers, and can indeed be problematic.
In this case the lack of evidence is evidence of the lack of problems. So, use semantic markup (especially OOCSS), and report any slow-downs that you find when using standard CSS selectors in obscure browsers.
People from the future: CSS performance problems in 2012 were already a thing of the past.
isn't css a irrelevant way to make it faster, it must be the last thing you look at when you look at performance. Make your css in what ever way that suites you, compile it. and then put it in the head. This might be rough but their are loads of other things to look for when your looking in to browser performance. If you work at a digital bureau you wont get paid to do that extra 1ms in load time.
As i commented use pagespeed for chrome its a google tool that analyze the website in 27 parameters css is 1 of them.
My post just concern exactly, wouldn't rather have around 99% of web users be able to open the website and see it right, even the people with IE7 and such. Than closing out around 10% by using css3, (If it turns out that you can get an extra 1-10ms on performance).
Most people have atleast 1mbit/512kbit or higher, and if you load a heavy site it takes around 3 secounds to load, but you can save 10ms maybe on css??
And when it comes to mobile devices you should make sites just for mobiles so when you have a device with screen size less than "Width"px, you have a separate site
Please comment below this is my perspective and my personal experience with web development
While not directly code-related, using <link> over #import to include your stylesheets provides much faster performance.
'Don’t use #import' via stevesouders.com
The article contains numerous speed test examples between each type as well as including one type with another (ex: A CSS file called via <link> also contains #import to another css file).
I devised an idea a long time ago and never got around to implementing it, and I would like to know whether it is practical in that it would work to significantly decrease loading times for modern browsers. It relies on the fact that related tasks are often done more quickly when they are done together in bulk, and that the browser could be downloading content on different pages using a statistical model instead of being idle while the user is browsing. I've pasted below an excerpt from what I originally wrote, which describes the idea.
Description.
When people visit websites, I
conjecture that that a probability
density function P(q, t), where q is a
real-valued integer representing the
ID of a website and t is another
real-valued, non-negative integer
representing the time of the day, can
predict the sequence of webpages
visited by the typical human
accurately enough to warrant
requesting and loading the HTML
documents the user is going to read in
advance. For a given website, have the
document which appears to be the "main
page" of the website through which
users access the other sections be
represented by the root of a tree
structure. The probability that the
user will visit the root node of the
tree can be represented in two ways.
If the user wishes to allow a process
to automatically execute upon the
initialization of the operating system
to pre-fetch webpages from websites
(using a process elaborated later)
which the user frequently accesses
upon opening the web browser, the
probability function which determines
whether a given website will have its
webpages pre-fetched can be determined
using a self-adapting heuristic model
based on the user's history (or by
manual input). Otherwise, if no such
process is desired by the user, the
value of P for the root node is
irrelevant, since the pre-fetching
process is only used after the user
visits the main page of the website.
Children in the tree described earlier
are each associated with an individual
probability function P(q, t) (this
function can be a lookup table which
stores time-webpage pairs). Thus, the
sequences of webpages the user visits
over time are logged using this tree
structure. For instance, at 7:00 AM,
there may be a 71/80 chance that I
visit the "WTF" section on Reddit
after loading the main page of that
site. Based on the values of the
p> robability function P for each node
in the tree, chains of webpages
extending a certain depth from the
root node where the net probability
that each sequence is followed, P_c,
is past a certain threshold, P_min,
are requested upon the user visiting
the main page of the site. If the
downloading of one webpage finishes
before before another is processed, a
thread pool is used so that another
core is assigned the task of parsing
the next webpage in the queue of
webpages to be parsed. Hopefully, in
this manner, a large portion of those
webpages the user clicks may be
displayed much more quickly than they
would be otherwise.
I left out many details and optimizations since I just wanted this to be a brief description of what I was thinking about. Thank you very much for taking the time to read this post; feel free to ask any further questions if you have them.
Interesting idea -- and there have been some implementations for pre-fetching in browsers though without the brains you propose -- which could help alot. I think there are some flaws with this plan:
a) web page browsing, in most cases, is fast enough for most purposes.
b) bandwidth is becoming metered -- if I'm just glancing at the home page, do I as a user want to pay to serve the other pages. Moreover, in the cases where this sort of thing could be useful (eg--slow 3g connection), bandwidth tends to be more tightly metered. And perhaps not so good at concurrency (eg -- CDMA 3g connections).
c) from a server operator's point of view, I'd rather just serve requested pages in most cases. Rendering pages that don't ever get seen costs me cycles and bandwidth. If you are like alot of folks and on some cloud computing platform, you are paying by the cycle and the byte.
d) would require re-building lots of analytics systems, many of which still operate on the theory of request == impression
Or, the short summary is that there really isn't a need to pre-sage what people would view in order to speed serving and rendering pages. Now, places where something like this could be really useful would be in the "hey, if you liked X you probably liked Y" and then popping links and such to said content (or products) to folks.
Windows does the same thing with disk access - it "knows" that you are likely to start let's say Firefox at a certain time and preloads it.
SuperFetch also keeps track of what times of day those applications are used, which allows it to intelligently pre-load information that is expected to be used in the near future.
http://en.wikipedia.org/wiki/Windows_Vista_I/O_technologies#SuperFetch
Pointing out existing tech that does similar thing:
RSS readers load feeds in background, with assumption that user will want to read them sooner or later. There's no probability function that selects feeds for download though, user explicitly selects them
Browser start page and pinned tabs: these load as you start your browser, again user gets to select which websites are worth having around all the time
Your proposal boils down to predicting where user is most likely to click next given current website and current time of day. I can think of few other factors that play role here:
what other websites are open in tabs ("user opened song in youtube, preload lyrics and guitar chords!")
what other applications are running ("user is looking at invoice in e-mail reader, preload internet bank")
which person is using the computer--use webcam to recognize faces, know which sites each one frequents
I'm planning on developing my own plugin for showing the most popular posts, as well as counting how many times a post has been read.
But I need a good algorithm for figuring out the most popular blog post, and a way of counting the number of times a post has been viewed.
A problem I see when it comes to counting the number of times a post has been read, is to avoid counting if the same person opens the same post many times in a row, as well as avoiding web crawlers.
http://wordpress.org/extend/plugins/wordpress-popular-posts/
Comes in the form of a plugin. No muss, no fuss.
'Live' counters are easily implementable and a dime a dozen. If they become too cumbersome on high traffic blogs, the usual way is to parse webserver access logs on another server periodically and update the database. The period can vary from a few minutes to a day, depending on how much lag you deem acceptable.
There are two ways of going about this:
You could consider the individual page hits [through the Apache/IIS logs] and use that
Use Google Page rank to emphasize pages that are strongly linked to [popular posts would no longer be based on visits but on the amount of pages that link to it]
So I've been wondering this for a while, I'm currently building a website which is very image oriented. What do people think of preloading images? How do they do it? (Javascript versus display:none css?).
As users what do you think of it? Does the speed gained while using the website justify the extra time you have to spend waiting for it to load?
From a programmer's stand point, what is better practice?
If you really have to preload (e.g. for rollover images), definitely use CSS. JavaScript can be blocked, and you can't rely on it.
Rather than pre-loading multiple images, I recommend you use CSS Sprites:
http://css-tricks.com/css-sprites/
Which is a technique where you consolidate multiple images into a single image (and use background-position to select the correct portion) to reduce the number of HTTP requests made to the web server and reduce the overall page load time.
Several websites are hotlinking my images, I'm going to block them but if hotlinking helps traffic/page-views in any way at the cost of bandwidth, I won't.
Are there any advantages to hotlinking, if any?
Thanks
I don't think by solely having links from other sites to images in your site increases your site's page rank in google, so unless you have a site in which images is the primary content of your site, I would try to block those requests.
If it is, I would reconsider implementing hotlink protection or at least the way in which its implemented, as you may in fact start blocking google image search results in the process.
Also,it seems that hotlinking may actually be bad for you if you do not take into consideration other SEO techniques as explained below:
http://www.google.com/support/forum/p/Webmasters/thread?tid=5f222c9485075f8c&hl=en
Well, consider the following:
Is your server fast? - if it is, then just ignore. if it is NOT, you should block because the bandwidth you're sending over, your server has to process them - thus making it slow for real users of your website.
Track traffic from hotlinking - install Google Analytics or any other trackers to see if people actually come to your website because of those hotlinking - which i really doubt so.
Do they link you on those hotlinked images? if not, block.
Overall hotlinking isn't that good. In fact it may cause too much request to your images, not your webpages.
To include a watermark to an image when is hotlinked is a good option to increase your traffic.