I've read that putting CSS stylesheets outside of the document HEAD prohibits progressive rendering to avoid having to redraw elements of the page if their styles change, but why is this? Does it just check to see if any CSS stylesheets are outside the HEAD and delay the rendering? Why can't it just decide to load all the stylesheets first, regardless of the location within the HTML?
Well, I guess that browsers do not wait until they get the entire file (and linked files (.js, .css...)) from the server, for then to render everything in the background and then display it to the user all at once. If you have Firefox, Press F12 and check the last tab... there you can see how the browser loads things.
Unlike downloading a large file, say 200 MiB, browsers usually start displaying whatever they get from the server, as soon as they get it, while still downloading the html/php/whatever file.
You may not notice much of a difference nowadays, with fast computers and fast Internet connections, but I'm pretty sure that, if you throttle your Internet connection, you can simulate this behaviour (page slowly loading).
Having this in mind, it kind of makes sense that the browser would have to "re-render" everything, if the stylesheets were at the end of the page, doesn't it?
When a browser looks at HTML, it goes from top-to-bottom. It can't know whether there are stylesheets at the bottom before loading the HTML. The reason you load your stylesheets in the <HEAD> is so, as you said, it can progressively render the DOM objects with the styles you specified. When it sees the <link rel=stylesheet> it makes a request to get the CSS file. In terms of performance some pages would load really slowly if the browser had to scan through the whole html file for all the stylesheets, determine what styles needed to be applied, and THEN loaded the HTML. From designing-a-browser perspective, I think this only seemed logical.
In general, the idea is HTML provides content and CSS provides styling so they are to be kept separate. I guess browsers were designed so if they did not find a stylesheet, they'd just simply load the HTML anyways because in all honesty CSS isn't really "necessary". It's just eye candy which is an aesthetic that is important to us humans.
Having stylesheets at the top or in the <HEAD> gives the browser a "heads up" (haha!) knowledge of what styles you want to put so it looks nice and then once it reaches the bottom, it will see the stylesheet and then load it.
There is a really good blog post about how browsers work that might be useful.
Well, adding a <style> tag outside of the <head> isn't actually legal in HTML5.
Edited to add: unless you're using scoped styles, which only Firefox supports.
Related
From this gist: https://gist.github.com/awesome/9947977, there are many options for adding the favicon graphic. Will many references to the tag slow down the page? Or is this just a bad idea?
Yes, but not that much.
Chrome and Firefox tend to load all PNG icons the first time they encounter the declaration, thus the "Yes". Subsequent browsing does not generate additional, unnecessary requests, thus the "not that much".
Also, I don't totally agree with the code you link to. In particular, all iOS PNG icons (such as favicon-57x57.png) are duplicated and won't be used (eclipsed by apple-touch-icon-57x57-precomposed.png in this example). But Chrome and FF will load them for no reason.
I rather advice you to use this favicon generator. The generated pictures and code support all major platforms and minimize overhead. Well, this is a matter of balance. Full disclosure: I'm the author of this site.
A hyperlink will not make the page load slower. if you want to display all of the icons on the page it will hardly effect the performance because of the low resolution.
Setup
The topic SVG vs. Icon Font is well covered in the web. But even after long searches, I did not find advice concerning my special situation.
I have a site served by a CMS. On one page, I have elements containing several icons. These elements are repeated over the page. So each icon shows up a lot of times on the page. Now I have a hard time to figure out how to realize those icons best.
Inline SVG
In general, I totally see the benefits of using Inline SVG. It's most simple and straightforward, and you can do the most with it. On other, non-repeated places on my website I already use it and I love it.
But: Repeating the exact same svg markup over and over again seems like blowing up the document unnecessarily.
Referenced SVG
I could use the SVG via the <img>, <object> or <embed> tag. Doing this, the SVG would be referenced and therefore only data that is unique is transfered via the web.
But: Besides things like using the side CSS for the SVG ist not possible, I have several extra HTTP requests.
Icon Font
I could use an Icon Font. Only one HTTP request and content is referenced.
But: Bad markup, bigger file than the SVGs.
SVG Sprites
I could use a SVG sprite. Only one HTTP request and reference.
But: It's quite comlicated and feels as much as a hack as using the Icon Font does. Plus I have the impression that background-SVG ist not so easy to use.
Conlusion
To come up with the best solution, I think the following questions are relevant:
Is repeating the SVG markup so bad compared to the other solutions? It's what I do with the HTML markup anyway. A SVG-Icon are about 30 lines / 1.6kB of code
Networkwise: Are several small HTTP requests (referenced SVG) or one big (bigger than the small ones combined, icon font) request faster?
Which advantages do I really have using SVG sprites compared to using an Icon Font? I guess it's at least as much CSS-fiddeling as an Icon Font.
Please note: I use AJAX, so only content is transferred. The icon font would load with the first request of my website (and then be cached), the referenced SVGs would load with the first call of this special page and then be cached. Inline SVG would be transferred on each call of this page, as content is not cached in the browser.
My feeling is an icon font or inline SVG would be best. But I am thankful for every contribution and aspect of this topic.
Why would you repeat exactly the same markup when you could use <use> elements to reference and display multiple instances of that markup? Here's a link to an example.
As for <img> <object> etc browsers can cache these if you set Expires and Cache-Control appropriately in your http responses.
Using Icon fonts would seem like you're shoehorning into something inappropriate for your use case.
In all given your requirements, <use> elements would seem most appropriate.
There might not be a best fit answer to this situation beyond weighting out the pros and cons of each.
I personally tend to go on the all inline approach, especially if the combined file footprint is smaller than a font or one huge svg.
using <img> is great if the browser can cache them (especially if you have lots of repeat visitors)...but you end up giving up on the styling and interaction options. you also need to add a bit extra mark up for some older browsers to serve a png file in the case that svg is not supported.
If you are interested, here is a hack I use for serving pngs vs. svg basically it fixes IE:
<!--[if lte IE 8]><img src="img/youricon.png" /><![endif]-->
<!--[if gt IE 8]><img src="img/youricon.svg" /><![endif]-->
<!--[if !IE]> --><img src="img/youricon.svg" /><!-- <![endif]-->
When page of my application is loaded font in some html tags is default one and when you mouse over it, proper font immediately shows. I made a list of things that probably matters:
Position of element doesn't matter, it occurs on absolute and static.
Font of my choice if assigned to body tag so there is no way some stylesheets don't get loaded.
I load fonts via #import from fast.fonts.net. This line of code is almost on the top of my stylesheets, above is only reset.
I load my assets from s3, minified in one file.
It never occurs locally and the only browser that this bug was seen is Chrome.
It is rare bug, maybe 1% of all page refresh, so reproducing when you want to see it is difficult
Once I have seen this issue in bugsnag.com
App is heavy on front-end side
Do you have any ideas how I could fix it?
I discovered that injecting fonts via JS script tag and not css #import works best. After that client stopped reporting me this issue.
It's simple change and the reason why it works must be connected with some Chrome bug.
A friend of mine threw a website I made through the tool at http://analyze.websiteoptimization.com/ . When he came back to me, he insisted that my browser was preloading tons of unrelated images on only the homepage of the site.
I came back to him, insisting that YSlow (and other 'network' tabs in browsers) prove that only specifically-displayed images and content gets loaded on the homepage-- nothing else. I insisted that the statistics from that site are only for a complete visiting of the site, and downloading all the required images.
However, he's not convinced, believing that some browsers (i.e. IE) will pre-load that unrelated content regardless. For that reason, he uses a global CSS stylesheet, and then applies changes to individual pages by loading a separate stylesheet.
I thought it was best practice to minimize requests to the server, not to add more, which is why we have CSS sprites. I also thought browsers never load images unless they're needed to display the page.
I don't believe I can accept an answer without healthy discussion.
Am I correct in that the browser's not loading EVERYTHING on every page?
Is the above tool incorrect?
Is the lesson my friend's learning from the tool's results incorrect?
Thanks.
The browser will generally only load what's actually shown in the page. (There may however be exceptions in some exotic browsers, like Opera Mini.)
The WebSiteOptimization tool will only look at what images are referenced in the HTML and in the CSS, not which images are actally used in the page.
When I analyse my own webpage, which has eight different background images that are shown one at a time by random pick, the tool says that all eight images are loaded, just because they are in the CSS. Checking the network traffic in Firebug and IE developer tools shows that they aren't.
According to me
Browsers do load cached images at time but newer updates can check if the image has changed. Also there are permissions which coders can set to allow browser caching or not.
when using yslow or Google page speed which is a better tool try and use control+f5 to refresh your page so the site is forced reloaded without any offline files.
You can also set Brower permissions based on your preferences.
I also want to add a little about your last line a browser will load all images linked in the code even if there css property is hidden.
It always loads thing in the img tags first and then all images in the css code.
It will also process the image request in sequential order ie first come first server
I hope this help.
<style type="text/css">
.hidden-image-container {
display: none;
}
</style>
<div class="hidden-image-container">
<img src="lulcats.png" />
</div>
I'm mainly interested in what mobile browsers make the optimization of not downloading an image that's in a hidden container.
This would allow me to signficantly reduce initial download time.
Related reference question about loading images across devices
Someone has tested this before:
http://www.w3.org/2009/03/image-display-none/test.php
Edit:
Looks like the list does not contain many mobile browsers (yet).
I would never call it an optimization for a browser to not download a hidden image. That might have dozens of good reasons and should (and will) still get downloaded by a browser. I don't have some table of numbers or browsers but I'm pretty much sure all mobile browsers will also download such an image as soon as the interpreter spots it.
I'm afraid there is no silver bullet to conditionally load <img> tags with just html/css. Right now you'll need at least a little piece of ecmascript, but as always, I'm very sure the stackoverflow community will correct me if I'm wrong here.
The <img> node has no property like .preventLoad (which would indeed be quite useful). Maybe it's time for a whatwg proposal, I'll join and support it :-)