For a website it is possible to include multiple iFrames for integration of external content. I know that there are other better ways to include such content, but I wonder if there is a browser-specific limit for the number of allowed iFrames on one web page?
Now I thought that there are two possible browser limitation:
the number of connection that are needed for including the iFrame resources and
the concrete maximum number of allowed tags.
For (1): I figured that e.g. Mozilla Firefox (v17) has config parameter for maximum number of connections to a server (network.http.max-persistent-connections-per-server) and an overall limited number of concurrent connections (network.http.max-connections). See about:config.
For (2) I cannot find any information. Except that there is a higher resource demand and other performance issues there is no fixed limitation for those tags on one page.
Do you have any other information?
Thanks
There does not seem to be a limit. However, like you've mentioned, your website's speed may decrease with the increase of i-frames.
Here's a great guide for I-Frames: i frames
Related
In order to find a good internship, I am engaged in answering these questions, There is one question which I am not clear what it says, I have never heard relevant information before, so I want to know What is progressive rendering?
Progressive rendering is the name given to techniques used to render content for display as quickly as possible.
It used to be much more prevalent in the days before broadband internet but it's still useful in modern development as mobile data connections are becoming increasingly popular (and unreliable!)
Examples of such techniques :
Lazy loading of images where (typically) some javascript will load an image when it comes into the browsers viewport instead of loading all images at page load.
Prioritizing visible content (or above the fold rendering) where you include only the minimum css/content/scripts necessary for the amount of page that would be rendered in the users browser first to display as quickly as possible, you can then use deferred javascript (domready/load) to load in other resources and content.
This pertains to the idea of sending data in chunks when doing Server side rendering rather than all at once. The advantage is reduced TTFB (Time to first Byte) i.e. the time period between the browser making the HTTP request and it receiving the first byte.
See below 'JSConf' talk for a detailed explanation:
https://www.youtube.com/watch?v=aRaQe9n1lPk
Progressive rendering is a concept to render content to the browser optimally by rendering the critical content first and the non-critical parts progressively as needed by the user. This article explains it very nicely.
I'm using SVGs extensively for obvious reasons. However I can't find any resources on the best way to implement SVG when performance is a priority. On one hand with inline SVG you have fewer requests, but on the other, using SVGs with the <img> tag allows the browser to cache them. We are talking about a web application where few users make many repeated visits. This makes the <img> approach sound more appealing.
Has anyone come across any benchmarks or has personal experience on the topic ?
The decision of picking inline versus tag would depend on the popularity of your site / app. There is a very interesting article on Yahoo! Perf guidelines page developer.yahoo.com/performance/rules.html which says on an average 60-80% of the users come to your site daily with an empty cache (yuiblog.com/blog/2007/01/04/performance-research-part-2) It totally depends on the popularity of the website - The more popular a site, the chances of a having a non empty cache is more.
I'm learning about Chrome and Native Client.
Basically i want to increase number of pages that are prerendered
by chrome (now its just one page).
I was thinking about creating a extension that would
allow to prerender more pages.
Is this a way to go or am i left with hard coding it into Chrome and build from scratch?
EDIT
I started a bounty for this question. I would really appreciate some input.
No, there is no way to go, you would need to hardcode it in Chrome and rebuild as you noted.
As you probably already know, Chrome explicitly states that they currently limit the number of pages that can be prerendered:
Chrome will only prerender at max one URL per instance of Chrome (not one per tab). This limit may change in the future in some cases.
There is nothing in their supported API's or their experimental API's that will give you access to modify this. There is not a toggle in chrome://settings/ or chrome://flags/ or anywhere else in Chrome currently that allows you to change this. You can however use the Page Visibility API to determine if a page is being prerendered.
In addition to the one resource on the page that you specify using the <link rel="prerender" href="http://example.org/index.html"> you could also consider prefetching resources.
The issue with prefetching is it will only load the top level resource of at the specified URL. So, if you tried to prefetch the other pages, like so:
<link rel="prefetch" href="http://example.org/index.html">
...then only the index.html resource would be prefetched, not all of the CSS and JavaScript links containeed in the document. One approach could be to write out link tags for all of the contained resources in the page but that could get messy and difficult to maintain.
Another approach would be to wait for the current page to finish loading, and then use JavaScript to create an iframe, that is hidden off the page, targeted at the URLs you want to prefetch all the assets for. The browser would then load all of the content of the URL and it would be in the user's cache when they go to visit the page.
There is also a Chrome extension that combines these two approaches by searching for link tags that define a prefetch and then creates the hidden iframe causing the assets to be downloaded and cached.
If the goal is to optimize around client performance for navigating your site there might be other alternatives like creating a web application that uses a Single Page Application (SPA) style of development to reduce the number of times JS and CSS are loaded and executed. If you are a fan of Google then you might check out their framework for building SPAs called AngularJs.
If it was a good idea to pre-render more pages, Chrome would probably already do it. Pre-rendering too many pages will drain website bandwidth and possibly end up slowing down the whole web, which is the opposite of what you're trying to achieve. So it's most likely intentional that you can only pre-render a single page and you shouldn't try to break that.
Not possible. Chrome manages pre-rendering based on many factors. If this was possible, it could also be easily abused by many sites. You could, depending on your page, keep all content on one page.
Building an AJAX based site and to keep the speed as high as possible I plan to jquery hide() pages after a user navigates away from them.
This allows me to show() them again instantly if they select them again.
The site is a date site so the vast majority of pages that will be hidden with be members profiles & other std pages like mail, home, search etc.
Question - A std page would be around the same as this stackoverflow page (with respects to HTML/content etc). If I was to have 100 pages like this hidden in the DOM would it cause problems for browsers? What if it was 1000 pages or 5000 pages. I'm interested to know if browsers would struggle or crash if running a site with slowly growing large DOM.
Note: if its a problem I can timestamp pages and remove excess pages when I have over 100 in the DOM etc.
thoughts?
This is an impossible question to answer because
Depends on the hardward the browser is running on that as a web site you have no control over
Depends on the browser technology - something else the web site has no control over
Depends on the available virtual memory - also the web site has no control over.
So in summary the web site has no control over the clients set up, so you have to make a reasonable assumption as to size of datastructures that it can hold in memory (be that real or virtual).
To reduce the number requests on the server I have embedded some images (PNG & SVG) as BASE64 directly into the css. (Its automated in the build process)
like this:
background: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAFWHRTb2Z0d2FyZQBBZG etc...);
Is this a good practice? Are there some reasons to avoid this? Are there some major browser that don't have data url support?
Bonus question:
Does it make sense to do this for the CSS & JS also?
Is this a good practice? Are there some reasons to avoid this?
It's a good practice usually only for very small CSS images that are going to be used together (like CSS sprites) when IE compatibility doesn't matter, and saving the request is more important than cacheability.
It has a number of notable downsides:
Doesn't work at all in IE6 and 7.
Works for resources only up to 32k in size in IE8. This is the limit that applies after base64 encoding. In other words, no longer than 32768 characters.
It saves a request, but bloats the HTML page instead! And makes images uncacheable. They get loaded every time the containing page or style sheet get loaded.
Base64 encoding bloats image sizes by 33%.
If served in a gzipped resource, data: images are almost certainly going to be a terrible strain on the server's resources! Images are traditionally very CPU intensive to compress, with very little reduction in size.
Common answers here seems to suggest this is not needed, for a set of legit reasons.
However, all of these seems to neglect modern apps behavior and build process.
It's not impossible (and actually quite easy) to design a simple process that will walk through a folder images and will generate a single CSS with all the images of this folder.
This css will be fully cached and will dramatically reduce round trips to the server, which is as correctly suggest by #MemeDeveloper one of the biggest performance hits.
Sure, It's hack. no doubt. same as sprites are a hack. In perfect world this will not be needed, until then, it's a possible practice if what you need to fix is:
Page with multiple images that are not easily "spritable".
Round trip to servers are an actual bottleneck (think mobile).
speed (to the milliseconds level) is really that important for your use case.
You don't care (as you should, if you want the web to go forward) about IE5 and IE6.
my view.
It's not a good practice. Some browsers are not supporting data URIs (e.g. IE 6 and 7) or support is limited (e.g. 32KB for IE8).
See also this Wikipedia article for complete details on the Data URI disadvantages:
Data URI scheme
Disadvantages
Data URIs are not separately cached from their containing documents (e.g. CSS or HTML files) so data is downloaded every time the containing documents are redownloaded.
Content must be re-encoded and re-embedded every time a change is made.
Internet Explorer through version 7 (approximately 15% of the market as of January 2011), lacks support.
Internet Explorer 8 limits data URIs to a maximum length of 32 KB.
Data is included as a simple stream, and many processing environments (such as web browsers) may not support using containers (such as multipart/alternative or message/rfc822) to provide greater complexity such as metadata, data compression, or content negotiation.
Base64-encoded data URIs are 1/3 larger in size than their binary equivalent. (However, this overhead is reduced to 2-3% if the HTTP server compresses the response using gzip)
Data URIs make it more difficult for security software to filter content.
I was using data-uri's for about a month, and Ive just stopped using them because they made my stylesheets absolutely enormous.
Data-uri's do work in IE6/7 (you just need to serve an mhtml file to those browsers).
The one benefit I got from using data-uri's was that my background images rendered as soon as the stylesheet was downloaded, as opposed to the gradual loading we see otherwise
It's nice that we have this technique available, but I won't be using it too much in the future. I do recommend trying it out though, just so you know for yourself
I'd more inclined to use CSS Sprites to combine the images and save on requests. I've never tried the base64 technique but it apparently doesn't work in IE6 and IE7. Also means that if any images changes then you have to redeliver the whole lost, unless you have multiple CSS files, of course.
I have no idea about general best practices but I for one would not like to see that kind of thing if I could help it. :)
Web browsers and servers have a whole load of caching stuff built in so I would have thought your best bet was to just get your server to tell the client to cache image files. Unless you are having loads of really small images on a page then I wouldn't have thought the overhead of multiple requests was that big a deal. Browsers generally will use the same connection to request lots of files so there are no new network connections being established so unless the volume of traffic through HTTP headers is significant compared to the size of the image files I wouldn't worry about multiple requests too much.
Are there reasons why you think there are too many requests going to the server at the moment?
I would suggest it for tiny images that are used very often, for example common icons of a web application.
Tiny, because the Base64 encoding increases the size
Often used, because this justifies the longer initial load time
Of course support problems with older browsers have to be kept in mind. Also it might be a good idea to use the capability of a framework to automatically inline the images a data urls such as GWT's ClientBundle or at least use CSS classes instead of adding it to the element's style directly.
More information are gathered here: http://davidbcalhoun.com/2011/when-to-base64-encode-images-and-when-not-to/