Here is the result from an approximately 15 second wait for one of GOG's pages to load. The attached images show 200 OK. I checked all the files (might_and_magic_9, website,false,?=1401924504471, etc) and all of them say 200 OK.

I can try Firebug if you want me to. But I'm not very familiar with it.

FYI The main page will always come back 200, and that is correct.

What we want to see 304's on are the images (and css, js files). If I'm understanding you correctly, you did check a bunch of the images files below, and they did come back as 200's correct?

If that is correct then the problem you are having is FF is not caching the images like it should be, and ends up redownloading everything every time you visit. Which is a lot of stuff, and would explain why it is taking so long. How you fix it is another issue.


Since you mentioned being the the about.config, check these items. I grabbed them from a old source, but I assume nothing would have changed for the entries

To ChrisSD and gooberking:
Just added these lines to ABE. Several GOG.com pages seem to be responding within 2 seconds now (for SOME pages, the first few files atop the Network window show a 301 Moved Permanently status code (not 304), while all other files show a 200 OK... then for the OTHER pages that were slow previously but now load fast, all files still show a 200 OK). This is a little confusing.

It is a little weird. All your load times looked way long, so I don't know how blocking one file improves things. Browsers load images after it builds the page, so maybe that item was keeping the initial load from completing by being a really slow download.

Regardless of that files guilt in the issue, it is abnormal for all images to be coming back 200 every time. Some, yes, but all is highly unusual unless something is wrong. Whatever that is could be causing the issue with the other file.

I'm having issues with the "Please wait. Processing..." again, so my posts are being delayed a little bit.
I read that this issue is related to quotes somehow, so I'll type this without quotes.

To gooberking:

Yes, I clicked on all the image files (including those jpg ones) and all came back as 200's.

Also... in About:Config (in Firefox), I just checked both "browser.cache.memory.enable" and "browser.cache.disk.enable". They were already true. What next?

Well, I would suggest researching cache settings, and make sure things haven't been disabled or run out of room. Do you have good disk space?

To start maybe go to Options -> Advanced -> Network, and then clear the cache. After that reload GOG, and then load it a second time before checking to see if you are still getting 200's

gooberking said:
It is a little weird. All your load times looked way long, so I don't know how blocking one file improves things. Browsers load images after it builds the page, so maybe that item was keeping the initial load from completing by being a really slow download.

Regardless of that files guilt in the issue, it is abnormal for all images to be coming back 200 every time. Some, yes, but all is highly unusual unless something is wrong. Whatever that is could be causing the issue with the other file.
-----------
Agreed.
It's also interesting that today I tried a brand new install of Pale Moon (which I've never tried before, but is a browser based on Firefox). All default settings were there, yet it displayed the same slow loading issues as Firefox.

In my last reply, I mentioned that in About:Config, those values were already set to true. Meaning the browser should already be caching. However, a while back I changed my Firefox Options > Privacy setting to never accept third party cookies. I tried changing it to Always yesterday (and both values were also TRUE) but this didn't help speed up GOG.com page loading in Firefox. Here's a snapshot of my current Firefox Options > Privacy setting.

If we can't find a solution soon, I'll just call it a day and thank you for your help.

Great news... I just set Firefox to accept all third-party cookies. With the combination of the ABE script and all third-party cookies being accepted, it seems that all of GOG.com's webpages load within 1-2 seconds now. Most files at the GOG.com home page now show 304's (first time I've seen 304's, btw) in Network Monitor. I've tried about 20 pages so far and all loaded within 1-2 seconds in Firefox.

I'm sure I couldn't have done this without your and gooberking's help. Kudos to you guys!

.. no need to confuse the issue now

No problem. I gave +1 to all your and ChrisSD's replies.

For me too, when I load gog ff goes to not responding for a while.

It could be due to a number of different things, depending how everything in your computer (including browser) is set up. You can try what I did in this thread and see if it works for you, if it's only GOG you're having issues with in Firefox.

To express my gratitude to those who helped me in this thread and to hopefully help others with similar issues, here are some screenshots from Network Monitor relating to the Might and Magic 9 page at GOG.com to show a before/after comparison.

Look at the circles on the left side. If they are green, they're uncached (200 OK). If they are brown, they're cached (304).

gogspeedresult3.jpg = from earlier before fixing issue. Notice the black circle. The ABE script removed it
gogspeedresult6(uncached).jpg = first visit after fixing issue, without restarting browser or any other action
gogspeedresult7(cached).jpg = second visit (reloading same page), caching works. Half the circles are brown

From the other thread:
I gave the current version of Pale Moon a spin with the default settings and still had no loading issues. Not sure why it's giving you such troubles.

FYI, in NoScript options you can select up to full addresses to selectively block vs the ABE route.

Then the servant-1.gog.com issue probably isn't browser-related. TY for giving the current version of Pale Moon a spin. Sorry I'm not too familiar with ABE scripts via NoScript. Can you give me an example how full addresses can be selectively blocked via the ABE route?

Tomorow I plan to post an updated summary of findings related to a couple of things in this thread.