Opera 12.17 is here...

This gives me at least SOME hope as they are at the very least doing security fixes for Opera 12 for the time being.

Given what a pathetically useless piece of crippleware Opera 15/newer is by comparison, much less the halfwit idiocy of switching to FF/Chrome style version releases where there's a major revision number change every time there's a stiff breeze... It's nice to at least see some effort to maintain the REAL feature-complete Opera, as opposed to the steaming pile of manure known as Chrome with the Opera logo slapped on it any old way.

Not that I'm calling Chrome pathetically useless crippleware... Oh wait, from a user interface perspective, YES I AM.

 

When you said that last time it kind of triggered my BS alarm but I didn't contest it at the time... thanks for linking to a compatibility table because... well... notice that it was supported as of 12.1 on that chart?

Though honestly spdy is just more sweeping under the rug the real problem of dumbass developers who have no business building websites in the first place blowing a megabyte in several dozen files for single digit k's of actual content text and a half dozen content images; See these forums that even in Firefox to make it useful I have to block x.dpstatic.com to even TRY to get into the forums in a useful manner thanks to the 551k in 8 files of scripttard "javascript for nothing" -- entirely what one comes to expect the moment you see the fat bloated idiotic train wreck of "let's make it cryptic and harder to use while calling it easier and hoping placebo effect makes up for it" BULL known as jQuery.

Because again, SPDY would probably serve no legitimate purpose if people didn't waste 778k in 21 files -- with a ridiculous 51k of markup -- to deliiver a mere 2.3k of plaintext and only two actual content images. (this thread before this post was added). Blocking jQuery and all the x.static crap guts it down closer to what it probably should be in the first blasted place -- around 120k in 12 files... though really there's no excuse apart from developer ineptitude for it to be more than HALF that... particularly since there's only

IT's scripttard BS like that which makes me run scripting blocks, domain blocks, user CSS and a whole slew of other things to even come close to making usable the ineptly coded front-ends on forums like Xenforo, vBull, or phpBB.

Never know whether to laugh or cry when I see three quarters of a megabyte doing 70k's job.

 

While it reduces handshakes and sends headers compressed, if it's delivering 50% you've done something wrong. Some of my sites are so small, it actually takes longer and increases overhead since it's HTTPS manditory -- SPDY is great if you "need" HTTPS, it makes it take LONGER if you don't since you introduce the overhead of encryption.

A 'speed freak' would not be wasting 515k of javascript on a FORUMS. I agree that using a separate domain so you aren't wasting the overhead of header info like cookies is a good idea; my problem is with the fat bloated crap it pulls that sucks laptop and mobile batteries dry, and causes execution spikes when they run, AND make it take longer to actually RENDER the page. That's why I'm blocking x.dpstatic.com/j -- to get rid of the scripttard BS that just gets in the way of using the site.

Assuming it doesn't get flushed to make room for other sites you visit... which for me I can blow out my browser cache inside a day easily, making all that dicking around with cache-control nonsense just more placebo BS to make up for developer ineptitude.

I laugh when certain server owners even use that as a way to make mobile faster; I'm so sure that with flash mass storage and memory amounts a quarter or less that of your average desktop all that cache-control crap is actually going to be obeyed... RIGHT.

