Solved Google Sites slow to load, 15s timeout

DarthRaptor

Hello,
This is probably a very weird problem, but my Vivaldi install on my PC is experiencing a very weird behavior with Google sites. Any time I try to open a Google search site, it takes at least 15s for the sideload to work.

As you can see in the network inspector screenshot it's reproducible and it's always nearly the same 15.5s (which makes me thing of a timeout somewhere).

I can not reproduce this on my other PCs running Vivaldi, but I was able to reproduce it with a new profile on the PC having the problem. I have not yet deleted my profile and re-synced everything to see if that fixes the profile, due to the pain of all the mails being lost on that.

Does anyone have an idea what this could be?

System:
Vivaldi 7.0.3495.10 (Stable channel) (64-bit)
Revision 46177f82db4977c295fe8a3bdecb6a552df0838d
OS Windows 10 Version 22H2 (Build 19045.5011)
JavaScript V8 13.0.245.18

I am running a pi-hole and a firewall, but the issue is reproducible with both of them disabled, and my other systems with the same setup don't show this behavior

Pathduck

@DarthRaptor I had a look but I'm no expert on parsing these logs unfortunately. What I can tell is the QUIC/HTTP3 connection reply takes 15 seconds - the 6661: QUIC_SESSION:

t= 1673 [st=   72]    QUIC_SESSION_PACKET_SENT
                      --> batch_id = 0
                      --> encryption_level = "ENCRYPTION_FORWARD_SECURE"
                      --> packet_number = 12
                      --> sent_time_us = 770772406457
                      --> size = 31
                      --> transmission_type = "NOT_RETRANSMISSION"
t=16616 [st=15015]    QUIC_SESSION_PING_FRAME_SENT

The value for "Reduced Ping Timeout In Seconds" under QUIC is 15 seconds.
No idea what that means in practice.

I know QUIC uses UDP so that might be a clue.

There is a flag you can try disabling:
chrome://flags/#enable-quic

You're also using several extensions according to the Modules page including Ghostery. I strongly urge you do all testing in a clean profile to exclude extensions and changed settings.

I also note you're not running Ghostery in Chrome.

DoctorG

@DarthRaptor Please try the troubleshooting steps, including testing in a clean profile and disabling adblocking/extensions:
https://help.vivaldi.com/desktop/troubleshoot/troubleshooting-issues/

Slowdown can be caused by:

connection (Ethernet, WiFi, Mobile)
router (filter, DNS)
Internet Service Provider (filtering, surveillance)
broken Windows DNS settings
use of VPN or Proxy
external security tool (Antivirus, Internet Security)
a extension in Vivaldi

Welcome in our Vivaldi Community

Do not hesitate to ask, we are a community to help users.

Enjoy browsing with Vivaldi.

DarthRaptor

I am sorry, I should have mentioned in the post, I already tried all of those trouble shooting steps.

In fact I just now uninstalled Vivaldi and restarted with a clean installation and I was still able to reproduce the issue.

It's not network, firewall, antivirus (or pi-hole) issue because none of the other 3 browsers installed on my system, nor any of my other systems exhibit the issue. (And disabling each of these did not make a difference)

It's not a profile or extension issue since I can reproduce it with a clean profile without extensions. Also this profile is synced to 3 other PCs and they do not have this issue

Is there some logs I could analyze?

Pathduck

@DarthRaptor said in Google Sites slow to load, 15s timeout:

Is there some logs I could analyze?

Yes, you can capture a network log using:
chrome://net-export
And analyze it in the linked netlog-viewer.

The Net-internals pages might also give some info:
chrome://net-internals/#dns
chrome://net-internals/#proxy

Note: The netlog will log a lot - so make sure you only launch a single tab, and also wait a minute or two after browser launch to make sure any component update connections are finished before starting the log.

Then do the same checks in other Chromium browsers and compare.

Does anyone have an idea what this could be?
I am running a pi-hole and a firewall

Yes - that

Also, since this is probably a socket connection issue, the netlog might not show much useful. Once a socket is made, the TCP socket connection handling is done purely on the OS level, so if there's a "timeout" or slowdown, that's where the problem lies.

DarthRaptor

I've created network logs both using Vivaldi and Chrome. I can see the 15s it takes for the network request to complete, but nothing obvious as to the problem. It almost feels server side. Why would it only be for Google.com, Google.de, etc... but not other Google sites like drive.google.com, sheets.google.com etc... and why only for this specific browser install on this specific PC?

None of my other browsers on my other PCs show any trouble. As mentioned before I've tried running without my pi-hole (removed the pi-hole from the DNS settings to ensure it is not involved), deactivated my firewall and antivirus, no change

Filebin.net - Network Logs

Edit: Another point of note. Once the page has loaded, it will load fast if I refresh. I always have to wait a minute or two to reproduce the issue

Pathduck

@DarthRaptor I had a look but I'm no expert on parsing these logs unfortunately. What I can tell is the QUIC/HTTP3 connection reply takes 15 seconds - the 6661: QUIC_SESSION:

t= 1673 [st=   72]    QUIC_SESSION_PACKET_SENT
                      --> batch_id = 0
                      --> encryption_level = "ENCRYPTION_FORWARD_SECURE"
                      --> packet_number = 12
                      --> sent_time_us = 770772406457
                      --> size = 31
                      --> transmission_type = "NOT_RETRANSMISSION"
t=16616 [st=15015]    QUIC_SESSION_PING_FRAME_SENT

The value for "Reduced Ping Timeout In Seconds" under QUIC is 15 seconds.
No idea what that means in practice.

I know QUIC uses UDP so that might be a clue.

There is a flag you can try disabling:
chrome://flags/#enable-quic

You're also using several extensions according to the Modules page including Ghostery. I strongly urge you do all testing in a clean profile to exclude extensions and changed settings.

I also note you're not running Ghostery in Chrome.

DarthRaptor

Disabling QUIC fixed the issue, thank you a lot.

As mentioned before, I did test all of this without extensions and a clean profile

Pathduck

@DarthRaptor That's great

Now of course, the question remains why Chrome worked just fine with QUIC. Then again, QUIC was invented by Google and is used (mostly) on their servers...

I do notice in your netlog for Chrome it has under Active Field Trial Groups:
QUIC:ReportEcnOct2024
Absolutely no idea what that is, and a search brings up zero. Would not surprise me in the least if Chrome is "cheating" in some way. Vivaldi of course, has all the Google Field Trials disabled as they don't want Vivaldi's users to be victims of Google's whims.

What would be interesting is if the same happens in other Chromium browsers, like Chromium itself, Opera, Brave, Edge etc as they may not have these Field Trials enabled (at least not Brave).

Also of note, is that network and security admins loathe QUIC as it needlessly complicates troubleshooting with its complexity and moves a lot of networking stuff from the network layer onto the application layer, making it for instance much harder to decrypt and scan TLS traffic, very important in an enterprise network.