NotHereToPlayGames

Googletagmanager is obviously blocked, surprised I haven't been blocking cdnjs.cloudflare. Correction - I am blocking cloudflare but via uMatrix so that's why Proxomitron's log still shows it. I'm showing 1,860,754 bytes of javascript for the web page we are reading right now. 1.86 megabytes. Could be worse, I don't have Facebook or I'd see how many of megabytes we have there.

"Ay, there's the rub." Look at this very MSFN page. Take your shoes off and borrow the hands and feet of another person, you'll need that many "digits" to count how many scripts exist for even this page!

If I recall correctly, the only reason we even have multi-process is because of Spectre and Meltdown.

That isn't HTML. It's not intended for a web browser. Use an RSS Feed reader and you should be fine.

No offense, but ANYBODY that is concientious of "privacy rights" would NEVER have been on Facebook to begin with!

https://en.wikipedia.org/wiki/Planned_obsolescence

What are you spoofing the user agent to? If you are spoofing it to anything NEWER than Chrome v86, then of course Facebook is going to serve a version that needs a much newer computer/browser to render. And since you don't want the MOBILE version being served, then my hunch is that you need an OLDER user agent. What happens if you spoof Chrome v49 on XP? What happens if you spoof Chrome v49 on Win7? At any rate, spoofing a NEW browser or a NEW operating system should only make matters WORSE as far as what Facebook's servers assume you can render.

Web sites are not "developed for multi process" browsers or not. There is no header that the client-end tells the server-end how many processors the client has. There is no "serve this version" for single-process, "serve that version" for multi-process. The closest would probably be mobile layout versus desktop/laptop layout. But that's more of a horizontal resolution issue than a processor-count issue (mobile phones are all single-processor, to the best of my knowledge).

Twitter and Facebook are blocked at the router-leve here. I have no use for them and I block them completely. Not sure what you mean by "perform a test". I use Proxomitron and view web pages source code via Proxomitron "debug". If the word "opensearch" exists in the web pages source code, then my above userscript will prevent that "opensearch" from adding a search engine to your custum search engine list.

Many around here use HTML5 but it also places browsers pretty much in the EXACT SAME ORDER as Speedometer. 360Chrome scoring HIGHER than Serpent 52. Serpent 52 scoring HIGHER than New Moon 28. Again, I want a "number". Not some Placebo Effect "gut feeling".

So how do you guys compare one browser to the next as far as performance? I do not like "gut feelings", I want a "number". Yes, I agree, step one is open up your most used web sites and check a "yes" or "no" for that browser on if those web sites even "work" or not. But what about step two? Without it being "gut feeling". I've always maintained that browser selection is always boiled down to PERSONAL PREFERENCE. But how would you guys propose something for a quantifiable MEASUREMENT on PERFORMANCE?

Speedometer is a "snapshot" based on CURRENT network conditions. I wouldn't expect them to score identically week after week. HOWEVER, I have always always always had it place slowest to fastest in the IDENTICAL ORDER week after week when they are tested within minutes of each other - THAT order is VERY important to me, I like to "squeeze the turnip". My LAN at work is the ONLY network I've ever had any browser score over 300. My brother has had a Mac score over 400 (but I have no use for Mac "computers").

Chrome browsers use your Operating System's "certificate store" - there are pros and cons to this. Firefox browsers use a "certificate store" independent of the Operating System - there are pros and cons to this also.

I definitely don't doubt that. Technically, I have ZERO use for St52 outside of one and only one tab (text messages throughout the day). NONE of Roytam's offerings outperform 360Chrome - be it my real use cases or be it artificial benchmarks, they both walk hand in hand here, I've never witnessed real use cases indicate anything different than artificial benchmarks.

