I have a big performance issue in IE6 even with javascript turned-off.
It's strange because sometimes when the page is loaded, the header is floated next to the footer, or slideshow is over the the content.
I wonder if someone had same or similiar issues in IE6 and if i minify a generated source code into a one-line, will it help somehow to gain loadspeed in that browser ?
-Want to mention that it should be compatible with ie6 so please, do not post a messages like - use modern browsers.
The problem was in MS png fixer inside css. Even if i turned off a javascript, it still works, so when i removed css lines with ms filter for png transparency, it starts working like it should.
Thanks for any submits.
I doubt that removing newlines would increase the speed in any noticeable fashion.
That is, the performance issues are likely not caused by line count but rather the size/number/type/cost of the elements/operations after the parsing.
The actual lexer that handles the newlines should see them no differently in the stream than any other character. Depending on exactly what context "source" means newlines have some effect semantically at the parser:
CSS: none (ignoring embedded newlines)
HTML: possible new text-nodes or different content
JavaScript: automatic semicolon insertion (or embedded newlines)
However, there is no reason not to try a minified version quickly to see if it makes a difference and, more importantly, to satisfy your curiosity ;-) I would definitely heed the other suggestions as well, such as checking the page (everything) for validity.
Happy coding.
You haven't specified what your page consists of, but my guess would be you're outputting the mother of all HTML tables?
The reason I guess that is because IE6 is known to be extremely slow when rendering large tables, particularly where the column widths are variable. (later IEs are also slow with this, but not as bad as IE6)
The reason is that the browser attempts to render the entire table before displaying anything, and performs a lot of calculations to work out how to render it.
The answers on this question may also help you: Are large html tables slow?
Related
I've came across this issue where the browser (Chrome) is sometimes rendering characters as completely different ones, however in inspect element they're written how they should be. You'll see in the images that on the right inspect element shows what it's supposed to be, and on the left shows what it's rendering as.
I can't find a reliable way of replicating this problem, there is no correlation of events that I can see to cause this to happen
I have noticed that the replaced words contain the correct amount of characters for the word it's supposed to be.
This can happen to any element on the site as far as I've seen. It doesn't matter if it's getting the content from the database or if it's hard coded.
Refreshing the page usually causes text to render as normal. It doesn't happen all the time.
I've just recently joined stackoverflow so I need 10 reputation to post pictures apparently.
http://imgur.com/G3yvRg2
http://imgur.com/Jqk2jwB
Does this happen only on one particular website, or some specific sites? I was thinking that maybe they used JS to like dynamically change the HTML (for whatever reason they would want).
Another cause might be some plugin that you installed in Chrome and that is working baddly / causing issues.
Also please post the encoding that the page(s) use (like UTF, ISO), that might help.
Except that, to really narrow it down to a Chrome problem, check in other browsers for the same issues.
It appears that the issue seems to be caused by 'text-rendering: optimizelegibility;'.
Mostly when used in conjunction with text-transform:uppercase;/text-transform:capitalize; , or letter-spacing.
It may also be an issue with opimizelegibility and Proxima Nova since I've never encountered this anywhere else.
After looking up the textrendering:opimizelegibilty; property more, I've released that it's an awful decision to use it more than sparingly due to performance issues (And this strange one..). From now on I'll only be using it in cases where the kerning looks particularly poor.
When users visit my website, they don't care about how perfect or how much standard the page is coded. They only care about whether it works or not.
There are tags that are deprecated but have consistent behavior throughout all major, minor, and very minor browsers. They work now and will work in the future. (I'm not talking about optional tags like <marquee> and <blink> which will probably be removed in the future since their non-existence doesn't break pages.) The tags I'm talking about are for example:
<center> (used by google.com homepage, yes and it's May 2014)
<body bgcolor=, alink=, vlink=, link= (all used by google.com)
<font size= (also used by google.com)
If my HTML generator produces tags like <body bgcolor=black>, it is guaranteed to work for near 100% of users.
If it instead produce CSS like background:black;, it will be supported by lesser users compared to <body bgcolor=black>. (Start with https://superuser.com/q/732669/78897 and https://superuser.com/q/447269/78897, though I'm sure they are not the only ones in the whole world.)
Bear with me, this is a real question based on a true problem. Exactly what are the real disadvantages of having these tags as output?
Potential disadvantages include the following:
1) Your customer might actually care about how standard the code is. Maybe not now, but in the future. Maybe for questionable reasons, but still.
2) Deprecated constructs do not always work consistently. For example, align=center attribute set on a table may have different effects depending on browser mode. This is a relatively weak argument, though, since the browser practices have been described rather well in HTML5 CR and you can manage the potential problems. (Besides, even CSS settings may work inconsistently.)
3) There is no guarantee that deprecated features will be supported by all future browsers. On the other hand, the same applies to standard features. In practice, very few features that have been defined in HTML specifications have actually been removed from browsers. (Regarding tags, I think basefont is the only case.) All the examples mentioned, and also marquee, have been described in HTML5 CR as “obsolete” but still well-defined, and according to HTML5 CR, browsers are expected, and partly required, to support them all.
4) Your colleagues (designers/developers/...) may regard your code (and you) as old-fashioned, non-semantic, and whatever.
5) Code maintenance and development may be more difficult. If you have 1,000 pages with <body bgcolor=black> and the customer says they want a somewhat different background color, you would need to edit each page. This argument is, however, weaker than it seems to be. First, how often do such things actually happen? Second, if the pages have actually been generated using suitable tools, perhaps you just need to change the value of one parameter and regenerate them (or just let servers do that, if the pages are dynamically generated). Third, if you have a link element on all pages, referring to basic style sheet for the pages, as you normally should, you just need to add one rule to that style sheet. It is easy to override presentational HTML attributes with CSS.
To summarize, the practical arguments against your approach are rather weak. The most important arguments relate to coding style and principles.
I've added some more disadvantages:
Another disadvantage of using those tags is site bandwidth. When you put in html center, bgcolor and similar tags every time browser needs to load the whole content even if on every page those tags are the same or even if user visited this site many times. But when you place design in css file browsers may cache those files (especially when you set headers properly) so they only load html and images (if no cache is set).
One another thing is that if you decide to redesign the site/style new elements, it's much easier to put changes only in CSS files. It's possible in future you won't be doing those changes on your own or other companies/freelancers will be doing them and it will be much easier for them to make changes in the site. So the site will be cheaper to maintain.
In addition if html / php code is poor (or site is very complex) and many "visual conditions" appear in many files (for example on one page you decide to use one colour and you put it in HTML, on the other another colour) and something goes wrong it will be much easier to find the problem because you may simple cut some css and check where's the problem.
The disadvantage is when one of the major browsers chooses to get rid of the deprecated tag in a future release.
The advantage of using CSS over tags is that you can change the whole web site look and feel in a simple move.
Consider people that require larger font sizes. Colour blindness and also enable the most use of screen readers.
Even those consistent behaviour tags may be removed from browser. What if you would like to create HTML5 website? Then you will need to learn everything from scratch and change literally everything for your website to make it work because you never know if those tags will be supported in HTML 5 in future or only in older HTML documents
CSS provides easier maintenance, for one; client decides they want some elements aligned left instead of center? Change your css rule and poof, you're done. But if you're using old-school valign and such? Get ready to go change every single instance of that in the file(s).
I want to make this page look the same across all browsers. Specifically, I want the wrapping point of the text to be exactly the same on all browsers so I can create a PDF version with 100% accuracy. Check this out in FF vs. Chrome, for example.
http://santaspencil.com/desktop/embedded-test/embedded-fonts-test.php
Questions:
- Can it be done?
- Are there alternatives that don't require the user to download a plugin?
You should consider embedding the font file into your CSS. But as usual stone-age IE can not do this as you will need to include an EOT font file on your server.
http://base64fonts.com will convert your font files to base64 and then produce a css code for you to copy and paste in your html. this will help with insuring your font loads across browsers (except IE).
Good luck
... I want the wrapping point of the text to be exactly the same on all browsers ...
Bang head here (sign on brick wall). Web technology doesn't even try to do this. If you figure out a way to provide your own font -such as embedded webfonts- you can SORTA make it work. But if 100% is your goal, you might as well give up sleeping.
One of the neat things about browsers is their "liquid layout" capabitity, automatically rendering a page differently on a tablet than on a desktop to fill the different screen sizes for example. One of the prices you pay for this infinite rerenderability though is inability to specify the appearance exactly. Besides, edge cases will always arise and bite. For example if the available line is 0-73 units and the text you want to put in it is 74 units long, does it "fit" or not??? (i.e. does zero count? and is using up the very last unit a "fit" or an indication of the need to "wrap"?)
The only way to have browsers render your exact appearance is to give them what appears to them to be an image. Displaying the text on your screen, taking a screenshot of it, and making that screenshot into a *.GIF is one way.
A PDF file works too, as it appears to a browser to be a "funny" image with its own rendering engine. Most rendering engines are probably the same (i.e. the ones from Adobe) even if the browsers aren't the same, so it's much more likely to work. Providing PDF documents on the web works pretty well and is pretty widely supported. If a URL looks like http://yoursys.yourdomain/yourpath/yourfile.pdf most browsers will fetch it and start their PDF rendering tool and display it directly ...usually INside the browser window so the user isn't even aware of a different application having been used.
As to the last part of your question, it's the wrong question. It should be "solutions that don't require a plugin THE USER DOESN'T ALREADY HAVE". The advantage of a PDF plugin is the vast majority of users already have it. Not all plugins are evil/inconvenient ...just the less common ones (or the Flash plugin if your target is iPhones where users aren't even allowed to download it:-).
good luck!
This is probably way too late, but I did not know this until today. There is something called a non-breaking space, represented by in HTML, you can use to prevent unwanted line breaks or other such thing. Wikipedia has a pretty good writeup on it.
http://en.wikipedia.org/wiki/Non-breaking_space
The question is pretty self explanatory. Why shouldn't I strip it? It seems to me that most of the whitespace is used purely for formatting in the text editor and has no impact on the final page.
What's more, when these random nodes of whitespace do have an impact on the final page, it is usually an impact I do not want, such as a mysterious one character (after whitespace collapse) gap between inline-blocks.
I can strip all these whitespace text nodes pretty easily. Is there any reason I shouldn't?
edit:
It's mainly for the strange behaviour where whitespace, rather than for performance. One example is me wanting to put images side by side using inline-block instead of float, while preventing wrapping to next line and allowing them to spill out of the parent.
The whitespace causes these mysterious gaps, which can be removed by basically minifying the HTML source code to remove the whitespace between inline-blocks manually (and completely messing up your source code formatting in the process).
There's no reason not to, really. It can be done very easily with something like htmlcompressor.
However, assuming you're delivering all your html, css, and js files via gzip, then the amount of real-world bandwidth savings you'll see from stripping whitespace will be very small. The question then becomes, is it worth the trouble?
UPDATE:
Perhaps this will affect your decision. I performed a simple minification on a page of my website just to see what kind of difference it would make. Here are the results:
BEFORE minification
22232 bytes (uncompressed)
5276 bytes (gzip)
AFTER minification
19207 bytes (uncompressed)
5146 bytes (gzip) - 130 bytes saved
The uncompressed file is about 3 KB smaller after minification. But that's not really what matters. The gzip compressed file is what is sent over the wire. And you can clearly see that gzip does a pretty good job even with the non-minified HTML.
I see the benefit of minifying js libraries, or things that aren't changing constantly. But I don't think it's worth the trouble doing this to your HTML for a measly 130 bytes.
Let me give one reason why you shouldn't minify html:
How html eventually gets rendered is strongly tie to the CSS applied up on it, but the minifiers usually work without expecting the influence of CSS. All minifiers you can get out there at the time of writing, they remove the spaces in html based on certain assumptions of your coding and CSS styling, if you don't code it the way they expected, the minified rendering result in browser will be different from before minification.
For example, some of minifiers assume the space between "block elements" (such as <div/>, <p/>) can be removed, this is usually true, because spaces between them has no effect on rendering the final result. But what if in the CSS you set "display: inline" or "inline-block" for elements whose default display property is block?
Will below html snippet still rendering as it should be if you remove the spaces between <div/>s ?
<div style="display: inline">will</div> <div style="display: inline">this</div> <div style="display: inline">still</div> <div style="display: inline">work?</div>
You may argue that, we can reserve at least 1 space, and remove remaining consecutive spaces and that still save a lot bytes. Then how about <pre> tag and white-space: pre?
Try copy the html code snippet from below url and paste into your minifier, see if it produces result as before the minification:
https://jsfiddle.net/normanzb/58rpazL2/
The only downside of stripping out whitespace from production pages is readability, and maintainability for the person that follows you in editing that/those page(s); but if you maintain a 'properly'/'readable' whitespaced-version for editing, and then minify that post-editing to form the production pages then it doesn't really cause significant problems.
I'm not sure how effective, or useful, the technique will be, but there's nothing to stop you trying it.
Short answer: no reason whatsoever
The only real purpose white space serves is to make the code more human-readable. You can, over time, save a lot of bandwidth by stripping all the unnecessary white space out of your documents and it should be considered good practice for production code. If your compressing your content the saving will be less, but even 1% of 1GB is 10MB... If your doing 100GB in a month on a busy web site, cutting out 1% of the data might be the difference between two pricing tiers of hosting...
As you say, some browsers (usually IE, grrrr....) will occasionally interpret the white space when they render the page, but usually when this happens it's in a way you'd rather it hadn't...
When it comes to my markup, I'm anal. It always has to be perfectly indented, easily readable to me, and 100% valid with the W3C. Often time, when viewing the markup of other websites, I'm appalled with the lack of effort by the developer to try to and keep their markup in the browser clean, organized, and valid.
On the flip side, there's a lot of people who will force all their markup on to one, continuous line for the size saving benefits. This annoys me as well, though not to the same extent because it is done with a purpose. But for the most part, it seems like no developer ever actually looks at their markup in the browser and does anything about it.
Understanding that, to the parser in the browser, indents and spaces (usually) don't matter, how should I be handling my markup? Is it worth the extra time to get my markup perfectly easily readable to humans as well as the browser? Are all my \t's and \n's being used in vain?
There are some browsers who has bugs that renders indented well formed html completely wrong. Such as some versions of Internet explorer with tables and images.
Other than that, i try to keep sane indention, I don't spend to much time with it, just enough to make it easy to debug.
Is it worth the extra time to get my markup perfectly easily readable
My answer is no. The arguments:
Whoever tries to look at the code probably will want modify it so, for editing the code you need good code editor with code formatting (e.g. Netbeans). You'll very soon need other features like, syntax coloring.
Some users might prefer other type of formatting than you.
Anyone interested in readable HTML may use Tidy (of Tidy extension to Firefox) to format it.
It's a performance issue too: additional overload of formatting + stripping whitespace (and minifying when possible) will speed up the site. It's very important for sites with high traffic.
It's worth the effort imho since it helps you understand what exactly is going on in your html page, and that's definitely worth something.
If we want to write clean, elegant code in general this means we should want to generate nice, clean elegant html as well, not?
Not sure if this answers your question, but as long as the code is valid by W3C, is structured as intended. As far as your view-ability of the code (like view source) structure, that's really up to you, but I would not add too much clutter (comments etc). Use the correct DOCTYPE for your markup and you should be fine with that. I don't see any reason to "waste" time on making the source code from the browser "book" readable. The view source would only be beneficial to you so you can quickly see what's happening at a glance through source view.
I like to correctly format my markup, and I think it makes it easier to manage when I do.
Then again, I use ASP.NET and a lot of markup is generated through various controls and classes. In this case, I've decided it is not worth trying to track down each mis-aligned markup and see if something can be done to get the associated control to produce the correct result.
In short, nicely formatted markup is worth it if it can be accomplished without a huge effort.
Yes, in my opinion it is worth. It will be easier to maintain, for you and for other collegues, now and in the future.
About the disadvantage of lower performance, why not to develop a well indented and commented source file and to generate a minimized version to run on the server? It can be acheived with a simple series of regex replacements.