Does having (approx 100) HTML validation errors affect my page loading speeds? Currently the errors on my pages don't break the page in ANY browser, but I'd spend time and clear those anyhow if it would improve my page loading speed?
If not on desktops, how about mobile devices like iPhone or Android? (For example, N1 and Droid load pages much slower than iPhone although they both use Webkit engine.)
Edit: My focus here is speed optimization not cross-browser compatibility (which is already achieved). Google and other biggies seem to use invalid HTML for speed or compatibility of both?
Edit #2: I'm not in quirks mode, i.e. I use XHTML Strict Doctype and my source looks great and its mostly valid, but 100% valid HTML usually requires design (or some other kind of) sacrifice.
Thanks
It doesn't affect -loading- speed. Bad data is transferred over the wires just as fast as good data.
It does affect rendering speed though (...in some cases... ...positively! Yeah, MSIE tends to be abysmally slow in standards mode) In most cases though, render speed will be somewhat slower due to Quirks mode which is less efficient, more paranoid and generally instead of just executing your data like a well-written program, it tries its best to fish out some meaningful content from what is essentially a tag soup.
Some validation errors like missing ALT or no / at the end of single-element tags won't affect render at all, but some, like missing a closing tag or using antiquated obsolete parameters may impact performance seriously.
It might affect loading speed, or it might not. It depends on the kind of errors you're getting.
I'd say that in most cases it's likely that it will be slower because the browser will have to handle these errors. For instance if you forgot to close a div tag, some browsers will close it for you. This takes processing time and increase the loading time.
I don't think the time delta between no error and 100 errors would be minimal. But if you have that many errors, you should consider fixing your code :)
Probably yes, and here's why.
If your code is valid to the W3C doctype you are using then the browser doesn't have to put more effort in to try and fix your code. This is called quirks mode, and it would be logical that if your code were to validate, the browser wouldn't have to try and piece the website back together.
Remembering it's always beneficial to make your code validate, if only to ensure a consistent design across the popular browsers. Finally you'll probably find that you fix the first few errors and your list of 100 errors will drastically decrease.
In theory, yes it will decrease page load times because the browser has to do less to handle errors and so on.
However it does depend on the nature of the validation errors. If you're improperly nesting tags (which actually may be valid in HTML4) then the browser would have to do a little more work working out where elements start and end. And this is the kind of thing that can cause cross-browser problems.
If you're simply using unofficial attributes (say, the target attribute on links) then support for that is either built into the browser or not. If the browser understands it, it will do something with it, otherwise it will ignore the attribute.
One thing that will ramp up your validation errors is using <br> under XHTML or <br /> under HTML. Neither should increase loading times (although <br /> takes a fraction longer to download).
Related
One of the pages served by my application is very long (about 8Mb of source HTML, mostly tables). I know this itself is a sign of wrong architecture but there are circumstances that don't allow to change that quickly :(
In almost every browser apart from IE the page is still fine - of course it's slower than an average one but it looks like the time it takes to display is mostly defined by code download speed, and I have no problems with that.
It is very different in IE (7, 8 and 9) though - the page is extremely slow for about 10-15 seconds after downloading with frozen screen effect, then experiences noticeable scrolling lags and "script is running slowly" messages while there is no javascript running on the page. IE9 takes about 800Mb of RAM as well when displaying that page.
When I serve plain text content of that size it is much better, but formatted HTML tables seem to be causing problems. It looks like long DOM is a blocker for IE of any version.
I don't know what answer am I hoping for - obviously a proper solution would be to change the page architecture by breaking it down on server side and serving piece by piece via ajax, but still - is there any kind of say magic pragma or js for IE to stop doing what it does with DOM tree speeding it up?
It would be the best solution to chuck page downloading by client. But you have to be advised that the "table" tag is the most slowest rendering tag in IE (as my experience says). So in the first step I think you should do some modifications on the HTML document. Here are some suggestions:
Clear inline style sheets and use css classes as far as you can. It will help your HTML document to be smaller in size.
use some other expressions instead of using TABLE. using DIV s would be my first recommendation. Simplify your document and the parser can read the codes as easy as you can. So make them easy to read. It causes to write less and again, it helps the document to be much smaller.
remove all the spaces, tabs, new line characters and many other extra contents from the HTML document.
Qualify the content you are presenting to be more useful for the client. As we all now, we can see two lines at most. So all the data on one page is not a good idea, actually useless. Because while user is downloading the document, some data might be updated on the server and the data your user has is not valid anymore.
After all, always remember that every character stores 8 bytes in the memory (no matter it's virtual or not) including all the parsing variables and memory uses by xml parsers and some how hard codes to load the HTML string and make a DOM out of it. The speed to read the document and parsing it is so important as much as the size would be.
Hope it helps you..
Cheers
I have created lots of buttons for a large number of pages (usually 5-10 in a row at the bottom of each page inside a table cell) using input type="button" name="..." value="..." onclick="some javascript event handler" etc, basically to link to other pages of the same group. All these pages are ultimately linked from an iframe tag on a single page. The buttons are working fine offline on my PC at least. But, now I've suddenly realized that I haven't used any 'form' tag for these buttons.
So my question is, is this 'form' tag really necessary? Will there by any problem after I upload? I would prefer not to add the form tag now to so many pages if it's not really necessary, because that's going to be a real drag. But, I don't want to suffer afterwards either.
No it is not necessary as long as you are not doing any Get/Post and grouping form elements together. They should work completely fine without a form tag.
There are two issues to be concerened with:
Is it valid HTML?
Turns out that it is valid HTML (see Is <input> well formed without a <form>?), so you are on the safe side here.
Will all common browsers accept it?
After googling around I haven't seen any information on problems wih this use of Input tags. That suggests that all common browsers accept this valid HTML (as they should). When developing any website that is accessible to the general public I would always do a manual cross-browser check to discover any abnormalities certain browsers may habe with my site.
Problem is that you most likely won't be able to tell from looking at your server logs whether certain browsers have a problem with your HTML. It may just not work on IE 6 and you would never be able to find unless a disgruntled customer calls up and informs you.
If this is a generally accessible website get some stats on the most commonly used browsers, decide which ones you want to support, and verify that the website is behaving properly on thiee browsers. This is a pain in the ass, but there is no way I know of to get around that. Browsers may not react to valid HTML properly.
As a rule of thumb, Firefox, Chrome, and Safari unsually behave well, and because of auto-updates most people will have a very recent version installed. If the latest version of the browser works I wouldn't be too concerned that users with some older version will have trouble.
The real test is always Internet Explorer. While version 8 and 9 are pretty standards-compliant, IE 7 certainly needs checking. IE 6 is the worst offender for unusual behavior. It was introduced in 2002, but today still 6% of the population use it! Most of this comes from cracked copies of Windows XP in China, but it is also used quite a lot in corporate networks, where OS and browsers are centrally deployed, and administrators have not managed to progress since early 2000.
In conclusion: Your code is unusual but ok, test it manually on the browsers you expect.
So I've been looking around and am a bit lost on this topic. People have said that there's alternatives to iframes, but I don't see any that fit the bill for what I'm trying to do. I essentially created a small game that uses videos and plays particular ones based on corret button input from the keyboard.
All of that is in a seperate html file, and I want to display it on a different html file to be in an iframe like state on a different webpage. But I can't seem to figure out the best approach to this.
The iframe is just too slow, the game itself runs fine, but when I put it in an iframe it lags like crazy half the time, or stuff doesn't render because it's going so slowly.
Any ideas of where to start?
There is one alternative to <iframe> and that's the <object> tag. It can display content from different sources as well. The pro is it being conform to the xhtml-standards and encouraged to use but there's not such a broad / usable support in older browsers (you have to mess with it to get it right in IE). It's used as followed:
<object data="page.html" width="400" height="300" type="text/html">
Alternative Content
</object>
That being the direct answer to you question I don't think it will give you any speed advantage. Already for the reason that the <iframe>-element is much more used and so more tested and cared for than <object>.
I for myself never saw an <iframe> being the cause for a slowdown, but that still might be possible. If that is an option, you should definitely try what ocanal said before in the comments: Let your script work on an wrapper container-div instead of the body-element and so embed it directly on the mainpage.
For the browser it shouldn't be much more than some overhead from handling a second document, so you could guess that it's just that little more to make your pc run slow. So it might be a good idea to optimize the code in general:
Look if you can find the bottleneck causing the slowdown. Possible causes could be
altering the DOM a lot - which is always slow
acting a lot on things not even visible on screen
getting attributes from objects. For every additional period you use it means more work for your cpu:
// instead of using this over and over again
house.roof.window.handle.open();
house.roof.window.handle.close();
// save it to a var and use that instead
var handle = house.roof.window.handle;
handle.open();
handle.close();
Updating the game in short equal intervals by window.setTimeout() may also be too fast and waste cpu power unnecessarily (or too slow and won't look fine then, but never really right) - so you can use the new window.requestAnimationFrame. The vendor-prefixed variants are implemented in the current versions of all important browsers and it's easy to provide a fallback to the old method.
As a last thought: Maybe it even helps in some meta-magical way to include the script file itself on the mainpage and not in the embeded document
When I print content using javascript, the browser automatically adds header and footer (url/date/pagenr). Currently there seems to be no way to suppress this from the webapp-side.
Css3 might eventually be a solution for it (e.g. with #page, #top-left styles), but currently doesnt seem to work here (winvista chrome 17.0.942.0 / firefox 9.0). When is it supposed to come to the browsers?
Another solution might arise with chrome-browser: With above version the printdlg is not the modal system-printdlg but rendered within the website (there is also a checkbox to disable header+footer). Now that chrome has remade the printdlg, chrome might also provide a api to control printing using javascript?
Are there other solutions on the horizont? It cant be the final state, that to print from the browser with full control pdf- or other plugins are needed.
Do this:
#page {
margin: 0;
}
Done!
Currently, Javascript is very limited to accessing resources "outside the browser" like hardware and the file system for security reasons. Hinting from this trend, I doubt programmatically controlling how prints come out will be in Javascript's future. I say this because having those headers and footers (despite how ugly they are) should still ultimately be the user's decision.
Even with CSS3, you are still talking about reaching content outside of the HTML document itself. Those headers and footers are set by internal browser functions. However, Chrome does create an easy UI to get rid of them when printing.
However, especially with Chrome, there is a lot of power in their extensions, especially if you use NDAPI plugins (though this just poses another security risk). This route is very technical, but could probably be "another solution."
I need to know what can be the main reasons (apart from the basics like grouping CSS selectors, reducing image size, using image sprite etc.) which makes a website slow on Internet Explorer, because my website works fine on the others like FF, chrome etc.
Is it the huge use of Javascript framework (ie. jQuery, extjs, prototype)?
Is it because of the use of plugins based on JS framework?
Should I use core javascript and remove the use of any js framework?
Should I try to avoid using jQuery(document).ready()? in case of jQuery framework?
Above some of the questions which I know and please answer the questions which I couldn't ask because of lesser knowledge about these.
I need to make my website perform well on IE (6,7,8) also please suggest.
Thanks
It has nothing to do with jQuery. The plugins however are hit or miss, and may not be well tested in IE. I'd use at your own risk.
DOM manipulation is very slow in IE. using appendChild (or insertRow) to add multiple nodes (say, 100+ for a long list) is much slower than building a string and doing one innerHTML.
You also want to be careful how you access nodes. Devs tend to rely upon jQuery too much and search for nodes via their class names, like:
$(".evenRows").hover(doSomething);
IE doesn't have a native way of getting a node by class name, so JQ is looping through the entire document and every single element and checking its class name... which needs to be checked via RegExp because it may look like:
class="evenRows yellow foo bar"
Finally, in spite of its improvements, IE8 is still using an old rendering engine - the same as IE6. Don't go crazy with the animations, and don't expect miracles.
As MSIE has a default-limit of 2 simultaneous connections you should minimize the number of requests that are required for building the page(use css-sprites, merge js-and css-files into a single file)
While you need to speed things up in IE, you can still use Firebug to look for places, that consume resources.
Install Yslow and see what it tells you
Run the site under profiler (Yslow or Firebug have one) and look for a bottleneck
It is very difficult to answer general questions like this, but jQuery is unlikely to be the one slowing everything down, just remember to
Use IDs as selectors wherever possible — they are the fastest, i.e. $('#myid')
Avoid using .class selectors without tagname, i.e. $('div.myclass') can be ten times faster than $('.myclass').
and so on
More tips for using jQuery to achieve better performance.
Earlier versions of IE will, in general, run JavaScript slower than later versions of IE, because there have been advances in JavaScript compilation speed since then.