In fact, for this page view, I opened up the network monitor, and not a SINGLE HTTP request was made to dpstatic.com for anything (because I've visited the site within the last year, it knows to not bother looking for anything there again).

By itself -- compressed -- jQuery is half the total filesizes I have as an ideal target for an entire template uncompressed -- that's HTML+CSS+SCRIPTS+IMAGES not counting content. Uncompressed jQuery is 75% my upper limit for an entire PAGE FULL OF CONTENT compressed.

Really if after gzip compression a developer "needs" more than 24k of javascript - even including any ajaxtardery - on a forums, they probably have no blasted business writing code for a forums.

Though this:

Is the typical fantasy-land BULL that makes me think you don't actually know enough JavaScript to make a sane and rational choice on using scripting; Oh noes, you might need one crappy little function to try/catch down the XML chain and another small function to provide a polyfill for querySelector/querySelectorAll -- which COMBINED shouldn't break more than 1.5k uncompressed -- that's SO worth a fat bloated 96k library that encourages slow/sloppy/needlessly and pointlessly cryptic methodology.

The handful of things that take less code to be written without jQuery usually don't belong on a website in the first place or are CSS's job. Everything else can typically be written smaller without it or more efficiently/feature-rich at the same size. Take crap like the typical image rotator -- which in jquery I've seen range from 8 to 16k while relying on the library, for functionality that shouldn't even break 6k without it. Using my upcoming JS library that's meant to kick "framework" bullshit to the curb, I've got a full featured "slider" demo that only takes 3.5k with a 16k library (all numbers uncompressed)... I've seen form handlers to the tune of 16k or more that rely on that garbage HTML 5 BS 'data-' attribute crap (nothing like putting stuff in the markup that has no business in the markup) that doesn't equal the functionality of what I can do in 4k of scripting WITHOUT any library... and of course my totals is with actually generating the scripting only elements in the scripting and hooking onto elements instead of inlining scripting with attributes; which is why usually I end up with less markup in the process as well! ... and that's before we even talk graceful degradation.

I've never seen anything done using jQuery that didn't fall into one of those three categories -- would be simpler/less code without the library (WITHOUT counting the library against that!), is CSS' job, or has no business on a website in the first damned place. That people are DUMB ENOUGH to buy the lie that jQuery is good, can only be attributed to the use of card stacking, testimonial, glittering generalities and bandwagon to create a placebo effect. Me, I go right for the plain folks, transfer and name calling.

Also seems like convincing people of that is a uphill battle against cognitive dissonance akin to convincing a faith-tard that their holy writ ain't the least bit legit, it's a bunch of bull****.

Always love the 'unneccesary pageloads' defense used by the Ajaxtards -- I'm not saying that using Ajax for that is bad, but if your markup and content is so bloated (like say... 52k doing 10k's job) that it makes a significant difference (given that everything else should be cached on a normal pageload) then you have done things horrifically and terrifyingly badly. It just reeks of the "pageloads are evil" paranoia spewed forth by people who don't understand enough HTML/CSS to write their page efficiently in the first place.... Like say (again to flog the deceased equine) 51k of markup doing 10k's job?

https://x.dpstatic.com/j/xenforo/xenforo.js
horrifically and terrifyingly badly...

I'd eat a bullet before I'd allow 174k of scripttard bull that requires a 96k library to even function on something as ridiculously simple as a forums; where even with AJAX submits and alert polling there's no excuse to break 32k WITHOUT any 'framework'... But yeah, sure -- it makes everything 'faster' and 'easier' -- RIGHT. Tell me another one Josephine...

