I have the following example code:
<body>
<div id="a"></div>
<div id="b"></div>
</body>
If I add empty lines between each of my original lines, like this:
<body>
<div id="a"></div>
<div id="b"></div>
</body>
does that do anything to my site's performance? Will the page load slower?
Yes, compact code speeds up page loading due to decreased payload...but not by a measurable amount, at least in most cases, unless your page is massive you won't see a difference.
Pages should be delivered via gzip, making the size difference between spaced and un-spaced negligible, just do what's readable to you, you'll thank yourself later. As with everything, you have to weight the costs, in this case a very minor difference in payload size, with what's easiest to maintain for you.
In theory, yes.
For the server, if it has to send out a 1MB file to each client, it has to spend n amount of time and resources sending out that one file. Now, if you were able to cut the file size in half, the time and resources it would take per user on the server would be .5n.
For the client, it has to download a file. Assuming a download rate of 25KB/S, a 1MB file would take 41 seconds to download. A .5MB file would take 20.5s. Thats a savings of 20 seconds by reducing the file size.
However, in practice. No, I would not worry about it, unless you're dealing with audio/video/picture data. That's because a character in a HTML document is only a couple bytes. Sure, you might have lets say 100 extra characters that you could trim and remove - whitespace for instance. At most you'd save up an additional 1KB per page.
I wouldn't be too concerned about it, unless you're developing an application or solution where it needs to be compact. But any modern or sub-modern computer won't break with 1KB extra data in their HTML file.
in your example, it saves up 3 bytes of code... so i don't think it has any noticeable effect on page loading time in modern times and it's internet speed. a better improvement would be to send your page gziped.
Page loading and compact code ? yes it really make things better as additional newlines and spaces are nothing but characters which need to be downloaded on the client end.
However i will suggest you to see it as part of the big strategy for optimization.
I will suggest you to take a look at YSlow/Yahoo Guidelines which will help you understand the different parts of "strategy" which is added to server and client components also. And collective results are just amazing for big sites.
Related
I have a problem. I am creating website and it is working well. But my boss told me that I shouldn't indent my codes because it can affect memory space because it reads the spaces or every indention in the code? Is this true? If yes can you provide me a reference for that so that I can defend myself. My boss show me some website in Japan that didn't indent their code and He ask me If indention is a program standard. If yes why some of the website in Japan didn't indent their code. It is all align left. I forgot some of the websites He showed me because it is in Japanese.
That's all thanks.
Here's the website that has no indention
http://www.dior.com/couture/home/ja_jp
For compiled code, it makes no difference whatsoever unless whitespace is significant in the language and means something that impacts memory usage.
Code transmitted over a network (HTML, CSS, JS, XML, etc.) can be made marginally smaller by removing spaces (in addition to compressing the output, which is considered a best practice). But this should never impact coding style and readability!
Whitespace removal can be done automatically when the page is served. This will actually increase the load on the server slightly (CPU, possibly memory), not reduce it. If the bandwidth savings are worthwhile (doubtful, if compression is enabled), it is an acceptable trade.
This answer shows the savings (or lack thereof) achieved by removing whitespace.
But my boss told me that I shouldn't indent my codes because it can
affect memory space because it reads the spaces or every indention in
the code?
"It" could refer to the web server sending the content or the browser reading the content.
Server: must send bytes of data from disk/memory in response to a request. So yes, extra whitespace may take a trivial amount more memory if the data is buffered and/or cached.
Browser: the browser can discard whitespace it doesn't need. It may never use any memory at all for those extra bytes of whitespace.
So (to be generous) your boss is right, but he is focused on the wrong thing. The savings (if at all) is measured in bytes and nanoseconds.
There are many, many other things that can be optimized first and will yield much more substantial benefits.
Hurting developer productivity is expensive. People indent code to make it more readable, and lack of readability equals lost productivity.
If one views the source code of http://www.google.com, it's highly minified. Even the html part. I am just wondering if formatted html takes up more space than minified HTML.
All I can think of is, that in formatted html, the characters : spaces, tabs and newline take space. And that is the only scope where html minification can save memory.
Yes, your thinking is correct. Removing whitespace and compressing the HTML will result in smaller download sizes.
If you'd like to see test cases for HTML minification, check out this blog post on Perfection Kills.
Excerpt:
Original size: 217KB (35.8KB gzipped)
Minified size: 206.6KB (34.3KB gzipped)
Savings: 10.4KB (1.5KB gzipped)
Minifying home page of amazon.com saves about 10KB with uncompressed
document, and only 1.5KB with compressed one.
Yes, there’s a difference. But for many (most?) websites this difference is not worth thinking about, because (1) the server will probably serve the HTML gzipped anyway, and (2) you don’t have enough pageviews to make the difference substantial. (Google does.)
Yes, minifying HTML, CSS, and JavaScript by removing spaces, tabs, newlines, and comments saves on bandwidth cost.
In addition to minifying the HTML, you should also be certain your HTML, CSS, and JavaScript is being GZIP'ed when being sent over the wire for even better performance. For more information about GZIP, read: http://developer.yahoo.com/performance/rules.html#gzip
I would also like to add that it is very important to think about bandwidth cost and page speed to any degree this day in age. Mobile web users are on a large upward swing. Even if you are not expecting a large mobile draw from your site, you are doing a disserve to those trying to access your site on their mobile 3G devices by not taking the proper considerations into bandwidth cost and speed.
I found by wget some_url that it has so many white spaces and blank lines like
<span class="meta">
someValue
</span>
And the whole document downloaded by wget is in good layout as we can see in Chrome dev tools,Does the document has so many white spaces and blank lines (or tabs) and they're downloaded as well as the main content.
e.g
if the document(also, download by wget or curl) is:
<div class=" someclass">
somevalue
</div>
there're 5 spaces(3 before someclass , 2 before </div>) and 2 blank lines wrapping somevalue
Was it downloaded in tighten form like:
<div class="someclass">somevalue</div>
if not,I'm shock by the fact that some many bandwidth is wasted by these mostly useless information,Are the just the wasted(except they're for layout purpose)?
It is my understanding that whitespace takes up just as much as a character- So technically yes, it's "a waste". However, generally speaking, it is something that you would not ever notice as there are many other things that hinder load time. if You were loading an incredibly large page with a high percentage of whitespace on an incredibly slow network, you might be able to notice.
Generally it is better to think not about how it affects performance (because it doesn't) and think more about whether it makes your code readable. When writing something you need to revisit or show to others, whitespace is very important. When obscuring code so people won't mess with it, getting rid of whitespace can go a long way.
You can set a compression algorithm for the webserver to use with the Content-Encoding header. For example, gzip: http://betterexplained.com/articles/how-to-optimize-your-site-with-gzip-compression/
However, the webserver doesn't have to do it. It's like you're strongly hinting for the webserver to compress your traffic.
Are there any benefits to omitting the closing body and html tags?
Why is the google.com homepage missing the closing body and html tags?
edit - with regards to bandwidth, it's an extremely small amount, really. Say 10 million hits # roughly 10 bytes saved ~ 100 mb only... Are there reasons other than bandwidth?
edit 2 - and nope, google (yahoo, microsoft, and others) are not w3-validator compliant... when it comes to bandwidth-saving en mass vs w3-compliance, I guess the latter's good for the sacrificing?
Think of how many times that page is served every day. Even small reductions in size can be significant at that volume of traffic.
(Although I work for Google, please don't treat this as an "official answer from Google" - it's a guess, but an educated one.)
Apart from a gain in bandwidth, there isn't.
Just because they do it you shouldn't.
You're thinking of that as a standalone thing. If they've done several different things that save bandwidth then it all adds up. Each one might not be significant on it's own but if they have 5 or 10 optimisations then it's significant in total.
Also, those ten bytes may well reduce the data size enough to make it take one less TCP/IP packet which will have significantly higher savings that simply reducing the size of one.
I think JB is on the right track. Their home page is about 8750 bytes (for me), meaning that if they can get 1458 bytes per tcp segment, it will be six packets. The point is not so much to make it 8750 bytes rather than 8760 but to make it six packets rather than seven.
This would make a cute Google interview question. :-)
Why does the number of packets matter? Because for modern internet connections, it's the latency that matters, not the roundtrips. A full packet is barely any slower than a 1-byte packet. The value is especially important at the start of a connection when the TCP windows are still opening.
Furthermore, the more packets, the more chance one of them will be lost, perhaps causing a very long delay. The chance is not very high but if you're already as tightly-tuned as they are, it's worth it.
So should you do it? I would say generally not, unless you're confident that you really are already sending just a handful of packets for the page in question. (You should measure it from a realistic client location.) Knowing that the page validates is worthwhile.
Adding to Jon Skeet's answer, this page shows there are 3 billion searches on Google per day. Don't know how accurate it is, but I would guess it's in the ball park.
</body></html> is 14 characters and at 3 billion searches per day, it amounts to approximately 39.12 GB of data per day ignoring compressions, or around 26 GB if we take gzipping into account.
However, Google might actually send the closing tags for body and html for older browsers by looking at their user agents. I cannot confirm or deny this, but looking at modern browsers - Safari, Firefox, and Chrome shows that all are missing the closing tags.
So if you think it works for you, then go for it :). There's no harm in implementing this which may or may not be a micro-optimization for you depending on the scale you're operating at.
According to W3C, body and html tags are optional and can be omitted
An html element's end tag may be omitted if the html element is not immediately followed by a comment.
A body element's end tag may be omitted if the body element is not immediately followed by a comment.
If W3C Recommendation says it is ok now, then it should be totally valid. So there is no reason not to do it, unless you don't like not closed tags
As for me, My ISP is injecting ads into my websites, they insert the script just before </body></html> , so i remove that to avoid their detection.
Simple question hopefully.
We have a style sheet that is over 3000 lines long and there is a noticeable lag when the page is rendering as a result.
Here's the question: Is it better to have one massive style sheet that covers everything, or lots of little style sheets that cover different parts of the page? (eg one for layout, one for maybe the drop down menu, one for colours etc?)
This is for performance only, not really 'which is easier'
3,000 lines? You may want to first go in and look for redundancy, unnecessarily-verbose selectors, and other formatting/content issues. You can opt to create a text stylesheet, a colors stylesheet, and a layout stylesheet, but it's likely not going to improve performance. That is generally done to give you more organization. Once you've tightened up your rules, you could also minify it by removing all formatting, which might shave off a little bit more, but likely not much.
Well, if you split those 3k lines into multiple files the overall rendering time won't decrease because
All 3000 lines will still need to be parsed
Multiple requests are needed to get the CSS files which slows down the whole issue on another level
According to this probably reliable source one file, to satisfy rule 1 (minimize http requests). And don't forget rule 10, minify js and css, especially with a 3000 line monster.
It'll be worse if you split them up because of the overhead of the extra HTTP requests andnew connections for each one (I believe it is Apache's default behaviour to have keep-alive off)
Either way, it all needs to be downloaded and parsed before anything can happen.
Separating that monster file into smaller once (layout, format and so on) would make development more efficient. Before deployment you should merge and minify them to avoid multiple http requests. Giving the file a new number (style-x.css) for each new deployment will allow you to configure your http server to set an expire date far into the future and by that saving some additional http requests.
It sounds like you are using CSS in a very inefficient way. I usually have a style sheet with between 400 and 700 lines and some of the sites that I have designed are very intricate. I don't think you should ever need more than 1500 lines, ever.
3000 lines of code is far to many to maintain properly. My advice would be to find things that share the same properties and make them sub-categories. For example, if you want to have one font throughout the page, define it once in the body and forget about it. If you need multiple fonts or multiple backgrounds you can put a div font1 and wrap anything that needs that font style with that div.
Always keep CSS in one file, unless you have completely different styles on each page.
the effort of loading multiple css files stands against the complexity (and hence speed) of parsing as well as maintenance aspects
If certain subsets of the monster file can be related to certain html pages (and only those certain pages) then a separation into smaller units would make sense.
example:
you have a family homepage and your all.css contains all the formats for your own range of pages, your spouse's, your kids' and your pet's pages - all together 3000 lines.
./my/*.html call ./css/all.css
./spouse/*.html call ./css/all.css
./kid/*.html call ./css/all.css
./pet/*.html call ./css/all.css
in this case it's rather easy to migrate to
./my/*.html call ./css/my.css
./spouse/*.html call ./css/spouse.css
./kid/*.html call ./css/kid.css
./pet/*.html call ./css/pet.css
better to maintain, easier to transfer responsibilities, better to protect yourself from lousy code crunchers :-)
If all (or most) of your pages are sooo complex that they absolutely need the majority of the 3000 lines, then don't split. You may consider to check for "overcoding"
Good luck
MikeD
The only gain in dividing your CSS would be to download each part in parallel. If you host each CSS on different server, it could in some case gain a bit of speed.
But in most case, having a single 3000 lines of code CSS should be (a bit) faster.
Check out the Yahoo performance rules. They are backed by lots of empirical research.
Rule #1 is minimize HTTP requests (don't split the file--you could for maintenance purposes but for performance you should concat them back together as part of a build process). #5 is place CSS references at the top (in < head>). You can also use the YUI compressor to reduce the file size of CSS by stripping whitespace etc.
More stuff (CDNs, gzipping, cache-control, etc.) in the rules.
I have a site css file that controls the styles for the overall site (layout mainly).
Then I have smaller css files for page specific stuff.
I even sometimes have more than one if I am planning on ripping out an entire section at a later date.
Better to download and parse 2 files at 20kb than 1 file at 200kb.
Update: Besides, isn't this a moot point? It only has to be downloaded once. If the pause is that big a deal, have a 'loading' screen like what GMail has.
3000 lines is not a big deal. If you split them into multiple chunks, it still needs to be downloaded for rendering. the main concern is the file size. i have over 11000 lines in one of our master css file and the size is about 150 kb.
And we gzipped the static contents and the size is drastically reduced to about 20 kb.. and we didnt face any performance issues.