1. Advertising
    y u no do it?

    Advertising (learn more)

    Advertise virtually anything here, with CPM banner ads, CPM email ads and CPC contextual links. You can target relevant areas of the site and show ads based on geographical location of the user if you wish.

    Starts at just $1 per CPM or $0.10 per CPC.

"Above the fold" CSS

Discussion in 'CSS' started by KewL, Aug 21, 2014.

0
  1. #1
    Just curious on everyone's opinion. I'm sure this technique has been around for quite a while, but to me it seems like it's a popular new thing at the moment.

    If your not sure what it means, basically its the idea of putting the CSS for the top part of your page and the main content inside the <head> of your html doc, so that the user doesn't have to load the entire CSS file before browsing the main content.

    It seems like a good idea to me as far as performance goes, but it also makes your pages super sloppy. Hmmmmzzz

    What do you all think? Good, bad?
     
    KewL, Aug 21, 2014 IP
  2. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #2
    What you describe is gibberish and invalid markup. You can't put content in <HEAD> -- that BULL. Much less putting CSS in the markup is code bloat that doesn't leverage caching, making return visits to the same page slower and use more bandwidth.

    Much less it shouldn't render any faster anyways, the DOM has to be built before CSS is applied -- so it sounds like 100% grade A farm fresh BS.

    Do you have an example of said buggy broken halfwit coding in action and/or where someone would actually advocate such a jacktarded asshat way of building a site?

    Though really, if such gooftarded halfwit tricks actually did provide a benefit, it probably means there's something wrong with the site like fat bloated non-semantic markup sleazed together any-old-way. See 99% of the crap vomited up by "designers" dicking around in Photoshop, or the people who are embracing HTML 5 since the majority of them seem to be the people who were vomiting up HTML 3.2 and slapping 4 tranny on it. Now they wrap 5 lip-service around it and pat themselves on the back over how 'modern' they are.

    -- edit -- The laugh being that's the watered down version. I COULD tell you what I'm REALLY thinking after reading your post... :p
     
    deathshadow, Aug 21, 2014 IP
  3. KewL

    KewL Well-Known Member

    Messages:
    245
    Likes Received:
    16
    Best Answers:
    3
    Trophy Points:
    128
    #3
    I guess the most well-known advocator of this would be google. If you run your sight through their page speed analysis tool it will recommend it. Here's what they say on their page speed insights page...

    I've seen it a few places here's one example from the post I heard about it from:
    http://daverupert.com/2014/07/rwd-bloat-part-ii/

    I'd be curious to hear your response, it sounds like it does more harm than good.
     
    KewL, Aug 21, 2014 IP
  4. Adam_UK

    Adam_UK Member

    Messages:
    23
    Likes Received:
    22
    Best Answers:
    0
    Trophy Points:
    28
    #4
    I had to Google this, as I wasn't quite sure what you meant from your description. If I understand you correctly, you are talking about removing part of your CSS text and placing the relevant sections between <style></style> tags in your header, or within the top part of your HTML code in the body. The idea being, these styles will display faster than if they were within a linked CSS file and therefore 'User Experience' would be improved.

    I came across css-tricks DOT com /authoring-critical-fold-css/ which seemed to explain it fairly well. They also quote Google as being the culprit in giving the onus for it in the name of 'CSS Delivery Optimisation' via their PageSpeed Insight.

    However, the whole method seems to advise breaking well known web standards such as keeping your styles separate from your HTML document, which came about for a reason. And despite Google's name being included in the discuss, I would still suggest keeping your CSS files separate and unobtrusive from your HTML document as standards trump private companies.

    I would hazard a guess, it is on websites using the strange manifestations known as 'Bootstrap' or 'Foundation' and their twisted kin. Who enjoy the fetish of large and long CSS documents full of many classes and hatred for traditional practises; that are the focus of this method. Or perhaps instead, the wonderfully fragrant soup of Wordpress with it's many inline Style attributes wafting through it's generated documents, 'lubricated' with the sandpaper and grit of plugins and broken themes that take so long to download. Because in reality, having to use a technique of 'Above the Fold' may be a symptom of bad web design/creation practises.

    Because heavy CMS such as Wordpress or large-isgh documents as found in Bootstrap as so popular these days. And since Google has to index all sorts of sites. Their suggestions and advocacy may be related to helping these sites in particular, rather than promoting 'Above the Fold' as a general rule.

    Personally I've been won over by the Progressive Enhancement approach to web design. And from this perspective using styles as suggested is a big no-no.
     
    Adam_UK, Aug 22, 2014 IP
    deathshadow and kk5st like this.
  5. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #5
    Ok, what you are referring to has NOTHING to do with putting "content" inside HEAD. NOWHERE in anything you linked to do they even consider doing that since again, that's invalid markup and complete gibberish. In fact the use of the term 'above the fold' is completely incorrect and has jack **** to so with the topic at hand! ALL they are talking about is putting STYLE there, and to be frank that's a bunch of re-re bull, even if Google pagespeed suggests it.

    The ONLY scenario in which doing that would make any sense is if you have a page where you only have a single page website where ALL of your traffic is bounce with no return visits; that doesn't sound like a very healthy or successful website to me. (even if the parallax scrolling halfwits and script-tards seem bound and determined to piss all over the web by intentionally building such sites)

    Honestly Google Pagespeed went to crap the moment they added the 'pay for optimization' service and started getting kickbacks from CDN's. It's damned near useless now since it will give a 72k website built from less than a dozen files that loads in under a second a lower speed ranking than a multi-megabyte monstrousity built from hundreds of separate files that takes half a minute to load, just because the site that's ACTUALLY smaller isn't using a CDN or make use of any goofy tricks (like the one we're discussing) -- and that's that point at which I pretty much had to call it bull and move on to greener pastures. (like actually simply measuring filesize, file counts, and keeping the number of DOM elements under control). Kind of like Google Analytics it no longer delivers on it's promises and you are better off without it; very quickly going from being a useful tool to being little more than nube predation.

    Given said page's garbage CSS, lack of media targets, bloated slow rendering SVG crap inlined in the markup, idiotic code-bloat DOM-bloat HTML 5 asshattery, wasting time forcing the box model to IE quirks mode style behavior, ****ing users like myself by resizing the font based on screen width (WHY THE **** DO PEOPLE DO THIS?!?), lack of condensed font properties, gibberish use of numbered headings, lists around things with numbered headings (meaning semantically they likely AREN'T short bullet point list items) and static scripting in the markup...

    Not to be a broken record, but said fellow doesn't know enough about HTML, CSS, JavaScript or accessibility to be opening their trap on the subject of page speed or efficiency. He may have optimized for a faster first-load, but he's effectively plowed the speed of sub-pages, re-visits while doubling or more the overall bandwidth use in the process. Any time someone is using 28k of markup to deliver 1k of plaintext, you've got proof enough of that.

    Putting static CSS into the markup (or static JS for that matter) means it can't be CACHED. it's not cached across sub-pages when it's shared, its' not cached when someone comes back to visit the page, and that means MORE bandwidth use and slower page access. As I said before, the ONLY time that technique would pay benefits on a site is when you only have a single page website that nobody ever revisits -- which would be one HELL of a crappy website.

    Just to illustrate what I mean, you go to this guys home page, where he has this train wreck of HTML 5 and SVG crap:
          <header class="site-header">
        <div class="container">
          <a class="logo" href="/">
            <svg title="daverupert.com"><use xlink:href="#logo"></use></svg>
          </a>

          <nav role="navigation" class="navigation">
            <ul>
              <li><a class="icon-button" href="/"><svg title="Home"><use xlink:href="#icon-house"></use></svg></a></li>
              <li><a class="icon-button"  href="/archive.html"><svg title="Archive"><use xlink:href="#icon-archive"></use></svg></a></li>
              <li><a class="icon-button"  href="/about.html"><svg title="About"><use xlink:href="#icon-vcard"></use></svg></a></li>
              <li><a class="icon-button"  href="/atom.xml"><svg title="RSS"><use xlink:href="#icon-rss"></use></svg></a></li>
            </ul>
          </nav>
        </div>
      </header>
      <main id="content" role="main">
      
          <div class="container">
            <div class="posts">

  <ul class="archive-list">
    
      <li class="archive-post">
        <a href="/2014/08/web-archeology">
          <h2 class="archive-list-h">Web Archeology</h2>
          <p>Restoring some of the history of the web, the 1994 Microsoft.com homepage</p>
          <p class="meta">Published August 11, 2014 </p>
        </a>

      </li>
    Code (markup):
    Weighing in at 1.29k and having ZERO graceful degradation and buggy/broken/redundant semantics, I'd have this:

    <div id="top" class="widthWrapper">

	<h1>
		<a href="/">
			daverupert.com
		</a>
	</h1>

	<ul id="mainMenu">
		<li class="home"><a href="/">Home</a></li>
		<li class="archive"><a href="/archive.html">Archive</a></li>
		<li class="about"><a href="/about.html">About</a></li>
		<li class="rss"><a href="/atom.xml">RSS</a></li>
	</ul>

	<div class="posts">

		<h2>
			<a href="/2014/08/web-archeology">Web Archeology</a>
		</h2>
		<p>
			Restoring some of the history of the web, the 1994 Microsoft.com homepage
		</p>
		<div class="meta">Published August 11, 2014 </div>
    Code (markup):
    Coming in at 595 bytes, less than half the code... and it would look identical, load faster, perform better due to the lower number of DOM elements... and THAT's why I call most of HTML 5 a bunch of ignorant bull...

    Hell, look at the garbage white-space stripped CSS on that same page -- with such gems as using box-resizing for christmas only knows what, 100% widths on elements that default to that behavior, to sending the -text-resize parameter in a manner that means desktop Safari users can't use the zoom... using the stupid REM measurement for being too silly to be able to figure out inheritance, (which laughably overrides/ignores the media query font shtupping)... I mean hell, even this:

    body{font-size:87.5%;line-height:1.8;color:#3a3a3a;font-family:'Helvetica Neue',sans-serif;font-weight:300;}
    Code (markup):
    Between the lack of condensed properties and use of unreliable numeric font-weight, this white-space stripped garbage is bigger than if he'd just written it properly:

    body {
	font:normal 87.5%/180% 'Helvetica Neue', sans-serif;
	color:#3A3A3A;
}
    Code (markup):
    81 bytes, so 17 bytes smaller. It's a stunning example of what I mean when I call whitespace stripping more about sweeping developer ineptitude under the rug, than it is building faster websites as if it actually pays dividends, you've likely got something wrong somewhere else on the site.

    Which is why I'd be flat out dismissing that person's opinions about, well... just about everything.
     
    deathshadow, Aug 22, 2014 IP
  6. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #6
    Oh, and the scripttardery to load the external stylesheet with redundant rules to the inlined one? that's just the nail in the coffin of this "Dave Rupert"'s credibility.
     
    deathshadow, Aug 22, 2014 IP
  7. KewL

    KewL Well-Known Member

    Messages:
    245
    Likes Received:
    16
    Best Answers:
    3
    Trophy Points:
    128
    #7
    I guess my grammar was bad, but I never said to put the main content in your head. I said to put the css FOR your main content and the top part of your page, in the head. Like in a style tag like Adam pointed out. Your right though, thinking about it, it makes a lot more sense for one pagers. I didn't realize about the caching.

    We'll I guess that leads me to more questions. Why don't you like SVG? To me it seems like the best thing, the file size is generally smaller than a .png, and it will look crisp on a "retina" screen. Or are you just against inline-svg which makes your source pretty sloppy?

    One more, sorry. Why not white-space stripped CSS files? Even if the css was perfect, it would save a few bytes or k's ultimately leading to faster page loads. They're not editing their CSS in the stripped state, they have tools to do that after the fact. The only thing it's bad for is if other coders want to check out the source code, but generally that's not what the websites meant for. Come to think of it, another thing I've been saying is white-space stripped CSS files with a link to the uncompressed version in a note.
     
    KewL, Aug 22, 2014 IP
  8. kk5st

    kk5st Prominent Member

    Messages:
    3,497
    Likes Received:
    376
    Best Answers:
    29
    Trophy Points:
    335
    #8
    White-space stripping provides little actual benefit in bandwidth or speed, and that only once. Have you considered that a site is often maintained by someone other than the original developer. I can speak from experience there. It is my experience, too, that so-called minimized css, html or javascript is a pain in the ass to work with and more often than not is an indicator that the developer is less than competent. You might be alright, but my first impression would be otherwise.

    Coding should always be readable by a real human's Mark I eyeball. By real human, I mean the homicidal psychopath who knows where you live and must make sense of your code. Formatting is important.

    cheers,

    gary
     
    kk5st, Aug 22, 2014 IP
  9. kk5st

    kk5st Prominent Member

    Messages:
    3,497
    Likes Received:
    376
    Best Answers:
    29
    Trophy Points:
    335
    #9
    Oops, I meant to respond to this, since I read it the same as ds.
    But that is in fact, what you did say, even if you didn't mean it that way.
    Regarding svg files: They may be smaller than some png files, but since they are text used to describe each and every line within the image mathematically as xml, they can grow very, very large in a hurry. GIF files would be the better choice for most line art (since the patents are expired and nearly all gif libs now in use are now under the Gnu license). Also, until recently, svg was poorly supported (looking at you IE).

    cheers,

    gary
     
    kk5st, Aug 22, 2014 IP
  10. KewL

    KewL Well-Known Member

    Messages:
    245
    Likes Received:
    16
    Best Answers:
    3
    Trophy Points:
    128
    #10
    Ahh yeah I said it wrong, mah bad! I guess that makes sense.
    I usually have an .sass that i make css edits on and then a compressed version I upload. Can't say I really work with others or anything though.

    Yeah they can get rather large, but I still think SVG makes sense in certain scenarios (like simple icons, or logos).
     
    KewL, Aug 22, 2014 IP
  11. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #11
    Re-reading I think the issues is Oxford comma and/or programmer logic.
    "Could you please go shopping for me and buy one carton of milk, and if they have eggs, get 6!"
    Comes home with 6 cartons of milk.

    It's why I'm actually a fan of monolithic CSS for a site; not only caching what's on the current page -- but you can also pre-cache the appearance of sub-pages. The fraction of a second (oh noes, 5k gzipped instead of 4k) more on first-load being a non-issue.

    There is NO excuse for ANY website to really need more than 48k of CSS per media target UNCOMPRESSED... the vast majority of sites people waste hundreds of K of CSS on thanks to idoicy like bootcrap likely being able to be delivered in 16k or less CSS uncompressed. (which is usually half what they wrote WITH the 'framework' not counting the framework against it!) By the time it's gzipped you're looking at 5k or less if your code is worth a flying purple fish -- in which case what 'benefit' does crapping it into the markup offer?

    Of course with the halfwits using two to five k of CSS for every 1k they should be using in dozens of separate files, such concepts are ultimately lost on them.

    It's a needlessly convoluted and grossly inefficient file format. Typically if it's "smaller than a PNG" you don't know how to use a PNG properly. The ONLY advantage it offers is being fully scaleable -- but in most cases if I want that I'd probably use a webfont to store it since at least .TTF tries to be efficicent. XML is NOT an efficient data storage format -- it only exists to be human readable, which to be frank blindly dumping in endless numbers for polygon coordinates is not. It's a non-human readable data set in a non-machine readable format; no matter how many XML fanboy nutters call XML "machine readable" it is not. You show XML to a machine language programmer and call it "machine readable" you are likely to get a fist in the face.

    I mean, look at those crappy false simplicity icons in the menu of that guy's page. I mean, on top of the accessibility trash "what the hell do those middle ones even mean" (see "Ambiguous UI") -- That's basically 2k of non-cacheable content being loaded on every single one of his pages, where If I made those as 26x26 inside a 56x112 "sprite sheet" including hover states I very much doubt it would take more than two thirds that as a PNG... and I could probably bring it in at around 1k... that 1k being an external file that's CACHED across pages.

    It's not even about it making the source sloppy -- it's about the complete lack of caching that approach offers, again see that guys site where he's loading 7k of SVG in the markup of EVERY one of his pages, then somehow thinks that's going to be FASTER? Maybe, MAYBE on first-load, but that's about it. Later visits to the same page, and where it's used on every one of his sub-pages it's taking longer as it's not being cached.. In many cases it's also presentation, and presentation has NO DAMNED BUSINESS IN THE MARKUP in the first place.

    Really, SVG was abandoned by it's co-creators and champions over a decade ago when Adobe dropped it like a hot potato after buying out Macromedia. It's a bloated hard to use file format that was effectively stillborn for the better part of the first decade of it's existence. Now somehow it's magically back? I think not. A common format for vector images would be nice, but to be frank doing it in XML is not the answer.

    Of course with battery powered ARM based devices a significant portion of traffic, the floating point math and even heavier memory footprint (yes, they use MORE RAM than PNG/GIF/JPG) makes SVG a great way to bleed people's batteries since in terms of floating point -- even with the vector extensions -- a 1ghz ARM A8 is roughly equal to a 450mhz Pentium 2. Remember, ARM is about processing per watt, not per clock!. It's the same as how a lot of scripttards who seem to think websites need megabytes of scripting are finding out that they are pissing off mobile users as "time remaining" on the battery goes from 1 hour to 10 minutes visiting certain sites.

    The laugh being a LOT of what I'm seeing people do with SVG could just as easily be done with the Symbola or Last Resort fonts (windows and mac respectively) using UTF-8 extended code blocks -- like "Misc Symbols" U+2B00 to U+2BFF, "arrows" U+2190 to U+21FF, "geometric shapes" U+25A0 to U+25FF, etc, etc... Not to keep bashing on this "RWD" fellow, but his SVG arrows are a great example of this.

    Much less his goofy logo that isn't even worth wasting 5k of SVG on what shouldn't even be a 2k PNG since to be frank, there is no real reason for that to even need to be scaleable!

    Even the damned smileys here on this forum suffer from this -- the mutliple SVG files (that I pretty much have to block to make the site usable) each being larger than a simple sprite-sheet png and the associated CSS for ALL of them would be... and for what? A scaling that 95%+ of users will never even use or care about?

    If you're leveraging caching, practicing minimalism, understand inheritance and selectors, the amount saved isn't worth the extra step and pain in the ass it turns maintenance -- much less debugging when something goes wrong -- into. Generally most "preprocessors" (those 'tools' you mentioned) fall into this trap, making things more complex and more convoluted. The laugh of that being when people use their ignorance of how to use CSS to make wild claims about garbage like LESS and SASS actually making their bloated code "easier' to create and maintain -- when it is in fact doing the exact opposite... something they'd realize if they knew even the slightest about how to use HTML and CSS correctly. Akin to how most jQuery-tards don't know enough about JavaScript to know if jQuery is actually better or not! It's NOT!

    The vast majority of what people whitespace strip it makes little to no difference on, or at least wouldn't if their code wasn't completely ineptly developed bullshit. That's why typically I consider it to be little more than sweeping developer ineptitude under the rug -- it seems to most often be used on sites that I could make a fraction their whitespace stripped version on a simple rewrite WITHOUT whitespace stripping/minification. Usually because they don't use condensed properties, don't use minimalism, don't use semantic markup, throw endless pointless classes at things for no good reason (which pathetically there are now jackasses out there calling that 'faster' because of selector depth -- what a load of ****),

    Of course, there's a LOT of people obsessing about "render time" to the point they are sacrificing bandwidth on the altar of it -- complete nonsense akin to the anti-table nutjobs "never use tables" where they make up lies about rendering time and tables; why do I call it lies? Because if a 386/40 running Windows 3.1 and IE4 can render a table in an acceptable amount of time, that claim is 100% farm fresh manure in the age of super-ghz processors in the palm of your hand.

    See the halfwit idiocy being circulated right now about "responsive layout" being slow rendering. BULLSHIT! Bootcrap is slow rendering and slow transferring, HTML 5 coding with the endless pointless extra DOM elements for nothing is slow rendering and slow transferring. The way most people continue to sleaze out HTML 3.2, and until recently were slapping 4 tranny and now wrap 5 lip-service around it is slow rendering and slow loading.

    Responsive layout? DROP in that bucket -- unfortunately most people are either too ignorant or too stupid to be able to do it properly/efficiently, so out of ignorance they throw extra tags (DIV, SECTION, NAV, ARTICLE) in the markup for nothing, throw classes at everything in a presentational manner because the jacktarded asshat 'framework' they rely on tells them to, then sit around wondering why their page is a multi-megabyte slow loading monstrousity. Naturally the answer to such issues being to "throw more code at it" -- because that solves everything. :/
     
    deathshadow, Aug 22, 2014 IP
    malky66 likes this.