All this stuff is just sweeping deep rooted issues under the rug and going "la la la la" Vancome lady style. Again, if you don't know what's wrong with wasting 55k of markup on 2.3k of plaintext and two content images, or 778k in 21 files for a thread load on a forums (something that probably shouldn't even break 70k in 8 files) -- then wonder why you need all these goofy tricks to "speed up the site" and constantly struggle with server load... shya, you know what? uh-uh...

So excuse me if my reaction to calling yourself a "speed freak" is akin to Bill Cosby's Noah... RIGHT...

 

Just to illustrate what I mean by developer ineptitude and sweeping bad code under the rug:

<nav>
	
		
			
				
			
		
			
				
			
		
	

	<fieldset class="breadcrumb">
		
			
		<div class="boardTitle"><strong>Digital Point</strong></div>
		
		<span class="crumbs">
			
				<span class="crust homeCrumb" itemscope="itemscope" itemtype="http://data-vocabulary.org/Breadcrumb">
					<a href="//www.digitalpoint.com/" class="crumb" rel="up" itemprop="url"><span itemprop="title">Home</span></a>
					<span class="arrow"><span></span></span>
				</span>
			
			
			
				<span class="crust selectedTabCrumb" itemscope="itemscope" itemtype="http://data-vocabulary.org/Breadcrumb">
					<a href="https://forums.digitalpoint.com/" class="crumb" rel="up" itemprop="url"><span itemprop="title">Forums</span></a>
					<span class="arrow"><span>&gt;</span></span>
				</span>
			
			
			
				
					<span class="crust" itemscope="itemscope" itemtype="http://data-vocabulary.org/Breadcrumb">
						<a href="https://forums.digitalpoint.com/.#the-digital-point.1" class="crumb" rel="up" itemprop="url"><span itemprop="title">The Digital Point</span></a>
						<span class="arrow"><span>&gt;</span></span>
					</span>
				
					<span class="crust" itemscope="itemscope" itemtype="http://data-vocabulary.org/Breadcrumb">
						<a href="https://forums.digitalpoint.com/forums/general-chat.19/" class="crumb" rel="up" itemprop="url"><span itemprop="title">General Chat</span></a>
						<span class="arrow"><span>&gt;</span></span>
					</span>
				
			
		</span>
	</fieldset>
</nav>

Code (markup):

HTML 5 bloat redundant to heading navigation (that stupid malfing nav tag), endless pointless classes for nothing, that stupid 'itemprop' code bloat that nothing actually uses, absolute URI's for no good reason, little if anything resembling semantic markup with the breadcrumbs effectively a run-on sentence since there are no actual block level tags, content cloaking and/or STRONG doing a heading's job (since that's a non-render element, it's the former!)... and what the blue blazes makes a section of code with no INPUT, BUTTON or TEXTAREA be a FIELDSET? REALLY? HERPAFREAKINGDERP.

It just reeks of "semantics, what's that" and HTML5-tardery akin to the old microformats junky data scraping BS. There is NO legitimate excuse other than developer ineptitude for that section of code to be anything more than:

<ul class="breadCrumbs">
	<li><a href="//www.digitalpoint.com">Home</a></li>
	<li><a href="/">Forums</a></li>
	<li><a href="/.#the-digital-point.1">The Digital Point</a></li>
	<li><a href="/forums/general-chat.19/">General Chat</a></li>
</ul>

Code (markup):

Since everything else can either be done from the CSS, is 'wishful thinking aria roles' bullshit that NO UA gives a flying purple fish about, or just plain has no business in the markup in the first place. That's 1.5k vs. 0.25k that in 99.999% of usage scenarios is 'close enough'; actually, the latter is more useful to people on screen readers since it's not going to come across as a run-on sentence.

... and that's basically what the AJAX-tardery, JS for nothing, and goofy server tricks are trying (and failing) to sweep under the rug, letting the server take longer to build the page's content and waste time string processing every time there's a pageload.

 

Just because there are opcodes for it doesn't mean it doesn't leave that execution pipe hanging... Where the blue blazes did you get the idea that's how that works?!? Sure, averaging 3.5 clocks for every DWORD (or QWORD x64) over the stock 28 (p4) to 48 (AMD, Atom, P3) 'brute force' code is a massive improvement, but given how much of that is balanced out by caching and memory controller prefetch much less the memory bus bottleneck, it ends up something of a wash... at least until memory bus stops being anywhere from one-half to one-fifth the cpu clock. (though it does make WRITING encryption code WAY easier at the machine language level). Of course, that bus disonnance is why the 12 core AMD's in super-ghz land (1 to < 2ghz) can be more attractive than a hyper-ghz (2ghz+) quad Xeon depending on what you are doing for server activity.

Interesting, as that's not what the waterfall in Firebug or Dragonfly is showing...

Which on 3 runs after a cache flush is saying 75% faster for HTTP here, and subsequent attempts come in at 50% faster for HTTP... 100 runs comes in at a nice 7 times faster for HTTP, so ... nice way to shoot down your own argument.

http://www.cutcodedown.com/for_others/digitalPoint/HTTPIsFaster.png

Cute though how after a cache flush on only three runs, it's averaging 512ms... but on a 100 run (flush or no) It's coming in at 66ms or less. NOT that there's sufficient timer accuracy in the process to trust any number smaller than 66ms... but that's JS for you.

Have to ask, what browser? I'm not getting that in Opera, FF or Chrome so... Of course, it could be you're sitting on top of your server (or a major pipe to it) and I'm not... that's why tools like that one are 'flawed' as without de-regionalization, it can lead you to false assumptions.

Firefox, web developer toolbar, information -> document size.

... and it's probably not right, as there are several files linked to in the markup not showing up on the list, so it's likely far more than the 515k that tool reports; though it's completely inline with the waterfall... though it also might be getting confused since it seems to be downloading ads.lfstmedia.com/getad?site=232235 twice... and it's NOT caching either in FF since it has a query; the trap of that stupid "put getdata at the end of your static includes" method.

Or you run out of cache memory because you actually *SHOCK* visit websites other than this one, and the browsers cache manager starts flushing things regardless. Let's face it, the 30-40 megs of memory cache and 128-256 megs of disk cache limit (or even less on mobile, particularly since they don't cache to flash since they don't want to burn it out prematurely) doesn't go very far these days... hence why the oldest cached item on my phone is from 3 days ago, and on this laptop (which has never seen a flush -- as opposed to my workstation which is flushed too often to use it for testing this type of thing) is 5 days ago.

Excepting I've never seen anyone bother trying to make the site faster by actually fixing what's REALLY wrong, which can deliver 5x or more the benefits.

I would REALLY be questioning those numbers; cache limits alone should be preventing that from happening unless the majority of those UA's are bots not retrieving anything but the markup. Cache-control is a cute idea, but unless you are allocating hundreds of megabytes of RAM and disk space as cache or people visit only one or two websites a day, it's a pipedream.

Though caching servers provided by ISP's may be picking up the slack. That happens a lot... in which case you aren't seeing the whole picture.

Normally I agree with that thinking, but to me doing so would hinge on how many people are going to those other parts of the site -- I may have a skewed viewpoint on that since I've don't visit anything but the forums on a daily, or even monthly basis.

Uhm... BULLSHIT? Let's use XMLHTTPRequest as an example:

function makeAjax() {
	if (window.XMLHttpRequest) return new XMLHttpRequest();
	function axObj(n) {
		try { return new ActiveXObject(n); } catch (e) { return null; }
	}
	return 
		axObj('Msxml2.XMLHTTP.6.0') ||
		axObj('Msxml2.XMLHTTP.3.0') ||
		axObj('Microsoft.XMLHTTP');
}

Code (markup):

From that point on it's functionally identical; NO differences worth even mentioning.

In terms of CSS, you use it properly you shouldn't be needing to do ANYTHING with scripting...

Unless of course you count ignorance of how to use JavaScript or CSS properly -- which of course describes 99.999999999999999999999999999999999999999999999999999999% of the folks who seem to think jQuery serves a legitimate purpose other than pissing all over the Internet.

Bwhaahhahaa... the one time I say rotator instead of slideshow -- and you didn't know what I meant. The term 'rotator' for images has come to NOT mean rotating AN images, but switching between a LIST of images or other content. You know, like banners and so forth?

Google it:
https://www.google.com/search?q=image+rotator+javascript

Or as I just wrote in the documentation of the demo in my soon to be released library, "eFlipper - A full featured banner rotator / carousel / flipper / slideshow / slider / whatever the blue blazes they are calling them this week."

Which are thankfully going away in Gecko and Blink... though really if the handful of cases you would need that actually impacts your overall CSS size, you are probably using more CSS than you need to. Admittedly, most people use two to three times as much CSS as they need to, just as they use three to five times as much markup for no legitimate benefit.

NOT that I would use scripting to try and fix that; since that's just stupid bull that wastes bandwidth for nothing and is the antithesis of graceful degradation... but I have this "people don't get linear gradients, box shadows and rounded corners on legacy browsers, OH WELL" attitude towards it.

Though I always find it a laugh when people list these massive libraries as "css savings" or "simpler scripting" when I'm most always using anywhere from one-half to one-tenth the code WITHOUT them... with NOT counting the size of those frameworks against it -- and that more than anything else is what makes me call bullshit on things like jQuery, LESS, SASS, OOCSS, blueprint, bootstrap, etc, etc... It always leaves me asking "Savings!?! WHAT SAVINGS?!?"

... and when fat bloated json or XML delivery is usually the same size (or sometimes even larger)... Though at least you didn't use the thing the die-hard AJAX-tards claim about it 'saving handshakes'; I've had a few people say that and it's like "Ok, we're done here moron."

To me it's just one of those things where if MAYBE people didn't have markup to content ratios of 20:1 they wouldn't need to throw even MORE code at it. Unless you're unrolling loops in machine language, if someone tells you using more code is going to be faster or better your BS alarm should be ringing.

Except we're not just talking transfer; you're also talking execution... and compression/decompression.

... and with bloated sites creeping up to a megabyte to deliver single digit k of plaintext and single digit numbers of images, with scripting who's filesizes are two to five times larger than the images of the theme; well... if you don't know what's wrong with that...

Particularly when it's typically 500k or more scripting doing the job of 20k... ALL of which has to be parsed (and much of it run) before the page can even render? Hence that wonderful 2 second delay on sites like this scripting enabled before you dare click on anything?

Which they used to do just fine without the microdata... Of course that in your example it's masking the URL is part of why it's so easy to abuse in the long term, which is why I'd not be surprised to see an update that slaps down sites for using it sooner than later.

But my real problem with that crap is twofold...

First, what the hell happened to "Code for the users, not the engine?" -- of course your SEO-tard scam artists nudniks defend this bloated idiotic halfwit bull saying things like "Matt Cutts doesn't know what he's talking about"; which of course is WHY I consider the people promoting this crap to be scam artist as who would be their biggest enemy? That's right, the guy in charge of the part of Google that slaps people down for abuse.

Though admittedly, Google right now has a 'left hand doesn't know what the right is doing" thing going on... Their marketing and advertising scamtards are in direct conflict with their anti-spam and search efficiency experts. Makes reading anything by Google feel like it was written by someone with multiple personality disorder.

But still this:

Is the antithesis of how we've been told to write websites for a decade, no matter how much the black hat SEO-tards want it to be otherwise.

Depends on who at Google you're listening to... It working on Google being in conflict with what their anti-spam people and webmaster guidelines have been telling us; sadly the webmaster guidelines seeming to have recent changes more geared towards scamming people than helping make sites better -- see their entire "pageSpeed" bullshit where crappy bloated idiotic websites get a 50% speed boost, while sites I've written profile 20% slower with their nonsense.

My second issue with it though is FAR more deeply rooted; it's the implementation. The breadcrumb one is a GREAT example of this as apparently what they are telling us is that search engines are too stupid inside a breadcrumbs list (which semantically SHOULD BE A LIST) are too stupid to realize that a anchor might actually be the URI and the text inside the anchor might actually be the title... Think about that -- it's REDUNDANT TO THE BLOODY MARKUP!!!

If that doesn't make your teeth hurt... Seriously, why the hell does it need all that garbage to say "these are breadcrumbs" -- If they had ONE attribute on a UL, then was smart enough to realize that the anchors are the links and the text inside the anchors is the titles for those links, I'd be fine with it... but that implementation? OH HELL NO! -- Dir mir est loch in kop...

Microformats have always pissed me off as being pointless code bloat and scam artist shmendrik; sooner or later you have to let the content do it's job or we'll end up within a decade having idiocy like new tags in HTML 6 for VERB, NOUN, PRONOUN, etc... (which admittedly with the halfwit idiotic HTML 5 article, section, nav, aside, header and footer crap, we're already halfway there)

Pisses me off even more when they expect you to put the URL to their garbage rules on every blasted item; it's like they don't grasp what semantic markup, inheritance, or DOM structure is for, and just like the OOCSS and jQuery retards feel the need to 'throw classes at EVERYTHING' -- instead of classes they're using those stupid extra redundant attributes. Why you can't just say it once on the wrapping parent is ... well, really jacktarded code bloat.

The laugh being the number of site owners who go all meshugga about content theft, then dope their sites to the gills with this microdata crap that makes site scraper's jobs easier. Search engines have worked just fine for DECADES without any of this nonsense -- and adding this bekaptah kakamame drek just makes the web slower, sleazeball content theives lives easier, and basically throws semantic markup and content as the important part right out the window.

In many ways it just boils down to "why not just let semantic markup and the entire reason HTML even exists do their job?"

But again, if you don't see what's wrong with using 51k of markup and half a megabyte of scripting to deliver pages with single digit K of actual content on them -- we'll have to agree to disagree as we'll never see eye to eye on it.

Though - even if you wanted to keep the microdata crap, it doesn't explain all the classes, span and div for nothing

<ul class="breadcrumb">
	<li itemscope="itemscope" itemtype="http://data-vocabulary.org/Breadcrumb">
		<a href="//www.digitalpoint.com/" itemprop="url">
			<span itemprop="title">Home</span>
		</a>
	</li>
	<li itemscope="itemscope" itemtype="http://data-vocabulary.org/Breadcrumb">
		<a href="/" itemprop="url">
			<span itemprop="title">Forums</span>
		</a>
	</li>
	<li itemscope="itemscope" itemtype="http://data-vocabulary.org/Breadcrumb">
		<a href="/.#the-digital-point.1" itemprop="url">
			<span itemprop="title">The Digital Point</span>
		</a>
	</li>
	<li itemscope="itemscope" itemtype="http://data-vocabulary.org/Breadcrumb">
		<a href="/forums/general-chat.19/" itemprop="url">
			<span itemprop="title">General Chat</span>
		</a>
	</li>
</ul>

Code (markup):

STILL basically half the code retaining that pointless schema-bloat. ... and DAMN those inner span and massive URL for nothing to the schema source piss me off.

Oh, and rel="up" is supposed to be up one, not up four... NOT that I believe in using REL on anchors in the first place as it too isn't useful to the user -- and we're SUPPOSED to be coding for the user, not the engine; at least, unless you WANT to go knee deep into SEO scam artist shvantz-land.

NOT that 'up' is a recognized REL to begin with -- but it's not like that's written in stone with the so called "specifications" being toothless and now thanks to HTML 5, not even bothering to be authoritative. Still though -- it's part of why things like REL on anchors and the various 'itemscope' type schema crap leaves me wondering "do the people behind this even understand what HTML is or how to use it?!?"