Instead of using an ABE script.

Got it - however, I didn't see an option to selectively block servant-1.gog.com even after temporarily disabling ABE (which had the script to deny servant-1.gog.com)

Now here's the update...

I went back and worked through a few things carefully. I re-tested with ABE enabled and accept third-party cookies set to "Never", to confirm that cookies aren't somehow transmitting info that can impact cache behavior. Well, all GOG pages loaded in under 2 seconds. The ABE script suggested by ChrisSD was the only thing required for the loading issue to go away. Forget cookies (yes, I know they're different from cache).

That was a good observation earlier by gooberking. I use Avast Free Antivirus and Online Armor, two programs that monitor online traffic. Disabling Avast and closing OA caused all cached page response times to drop from the 500-1000ms range to 31-87ms. Even non-cached pages are usually in double digits now.

Lower response time but at a security tradeoff.

Just out of curiosity, I tested **with ABE disabled** to see if servant-1.gog.com (which is causing me the page loading issues in Firefox, not Chrome) would still pose an issue with Avast disabled and OA closed. Unfortunately, servant-1.gog.com is STILL an issue. See screenshot. I know the issue's been fixed with ABE scripting, but I'd still like to ask...

Disabling all Firefox add-ons, plus having all firewalls and network monitoring software disabled has no effect on servant-1.gog.com. What could cause servant-1.gog.com to not load?

I'm impressed with your investigative skills!

I'm on my tablet atm so I can't I investigate your question just yet but here's what I remember. Pages on servant-1.gog.com aren't meant to load in the traditional sense, it's supposed to be started in the background and then keep a connection to GOG open. This open connection can be used by GOG to send your browser messages whenever it wants without having to reload the page or keep asking GOG if there are any new messages.

I'm not sure what GOG uses it for but it could be used to notify you of new private messages or new game updates even if you stay on the same page for a while.

So this thing that is meant to run in the background isn't and instead is holding up the page load. Why is it doing this? I don't know. It's probably an issue with GOG's code that doesn't take account of one loading issue or another (perhaps something else is loading too slow or too fast, I don't know).

I might try and investigate tomorrow but I'm not having the same issue as you so I might not find out anything useful!

+1!

I am also investigating this in the meantime, but might not find anything either. It's like a fun project. :)

You likely needed to forbid gog.com first.

Good idea to tackle this from my end too. Will look into it.

Tried that just now. Forbidding gog.com in NoScript is another way of disabling JavaScript (which I tried with YesScript add-on at the beginning of this thread) and breaks some functionality of the GOG website although the pages start loading in <2 sec (instead of 10-30 sec). It appears that servant-1.gog.com will not process unless gog.com is allowed, which can account for the faster page loading times when gog.com is forbidden.

That could be why forbidding gog.com (with ABE scripts disabled) didn't cause servant-1.gog.com to show up on the NoScript list after loading a few different pages. Was worth a try anyway. See screenshot.

No, right. I should have been explicit. I meant for you to forbid gog.com and then allow www.gog.com. At which point it may take a few minutes or wandering around the forum before servant-1 shows up. Given you are already blocking it with the ABE script it's a minor thing anyway.

Ah I see. No worries due to the ABE script, but thanks for the idea!

I followed your instructions and found some interesting things, but not sure if the info will be useful. I used a network diagnosis tool called Fiddler (credit goes to gooberking for telling me about it via PM). See the image called console.jpg. In the console, Fiddler shows that there is a 504 error with nearly each instance of servant-1.gog.com. 504 errors are Gateway Timeout Errors.

In the screenshot, I'm coming from Baldur's Gate page. The target page is Planescape Torment. The servant-1.gog.com line (with the first black x) immediately following the target page url is associated with the page I'm coming from (not the target page), as indicated by Properties (not shown). This is where the console stops for 10-30 seconds due to loading issue before showing more lines.

The three remaining servant-1.gog.com pages (at bottom of screenshot) are associated with the target page. Every 2 minutes afterwards, servant-1.gog.com repeats via a loop (possibly checking for new messages, etc). With Fiddler running in the background, servant-1.gog.com is shown to have Receive Failure issues.

I've attached two more screenshots (from Fiddler). Maybe there's something that shows why servant-1.gog.com is having Receive Failure issues. You (and others) could try the free Fiddler program (if you want or have time) and see how your results differ from mine. Or just inform me if you uncover anything interesting from the images.

504 error in this case is the expected result. If you sit with a GOG page open and watch fiddler for a few minutes, you should see the connection closing and then a new one opening. Basically it keeps a connection open until it receives a message from GOG or until the connection timesout (after 2 or 3 minutes). Then when that connection is closed it opens a new one.

In fiddler, if you right click the column headers you can "Customize Columns" and then add Session Timers this might be made clearer. ClientBeginRequest, ClientDoneResponse and Overall_Elapsed might be the most interesting columns.

As I mentioned before servant-1.gog.com is used by gog to keep an open connection that can be used to send messages to the user. Even though it's opened for every page, as far as I can make out it's only actually used in two places.

1. On the messages page to notify you if the other user is typing.
2. On your shelf page if you use the Downloader.

So blocking servant-1.gog.com might mean the Downloader doesn't work (which is interesting because other people have mentioned similar issues with the Downloader).

Yeah, well... it looks like we've done everything we can up to this point. I tested the GOG Downloader with the ABE script enabled. Everything works just fine. Very snappy and responsive thanks to the ABE script you provided earlier. Also, everything works perfectly with the ABE script enabled. I get message notifications (while on the same page I think, but will have to check this later), Downloader works, etc. I got the results I want.

If others are experiencing issues with the Downloader, maybe pressing Ctrl + Shift + Del in Firefox to clear cache, cookies, active logins will help. The Downloader wasn't working at all for several minutes with ABE script enabled but clearing those things seemed to fix things right away.

Still stratching my head as to why servant-1.gog.com causes a hanging issue for me on Firefox and a current version of Pale Moon (never before used, w/ default settings and no add-ons) when it works for everyone else and for me in other browsers. But thanks for helping me. +1 to all your posts.

Yeah I suspect we'd have to deep dive into the javascript code to get any further. The only other thing I can think of is that some security software somewhere doesn't like the way Firefox handles sevant-1 for some reason. But I think you tried disabling stuff already? So yeah, no idea. :)

Yup I think your suspicions are correct. There is one more thing I suspect... it could have to do with plugins (different from extensions), which I haven't really looked at yet. I noticed just now that plugins weren't disabled in Firefox's Safe Mode, unlike extensions. Anyway, for others' benefit, wanted to point out one more thing about GOG Downloader.

If someone keeps a network diagnosis tool like Fiddler running in the background, it can prevent GOG Downloader from working properly. I tested this 3x and noted this: If Fiddler is running in background, downloading a game will not get past the "Initializing..." stage in the Downloader. But the very second that Fiddler is closed, the download resumes normally. Verified 3x without fail.

So if others have issues with the Downloader it might be worth asking about any network diagnosis or monitoring tool that might be running in the background too.