Re: [CODE4LIB] CSS Optimization/Minimization: Remove line breaks?
Everyone, thanks for the replies. I apologize, I can't remember where I read about line length being an issue, but I can't find it now so it must have been a specific case. I'm glad I asked, though, because those books look promising. Joel -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Tim Spalding Sent: Friday, January 14, 2011 7:02 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] CSS Optimization/Minimization: Remove line breaks? I recommend immersing yourself in Steve Souder's two books-High Performance Websites, and Even Faster Websites. As it stresses again and again, the killer isn't the length of your content, but the number of files (only so many can be loaded in parallel), latency, expiry checks and so forth. Positioning of JavaScript is also critical, although putting it at the bottom can be a real pain. Sounders rules are built into YSlow as most of you probably know. LibraryThing's solution-a common one-is to use full CSS and JS on the dev. server. But on the real server each page has only one CSS and one JS file. And they have far-future expiry dates. The system changes their names (which are nonsense hashes) if they change. They've been compressed too, but that doesn't make much of a difference. Gzipping them helps more for bandwidth bills than speed. We split up files across two domains, www and static, because simultaneous download limits are by domain. We also toyed with CSS sprites a fair amount, to avoid multiple image loads-our sprite is http://static.librarything.com/pics/c.png-but the savings aren't that considerable. Best, Tim On Fri, Jan 14, 2011 at 12:15 PM, Richard, Joel M wrote: > I sort of agree with Mike on this, but I could play devil's advocate and > say... > > If you include comments in your CSS (which I'm sure you do, because we're all > conscientious developers and practice good coding standards. :), then > removing them and condensing the file down can make it significantly smaller. > It may be an extreme example, but YUI's base.css and base-min.css are 2.23 K > and 0.89 K respectively. My CSS files often weigh in at well over 15 K before > compression. > > Also, keep in mind that these days modern web pages depend heavily on the > stylesheet to render in a pretty manner. Therefore the smaller it is, the > faster the browser can make use of it. > > Just my two cents... This is also useful: > http://developer.yahoo.com/performance/rules.html > > --Joel (the other one) > > Joel Richard > IT Specialist, Web Services Department > Smithsonian Institution Libraries | http://www.sil.si.edu/ > (202) 633-1706 | (202) 786-2861 (f) | richar...@si.edu > > > > On Jan 14, 2011, at 11:30 AM, Mike Taylor wrote: > >> On 14 January 2011 16:28, Joel Marchesoni wrote: >>> Hey Everyone, >>> >>> I'm working on optimizing our CSS files and can't find anything about this >>> on the web. I know that some browsers/systems have issues with really long >>> lines in files and wanted to get some opinions about removing all line >>> breaks from a CSS file to conserve space. I've seen some optimizers that >>> give the option NOT to remove them, but don't explain why. >> >> Why bother? CSS files are tiny compared with the images you're no >> doubt also loading and literally negligible compared with video. They >> get loaded once per session, then cached in the browser. Messing with >> the whitespace will have absolutely no perceptible effect on >> efficiency for anyone who's not using a 300 baud modem. > -- Check out my library at http://www.librarything.com/profile/timspalding --
Re: [CODE4LIB] CSS Optimization/Minimization: Remove line breaks?
Drupal strips the whitespace and comments out of.js and .css, aggregates them and caches them. You can turn this off in development. Cary On Fri, Jan 14, 2011 at 4:02 PM, Tim Spalding wrote: > I recommend immersing yourself in Steve Souder's two books—High > Performance Websites, and Even Faster Websites. As it stresses again > and again, the killer isn't the length of your content, but the number > of files (only so many can be loaded in parallel), latency, expiry > checks and so forth. Positioning of JavaScript is also critical, > although putting it at the bottom can be a real pain. Sounders rules > are built into YSlow as most of you probably know. > > LibraryThing's solution—a common one—is to use full CSS and JS on the > dev. server. But on the real server each page has only one CSS and one > JS file. And they have far-future expiry dates. The system changes > their names (which are nonsense hashes) if they change. They've been > compressed too, but that doesn't make much of a difference. Gzipping > them helps more for bandwidth bills than speed. We split up files > across two domains, www and static, because simultaneous download > limits are by domain. > > We also toyed with CSS sprites a fair amount, to avoid multiple image > loads—our sprite is http://static.librarything.com/pics/c.png—but the > savings aren't that considerable. > > Best, > Tim > > On Fri, Jan 14, 2011 at 12:15 PM, Richard, Joel M wrote: >> I sort of agree with Mike on this, but I could play devil's advocate and >> say... >> >> If you include comments in your CSS (which I'm sure you do, because we're >> all conscientious developers and practice good coding standards. :), then >> removing them and condensing the file down can make it significantly >> smaller. It may be an extreme example, but YUI's base.css and base-min.css >> are 2.23 K and 0.89 K respectively. My CSS files often weigh in at well over >> 15 K before compression. >> >> Also, keep in mind that these days modern web pages depend heavily on the >> stylesheet to render in a pretty manner. Therefore the smaller it is, the >> faster the browser can make use of it. >> >> Just my two cents... This is also useful: >> http://developer.yahoo.com/performance/rules.html >> >> --Joel (the other one) >> >> Joel Richard >> IT Specialist, Web Services Department >> Smithsonian Institution Libraries | http://www.sil.si.edu/ >> (202) 633-1706 | (202) 786-2861 (f) | richar...@si.edu >> >> >> >> On Jan 14, 2011, at 11:30 AM, Mike Taylor wrote: >> >>> On 14 January 2011 16:28, Joel Marchesoni wrote: Hey Everyone, I'm working on optimizing our CSS files and can't find anything about this on the web. I know that some browsers/systems have issues with really long lines in files and wanted to get some opinions about removing all line breaks from a CSS file to conserve space. I've seen some optimizers that give the option NOT to remove them, but don't explain why. >>> >>> Why bother? CSS files are tiny compared with the images you're no >>> doubt also loading and literally negligible compared with video. They >>> get loaded once per session, then cached in the browser. Messing with >>> the whitespace will have absolutely no perceptible effect on >>> efficiency for anyone who's not using a 300 baud modem. >> > > > > -- > Check out my library at http://www.librarything.com/profile/timspalding > -- Cary Gordon The Cherry Hill Company http://chillco.com
Re: [CODE4LIB] CSS Optimization/Minimization: Remove line breaks?
I recommend immersing yourself in Steve Souder's two books—High Performance Websites, and Even Faster Websites. As it stresses again and again, the killer isn't the length of your content, but the number of files (only so many can be loaded in parallel), latency, expiry checks and so forth. Positioning of JavaScript is also critical, although putting it at the bottom can be a real pain. Sounders rules are built into YSlow as most of you probably know. LibraryThing's solution—a common one—is to use full CSS and JS on the dev. server. But on the real server each page has only one CSS and one JS file. And they have far-future expiry dates. The system changes their names (which are nonsense hashes) if they change. They've been compressed too, but that doesn't make much of a difference. Gzipping them helps more for bandwidth bills than speed. We split up files across two domains, www and static, because simultaneous download limits are by domain. We also toyed with CSS sprites a fair amount, to avoid multiple image loads—our sprite is http://static.librarything.com/pics/c.png—but the savings aren't that considerable. Best, Tim On Fri, Jan 14, 2011 at 12:15 PM, Richard, Joel M wrote: > I sort of agree with Mike on this, but I could play devil's advocate and > say... > > If you include comments in your CSS (which I'm sure you do, because we're all > conscientious developers and practice good coding standards. :), then > removing them and condensing the file down can make it significantly smaller. > It may be an extreme example, but YUI's base.css and base-min.css are 2.23 K > and 0.89 K respectively. My CSS files often weigh in at well over 15 K before > compression. > > Also, keep in mind that these days modern web pages depend heavily on the > stylesheet to render in a pretty manner. Therefore the smaller it is, the > faster the browser can make use of it. > > Just my two cents... This is also useful: > http://developer.yahoo.com/performance/rules.html > > --Joel (the other one) > > Joel Richard > IT Specialist, Web Services Department > Smithsonian Institution Libraries | http://www.sil.si.edu/ > (202) 633-1706 | (202) 786-2861 (f) | richar...@si.edu > > > > On Jan 14, 2011, at 11:30 AM, Mike Taylor wrote: > >> On 14 January 2011 16:28, Joel Marchesoni wrote: >>> Hey Everyone, >>> >>> I'm working on optimizing our CSS files and can't find anything about this >>> on the web. I know that some browsers/systems have issues with really long >>> lines in files and wanted to get some opinions about removing all line >>> breaks from a CSS file to conserve space. I've seen some optimizers that >>> give the option NOT to remove them, but don't explain why. >> >> Why bother? CSS files are tiny compared with the images you're no >> doubt also loading and literally negligible compared with video. They >> get loaded once per session, then cached in the browser. Messing with >> the whitespace will have absolutely no perceptible effect on >> efficiency for anyone who's not using a 300 baud modem. > -- Check out my library at http://www.librarything.com/profile/timspalding
Re: [CODE4LIB] CSS Optimization/Minimization: Remove line breaks?
I sort of agree with Mike on this, but I could play devil's advocate and say... If you include comments in your CSS (which I'm sure you do, because we're all conscientious developers and practice good coding standards. :), then removing them and condensing the file down can make it significantly smaller. It may be an extreme example, but YUI's base.css and base-min.css are 2.23 K and 0.89 K respectively. My CSS files often weigh in at well over 15 K before compression. Also, keep in mind that these days modern web pages depend heavily on the stylesheet to render in a pretty manner. Therefore the smaller it is, the faster the browser can make use of it. Just my two cents... This is also useful: http://developer.yahoo.com/performance/rules.html --Joel (the other one) Joel Richard IT Specialist, Web Services Department Smithsonian Institution Libraries | http://www.sil.si.edu/ (202) 633-1706 | (202) 786-2861 (f) | richar...@si.edu On Jan 14, 2011, at 11:30 AM, Mike Taylor wrote: > On 14 January 2011 16:28, Joel Marchesoni wrote: >> Hey Everyone, >> >> I'm working on optimizing our CSS files and can't find anything about this >> on the web. I know that some browsers/systems have issues with really long >> lines in files and wanted to get some opinions about removing all line >> breaks from a CSS file to conserve space. I've seen some optimizers that >> give the option NOT to remove them, but don't explain why. > > Why bother? CSS files are tiny compared with the images you're no > doubt also loading and literally negligible compared with video. They > get loaded once per session, then cached in the browser. Messing with > the whitespace will have absolutely no perceptible effect on > efficiency for anyone who's not using a 300 baud modem.
Re: [CODE4LIB] CSS Optimization/Minimization: Remove line breaks?
On 14 January 2011 16:28, Joel Marchesoni wrote: > Hey Everyone, > > I'm working on optimizing our CSS files and can't find anything about this on > the web. I know that some browsers/systems have issues with really long lines > in files and wanted to get some opinions about removing all line breaks from > a CSS file to conserve space. I've seen some optimizers that give the option > NOT to remove them, but don't explain why. Why bother? CSS files are tiny compared with the images you're no doubt also loading and literally negligible compared with video. They get loaded once per session, then cached in the browser. Messing with the whitespace will have absolutely no perceptible effect on efficiency for anyone who's not using a 300 baud modem.
Re: [CODE4LIB] CSS Optimization/Minimization: Remove line breaks?
I haven't heard of that specific issue with CSS optimization. It isn't mentioned in the page for the YUI CSS compressor, which removes white space "not required for the CSS to work": http://developer.yahoo.com/yui/compressor/css.html Please reply back if you can document the line length issue. Joe Ryan Digital Library Initiatives NCSU Libraries >>> Joel Marchesoni 01/14/11 11:28 AM >>> Hey Everyone, I'm working on optimizing our CSS files and can't find anything about this on the web. I know that some browsers/systems have issues with really long lines in files and wanted to get some opinions about removing all line breaks from a CSS file to conserve space. I've seen some optimizers that give the option NOT to remove them, but don't explain why. Thanks, Joel Marchesoni Tech Support Analyst Hunter Library, Western Carolina University http://library.wcu.edu/ 828-227-2860 ~Please consider the environment before printing this email~ --
[CODE4LIB] CSS Optimization/Minimization: Remove line breaks?
Hey Everyone, I'm working on optimizing our CSS files and can't find anything about this on the web. I know that some browsers/systems have issues with really long lines in files and wanted to get some opinions about removing all line breaks from a CSS file to conserve space. I've seen some optimizers that give the option NOT to remove them, but don't explain why. Thanks, Joel Marchesoni Tech Support Analyst Hunter Library, Western Carolina University http://library.wcu.edu/ 828-227-2860 ~Please consider the environment before printing this email~ --