Of course it does! "It's all relative." And you can not compare REAL v86 to backport v86 in XP, now can you? Backport v86 is "faster" than REAL v86 in Win10 and in Win7 - my point was that you cannot blanket-statement backports as "inefficient". Inefficient is another way of saying "slower". One of the laptops is triple-boot - XP, 7, and 10. Backport v86 on same hardware and on same network is FASTER than real v86. But no, you cannot test real v86 in XP, we all already know that. Feel free to test on your hardware, backported v86 is FASTER than real v86 - and I'm quite confident that it is for everyone, "not just me".. On XP x64 - Backport v86 scores 75.04. Serpent 52 scores 36.5. New Moon 28 scores 37.7. Next I suppose you'll probably want to see "real" Firefox 52 and "real" Firefox 28 - but I don't have them and I leave that to those that are interested in the results.

Please show that address resolving in any other browser - ie, prove that you don't have access to Google blocked globally. Disable any and ALL antivirus and firewall and "security" programs to at least rule them out.

For one, type a REAL address into the address bar. Typing these FAKE addresses (here and Humming Owl thread) into the address bar is almost like you WANT the browser to "not work".

YES.

YES, it works on XP x64. You have done something wrong as you can't get this or Humming Owl's versions to work.

Since this thread has been revived and I missed it the first time around. I use the below to prevent custom search engines from being added - // ==UserScript== // @name - Disable OpenSearch // @version 2.0.1 // @include http*://* // @run-at document-start // ==/UserScript== //document.querySelector('[type="application/opensearchdescription+xml"]').remove(); ////////////////////////////////////////////////////////////////////////////// // Code from https://github.com/gregsadetsky/chrome-dont-add-custom-search-engines/blob/master/src/content.js // OpenSearch - e.g., https://martin-thoma.com/search-engine-autodiscovery/ // Uses CSS4 selectors, Chrome 49+ const DEBUG=false; let numseen=0, numspoiled=0; let unspoiled=[]; // called when the user clicks an element of the form (any field or button). // The parameter passed is the event object. function clickApply(e) { if(DEBUG) console.info({'form onclick':e}); // remove onclick. One fix only e.srcElement.form.removeEventListener("click", clickApply); applyFix(e.srcElement.form); } //clickApply // add a new <textarea> element function applyFix(elem) { var newelem = document.createElement('textarea'); newelem.name = ''; newelem.style.display='none'; elem.appendChild(newelem); } //applyFix // Add an extra child input to any form that only has one function spoilFormGet(elem) { if(DEBUG) { ++numseen; unspoiled.push(elem); } // Check whether the form submits to a HTTP(S) URL. // A missing or relative action will be resolved against the page URL // so it must have the same URI scheme which is all we care about var action = elem.getAttribute('action'); if(!(action && action.indexOf('://') >= 0)) action = location.href; if(!/^https?:\/\//i.test(action)) return; // Autodetection requires exactly one input of type text or search // If the type attribute is missing, it defaults to `text` // Readonly inputs do not count against this total if(elem.querySelectorAll(':scope input:-webkit-any([type="text" i],[type="search" i],[type*="search" i],[type=""],:not([type])):not([readonly])[name]:not([name=""])').length !== 1) return; // Autodetection also requires no password, file, or textarea elements if(elem.querySelector(':scope :-webkit-any(input[type="password" i],input[type="file" i],textarea)')) return; // Add a <textarea> - unlike <input>, it doesn't block implicit submission // per https://www.tjvantoll.com/2013/01/01/enter-should-submit-forms-stop-messing-with-that/ // apply the fix now, or place it in onclick. "this" is a parameter passed by foreach(). see below if (this.now === true) { // remove onclick placed during first pass elem.removeEventListener("click", clickApply); // and instead do it now; applyFix(elem); } else { elem.addEventListener('click', clickApply); } if(DEBUG) { console.info({Spoiled: elem}); ++numspoiled; unspoiled.pop(); } } //spoilFormGet var debugAutoDetect=0; // move this part of the code here, since it's called multiple times function autoDetect(now, when_called) { if(DEBUG) console.log('autoDetect: '+(++debugAutoDetect)+' ('+when_called+')'); document.querySelectorAll('form:-webkit-any([method="get" i],:not([method]))').forEach(spoilFormGet,{now}); if(DEBUG) { console.log(`Spoiled ${numspoiled}/${numseen}.`+(unspoiled.length?' Unspoiled were:':'') ); if (unspoiled.length) console.log(unspoiled); } // we reset spoil vars for next call numseen=0; numspoiled=0; unspoiled=[]; } //autoDetect function catchOpenSearch() { if(DEBUG) console.info('catchOpenSearch called'); // OpenSearch - e.g., https://martin-thoma.com/search-engine-autodiscovery/ // Uses CSS4 selectors, Chrome 49+ document.querySelectorAll('[type="application/opensearchdescription+xml" i]').forEach( function (it) { it.removeAttribute('type'); if(DEBUG) console.info({"Spoiled by type removal": it}); } ); // Suggestion service, https://www.chromium.org/tab-to-search document.querySelectorAll('url[rel="suggestions" i]').forEach( function (it) { it.removeAttribute('rel'); if(DEBUG) console.info({"Spoiled by rel removal": it}); } ); // added document.querySelectorAll('url[rel="search" i]').forEach( function (it) { it.removeAttribute('rel'); if(DEBUG) console.info({"Spoiled by rel removal": it}); } ); } //catchOpenSearch function onDOMContentLoaded() { if(DEBUG) console.log('onDOMContentLoaded'); catchOpenSearch(); // #1 call it now (i.e., DOMContentLoaded) without applying the fix // #2 call it in 1500 ms and apply the fix // #3 call when document loaded, and apply the fix. // if <form> is added/modified // dynamically before the document // is fully loaded, #1 could miss it, but not #2 & #3. Note that #2 // could fire after #3 if the page is fast to load. Once the fix // is applied, the <form> can't be found by subsequent execution // of autoDetect, so the fix can only be applied once (#1 is not // applied but delayed until #2 or #3 fires, or if the user // clicks). window.addEventListener('load', function() { if(DEBUG) console.log('onload'); catchOpenSearch(); autoDetect(true,'Load'); } ); // #3 setTimeout(function() { autoDetect(true,'Timer'); } ,1500); // #2 autoDetect(false,'onClick'); // #1 } //onDOMContentLoaded (function() { document.addEventListener('DOMContentLoaded', onDOMContentLoaded); onDOMContentLoaded(); })();

