forum web page is stalling with "waiting for www.suse.com"...

I don’t know when this started, but since quite some months I do experience performance issues when browsing the openSUSE forum.
More precisely, my Google Chrome browser [Version 60.0.3112.113 (Official Build) (64-bit)] stalls again and again with the following message
being visible in the browsers status bar: “Waiting for www.suse.com”. The delay/stall takes about 30 s…

The DevTools of Chrome (invoked by hitting F12) shows the following message (again and again):

A Parser-blocking, cross site (i.e. different eTLD+1) script, https://www.suse.com/common/util/secure/userInfo.php, is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message.See https://www.chromestatus.com/feature/5718547946799104 for more details.

Any idea what I could do to avoid this unpleasant delay?

This was reported also a few days ago in this thread https://forums.opensuse.org/showthread.php/527944-Browsing-the-forums-super-slow-due-to-php-file-from-www-suse-com

As I wrote at the time it wasn’t an issue I was seeing, and still don’t. (Possibly because I’m using the Firefox extension “NoScript” which blocks cross-site scripting).

There didn’t appear to be a resolution other than, as the OP wrote, to block that particular *.php file (comment #4).

When I am using Firefox 52.4.0, I don’t experience any delay either (with no add-ons nor extensions installed).

Google Chrome however seems to block DOM-based XSS since version 53. As this seems to be done for good reasons,
I am wondering if the forums web page shouldn’t get rid of this technique sooner or later.

I found some more insight into that problem here: https://developers.google.com/web/updates/2016/08/removing-document-write

Just saw this again (and yes, I observe this quite frequently and it is​ annoying).

I concur, I had to go back to blocking the .php AGAIN.

If the forums still work with that blocked, which evidently they do, then I wonder why it’s needed?

@Miuku

In the thread you opened previously you wrote

It’s rather weird - I wonder what it even does.

If one actually browses to https://www.suse.com/common/util/secure/userInfo.php it returns the following: (heavily redacted!)

var WEBIDSYNCHID="";

var FIRSTNAME="";
var MIDDLENAME="";
var LASTNAME="";
var PHONENUMBER="";
var EMAIL="";
var ADDRESS1="";
var ADDRESS2="";
var ADDRESS3="";
var CITY="";
var STATE="";
var ZIP="";
var COUNTRY="";
var COMPANY="";

var ENTITLEMENTS ="";

var isLoggedIn = true;

var holy_moly = 'no';

function crossAuthenticate() {
    if(typeof isTest == "undefined") {
        var isTest = false;
    }
    if(typeof isStage == "undefined") {
        var isStage = false;
    }
    var randomNum = Math.floor((Math.random()*100)+1);
    var authImage_novell = new Image();
    authImage_novell.src = "https://secure-www" + ((isTest) ? "test.provo" : ((isStage) ? "stage.provo" : "")) + ".novell.com/common/util/secure/pixel.png?r="+randomNum;
    var authImage_suse = new Image();
    authImage_suse.src = "https://www" + ((isTest) ? "test" : ((isStage) ? "stage" : "")) + ".partnernetprogram.com/common/util/secure/pixel.png?r="+randomNum;
    var authImage_netiq = new Image();
    authImage_netiq.src = "https://www" + ((isTest) ? "test" : ((isStage) ? "stage" : "")) + ".netiq.com/common/util/secure/pixel.png?r="+randomNum;
}
if(isLoggedIn) {
    crossAuthenticate();
}

var holy_moly = ‘no’; should clearly be var holy_moly = ‘yes’; in my case :wink:

That being said, forums work fine without it.