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.
Related
First, I've seen the duplicates
What is #shadow-root, and why does it put display none on my font awesome classes?
and
HTML / CSS - DIV Element hidden when it shouldn't be?
however both of these suggest the issue is with adblock and I have totally disabled adblock.
I am more concerned with where the #shadow-root is coming from, since I certainly did not put it there.
I have read that there is an option in chrome to disable it (and interestingly enough I have it disabled...), but this means that anyone using my website will need to do the same, and I'd rather just do away with it entirely as it provides zero usefulness in my application.
I have also googled and read many of articles about the shadow dom and none of them give any insight on why it would appear seemingly for no reason.
From what I have seen in inspector/view page source, the entire contents of my app are being rendered into this shadow dom and thereby not receiving any of my styles.
I am using rails, react, redux, react-redux, react-router
Chrome developer tool screen
Page Source screen
Notice that the source has nothing in the div that react should be rendering to.
Additional info:
displays unstyled page on chrome in normal and incognito
does not work at all in safari
A lot of chrome plugins automatically create this shadow root in your inspector. For example, ever since I downloaded Vimium, I've had a shadowroot div at the bottom of any page I've opened in chrome. It's nothing to worry about.
I was having the same issue and found that it was Adblock Plus that was adding #shadow-root. Thanks to the resources above I was able to assertain what the issue
For me it was also an Adblocker (uBlock) and it was actually hiding part of the webpage I was making which showed imported tweets. Turning the adblocker off for my site fixed it.
I have a new website with a set of favicon images auto generated from a source file using Real Favicon Generator, and there are:
9 Apple favicons
1 Android favicon
3 named favicons
1 Safari pinned SVG
1 json manifest
1 set of Microsoft tile image/colour
Obviously most of these can be placed for their respective vendors - Apple, Microsoft tiles, etc.
I have an issue in that running the website on Firefox, I want the favicon it uses to change but I do not know which one it actually uses?
I have read this question but the stated answer on here is incorrect and
Firefox and Safari will use the favicon that comes last.
is no longer true.
Obviously it's a time consuming repetition to go through ~15 images to find the one that gets changed on one browser, and I actually found that Firefox 42 selects the 96x96 dimension favicon, rather than the last one presented.
Question:
Is there a way [aside from trial and error] to load a page and then find a declaration in the browser defining which image from the HTML head is used as the page favicon in that browser?
Additional Information:
There is an incomplete reference list here. However, this misses out various versions and various OS, and I can only assume these details where found from trial and error.
While this is useful, the various links and solutions on that question give a single URL result for an automated process, such as
http://www.google.com/s2/favicons?domain=www.domain.com
Which works fine in returning a valid favicon but it does not return the favicon that my browser uses when I tested it.
Other links from that question are similar, most only returned a 16x16 favicon and many clearly did not return the image used. Some probably didn't return the image used... it is hard to differentiate 16x16px sometimes!
You can use the Compatibility test of RealFaviconGenerator. The test will ask you which icon you see. But there is a twist: the test is not really for the end-user, so you will have to right-click the image corresponding to the icon you see, inspect it, and look at the alt attribute of the img tag. But that will prevent you from playing with 20+ images to make them different. Much easier!
Full disclosure: I'm the author of RealFaviconGenerator.
Note: I would be interested in your investigations to fix the answer you mention (I'm his author).
Using the Inspect Element, or just Inspect tool, available in Firefox and Chromium. The Network tab shows all http operations related to reload. Filtering by 'favicon' most likely peeks the correct operation, when the page is reloaded.
The fact that the browser downloads an image is a strong hint of what gets displayed. Yet, doubts can persist, e.g. which part of an .ICO. Unfortunately, the tab is a computed element not visible in the (computed) page source.
On Firefox, the iconuri is visible in the json code of exported bookmarks.
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.
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.
I am writing a complex tab based web application where each tab is unrelated to each other in the sense that there is no interaction. So for ease of development i want I want each tab to be a separate html page viewable on its own and at later stage I can assemble them via tabs or may be menus or trees
so question or questions are:
I am planning to use iframes, does all major browser support them?
Are iframes going to be deprecated, so what are alternatives e.g. is object tag supported by all major browsers?
May be i can use some better strategy instead of iframe/object?
But what I love about iframes is that it can be totally modular, so each page doesn't know about other.
Note: i selected the answer which explain well but still i am not sure why not iframes
question iframes vs ajax may answer that.
Yes, all major desktop browsers support iframes. So do many mobile browsers, including IEMobile, Opera Mobile, and Safari on the iPhone. The only major browser I know of that doesn't support iframes is the BlackBerry Browser.
The object tag is supported by most browsers, but the implementation is extremely inconsistent across the various browsers.
What's wrong with just having a flat page with an ordinary navigation menu? If you are only displaying one page at a time, and the only interface element being placed outside of the iframe is a tab menu, then why not just integrate the tabs into the page layout and do away with the frames?
Frames of any sort tend to break the familiar browser behaviors that people are used--like the forward and back navigation buttons. And they completely disable the use of bookmarks. When building a website, you should try not to restrict or dictate to visitors how they're allowed to browse your site. If the user wants to open a link a new tab, they should not be left without a navigation menu. If they make their browser window a particular size, the page content should fill that area, not a predetermined area specified by the dimensions of the iframe.
Frames are inherently user-unfriendly, which, unsurprisingly, makes them search-engine-unfriendly; which is why so few professional websites use frames/iframes. Cheap broadband is widespread enough these days that reloading a few extra kilobytes of navigational data makes no difference to the overall user experience.
If I were you, I would use jQuery UI Tabs instead of my own solution.
it looks like your website is not static, so i don't see why you're doing it with bare HTML.
I'd use ASP.NET and CustomUserControl as each of your tabs, that they all the tab would be truly independent and you can reuse them anywhere in your application
For the separate pages in each tab, you can as well use server includes.
To answer your first 2 questions:
iframe is supported across all the latest web browsers however i am not sure about mobile browsers. Opera mobile yes, dont now about iPhone.
the next major iteration of html is being led by WHATWG and the iFrame will be supported. It is also supported in xhtml
As far as different approaches, that very much depends on what you are going to be doing with the tabs. if each tab is going to have a lot of information on it or take a while to load then separate iFrames is probably best. Also, if you are going to reuse the code as independent pages else where then iFrames are also a good option.