I technically don't define it as "based on" anything. It's more of a hodge-podge conglamerate. Theoretically, yeah, I suppose it "started" with Fx52. But... St52 can do nullish coalescing operator, something Firefox couldn't do until v72 - https://caniuse.com/?search=nullish St52 can do optional chaining, something Firefox couldn't do until v74 - https://caniuse.com/?search=chaining St52 partially supports BigInt, something Firefox couldn't do until v68 - https://caniuse.com/?search=bigint The list is kind of endless. BUT there are also things that Firefox can do that St52 cannot do. And even more things that a Chrome-based can do that a Firefox-based cannot do. And vice versa, of course.

Agreed! Though I wouldn't call it all "inefficiencies". Not everyone here is a fan of Speedometer, but one must use some metric that is quantifiable and repeatable - for me, that's Speedometer. As a disclaimer, I am new to using St52 and I picked an older version for my own reasons, newer versions may score higher (but my experience is that they all fall within 5 to 10 points of each other). While 360Chrome v13.5 is a "backport" v86, it scores higher than "real" v86 (on my system, for other systems "mileage may vary"). Ungoogled v113 scores 320! "Real" v86 scores 149. "Backport" v86 scores 166. Serpent 52 scores an abysmal 62.6.

Technically, none of the 360Chrome versions are being "maintained". They have all hit FINAL release stage. Humming Owl no longer updates his versions and is much less of an active member as he once was, but he still does visit on occasion: