Slow first page loads on Chrome

 I was experiencing frequent - but seemingly random - slow page loads on opening new sites in Chrome. The wait was up to 10 seconds, but a refresh mid-wait appeared to cause it to load quickly.

Copilot gave the following explanation. 

The chrome://net-internals/#dns and clear net cache seemed to yield good results, but time will tell.

What you’re describing — first navigation in a new tab taking ~10s, then a refresh becoming fast (even during the wait) — can be DNS-related, but it’s often not “basic DNS resolution”. It’s usually one of: 

• Chrome’s own host-resolution behavior (async resolver / internal cache / DoH) behaving differently to your terminal tools 

• Connection establishment delays (TCP/TLS/HTTP3/QUIC, certificate validation/OCSP/CRL, proxy/PAC, AV inspection) 

• Happy Eyeballs / IPv6 fallback weirdness 

• Chrome preconnect / preloading / service-worker / HSTS interactions that make “refresh” take a different (faster) path 

Below is a practical way to narrow it down. 

 

1) Is it DNS? (And yes: Chrome can behave differently than Terminal) 

Chrome does not always behave like nslookup 

• nslookup queries DNS servers directly and reports what it gets back; it doesn’t necessarily mimic how applications resolve names. 

• Chrome/Chromium has its own host resolution stack (including caching and support for different resolution sources) rather than being a thin wrapper around the OS resolver. Chromium’s own docs describe Chrome’s host resolution implementation, including DNS/host caching and interaction with system settings. 1 

• Chrome also maintains a separate DNS/host cache that you can inspect and flush independently. 2 

Chrome may use Secure DNS (DoH) depending on settings/policy 

Chrome has a “Use secure DNS” setting that can cause Chrome to use DNS-over-HTTPS (or opportunistically upgrade to it), which can differ from what your OS / terminal uses. 3 

So yes: Chrome can use a different mechanism/caching/transport than nslookup, and you can see “DNS is instant” in terminal while Chrome still stalls for reasons that look DNS-ish. 

 

2) Why “refresh” is fast even during the wait 

A refresh being fast strongly suggests the slow part is something that becomes satisfied/cached/unstuck after the first attempt starts: 

• DNS answer cached (browser cache, OS cache, router cache) 

• TCP/TLS handshake completes and is then reused (keep-alive / session resumption) 

• QUIC/HTTP3 path negotiation completes (subsequent request reuses state) 

• Certificate validation or revocation check completes (OCSP/CRL) 

• Proxy auto-detection (PAC / WPAD) finishes 

• Extension/AV scanning delays only the first request 

Chrome DevTools “Initial connection” time includes time to establish the connection (TCP) and negotiate TLS where applicable. 4 

 

3) A focused diagnostic flow (quick to do, high signal) 

Step A — Use Chrome’s own network/DNS diagnostics 

1. Open: chrome://net-internals/#dns (or in newer Chrome, use NetLog export via chrome://net-export) 

2. Click Clear host cache 

3. Try loading a site that shows the 10s delay 

4. Re-open the page and inspect whether host entries appear / how they change 

Chromium maintains its own host resolution stack and tooling around it. 5 

What you’re looking for: 

• Do you see slow resolution attempts? 

• Are there repeated failed queries followed by success? 

• Does it prefer IPv6 first then fallback? 

If you want the most precise view: create a NetLog (chrome://net-export), reproduce the issue once, then stop logging. The NetLog will show whether the delay is DNS, proxy resolution, TLS handshake, QUIC, etc. 

 

Step B — Check whether it’s Secure DNS / DoH related 

Go to: Chrome Settings → Privacy and security → Security → “Use secure DNS” 

• Toggle it off temporarily, or set it to a known provider explicitly. This setting controls Chrome’s DoH behavior. 6 

Then reproduce the issue. 

If disabling Secure DNS fixes it, the problem could be: 

• DoH endpoint latency/reachability 

• middlebox interference 

• IPv6/IPv4 path differences to the DoH resolver 

 

Step C — Rule out proxy auto-detection (a classic “first request takes ~10s” cause) 

This is very common on Windows and sometimes macOS in managed environments: 

• Windows: Settings → Network → Proxy → “Automatically detect settings” 

• Also check whether a PAC script is configured. 

Proxy/WPAD delays often show up exactly like “first request after opening browser/tab is slow”. 

 

Step D — Check IPv6 vs IPv4 weirdness 

Even with fast internet, a broken/partial IPv6 path can cause a stall until fallback occurs. 

Test quickly: 

• In terminal, resolve both A and AAAA: 

• nslookup -type=A example.com 

• nslookup -type=AAAA example.com 

• If AAAA exists, try temporarily disabling IPv6 on your adapter (for a test), or test a browser that you know prefers different behavior. 

If disabling IPv6 makes it disappear → it’s not “DNS speed”, it’s “first connection attempt over IPv6 stalls”. 

 

Step E — QUIC / HTTP3 negotiation 

Chrome may attempt HTTP/3 (QUIC) first on some sites; if your network blocks/impairs UDP/443, you can see delays before fallback. 

Quick test: 

• Go to chrome://flags and temporarily disable Experimental QUIC protocol (or equivalent flag if present), relaunch, retry. 

If fixed: your router/firewall/ISP path may be interfering with UDP/443 or QUIC. 

 

Step F — Certificate validation / OCSP / security software 

Another common “10s on first connect” culprit: 

• OCSP/CRL checks stalling 

• Antivirus “HTTPS scanning” / corporate TLS interception 

• Extension doing blocking work on first navigation 

Chrome’s own help guidance explicitly calls out that firewall/antivirus and extensions can cause connection/loading issues. 7 

Quick isolation: 

• Try Incognito (extensions often disabled) 

• Or start Chrome with all extensions disabled 

• Temporarily disable “HTTPS scanning” in AV (if you have it) just to test 

If Incognito is fine → extension is likely involved. 

 

4) How to tell exactly what part is slow (DNS vs TLS vs server) 

Use DevTools Network timings 

Open DevTools → Network → load a site → click the first request → Timing tab. 

If the delay is mostly: 

• “DNS Lookup” → name resolution/DoH/system resolver interactions 

• “Initial connection / SSL” → TCP/TLS handshake, packet loss, inspection, certificate validation 

• “Waiting (TTFB)” → server/app delay (less likely if it happens across many unrelated sites) 

Remember: “Initial connection” is handshake setup and (where applicable) SSL/TLS negotiation. 8 

 

5) Why your 1.6Gbps speed doesn’t rule this out 

Bandwidth ≠ latency. These 10s stalls are typically: 

• a timeout/fallback interval 

• a blocked protocol (UDP/443, IPv6) 

• a proxy discovery timeout 

• a security product doing synchronous inspection 

They can happen on a gigabit link just as easily. 

 

6) Most likely culprits given your symptoms (ranked) 

Based on “first request slow; refresh fast; nslookup instant”: 

1. Proxy auto-detect / PAC delay (especially on Windows, corporate setups) 

2. IPv6 first attempt stalls then fallback to IPv4 

3. Secure DNS / DoH path issue (Chrome differs from terminal) 9 10 

4. QUIC/HTTP3 attempt blocked → fallback 

5. AV/Firewall HTTPS inspection or an extension 11 

6. Certificate revocation checks stalling (OCSP/CRL) 

 

7) Two super-quick “tell me the answer” tests 

If you want the fastest route to a root cause, do these two: 

Test 1 — Disable Secure DNS in Chrome (1 minute) 

Settings → Privacy & security → Security → Use secure DNS → Off 12 
Retry. 

Test 2 — Disable proxy auto-detect (1 minute) 

Disable “Automatically detect settings” (Windows proxy settings) 
Retry. 

If either fixes it, you’ve basically found the class of issue. 

 

A couple of questions (so I can narrow it to one or two likely causes) 

1. What OS are you on (Windows 11 / macOS / Linux)? 

2. Does it happen on all sites (e.g., google.com, bbc.co.uk) or mostly new/less-visited sites? 

3. If you open the same URL in Edge (Chromium) or Firefox, do you see the same first-load stall? 

If you tell me those, I’ll suggest the most likely root cause and the shortest path to confirm it (and fix it). 

Flutter

dart run flutter_launcher_icons
flutter build apk --release 
adb install build/app/outputs/flutter-apk/app-release.apk

Creating a Shopify Web pixel

shopify app init

shopify app generate extension --template=web_pixel --name=my-webpixel

shopify app deploy

shopify app release

Once the app is installed on the store, it will be shown in Customer Events but disconnected.
You must run GraphQL to install it, USING THE CREDENTIALS FOR THE APP.

string shopDomain = "mystore.myshopify.com";
string apiVersion = "2025-10";                                      // use a current version
string clientId = "myclientId";										// In the Dev Dashboard
string clientSecret = "myClientSecret";

// gid://shopify/WebPixel/3094610295

string query = @"
mutation CreateWebPixel($settings: JSON!) {
  webPixelCreate(webPixel: { settings: $settings }) {
    userErrors { code field message }
    webPixel { id settings }
  }
}";

public async Task Main()
{
	var variables = new { settings = "{\"accountID\":\"123\"}" };
	var payload = new { query, variables };
	var json = JsonSerializer.Serialize(payload);

	try
	{
		var cache = new MemoryCache(new MemoryCacheOptions());
		var services = new ServiceCollection()
					.AddHttpClient()                    // registers IHttpClientFactory and the default plumbing
					.BuildServiceProvider();

		var factory = services.GetRequiredService<IHttpClientFactory>();

		var client = factory.CreateClient("shopify");
		var tokenService = new ShopifyTokenService(client, cache, shopDomain, clientId, clientSecret);

		client.BaseAddress = new Uri($"https://{shopDomain}/admin/api/2025-04/graphql.json");
		client.DefaultRequestHeaders.Add("X-Shopify-Access-Token", await tokenService.GetTokenAsync());
		client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
		var content = new StringContent(json, Encoding.UTF8, "application/json");

		var response = await client.PostAsync("", content);
		var responseString = await response.Content.ReadAsStringAsync();
		Console.WriteLine(response.StatusCode);
		Console.WriteLine(responseString);
	}
	catch (Exception error)
	{
		while (error != null)
		{
			Console.WriteLine(error.Message);
			error = error.InnerException;
		}
	}
}

public sealed class ShopifyTokenService
{
	private readonly HttpClient httpClient;
	private readonly IMemoryCache cache;
	private readonly string shopDomain;
	private readonly string clientId;
	private readonly string clientSecret;
	private readonly int fallbackTtl = 30;
	private static readonly string cacheKey = "shopify_admin_token";

	public ShopifyTokenService(HttpClient httpClient, IMemoryCache cache, string shopDomain, string clientId, string clientSecret)
	{
		this.httpClient = httpClient;
		this.cache = cache;
		this.shopDomain = shopDomain;
		this.clientId = clientId;
		this.clientSecret = clientSecret;
	}

	public async Task<string> GetTokenAsync()
	{
		if (cache.TryGetValue(cacheKey, out string token))
			return token;

		var endpoint = $"https://{shopDomain}/admin/oauth/access_token";
		var body = new { grant_type = "client_credentials", client_id = clientId, client_secret = clientSecret };

		Debug.WriteLine("Requesting a Shopify access token");
		var resp = await httpClient.PostAsync(endpoint,
			new StringContent(JsonSerializer.Serialize(body), Encoding.UTF8, "application/json"));

		var text = await resp.Content.ReadAsStringAsync();
		resp.EnsureSuccessStatusCode();

		var parsed = JsonSerializer.Deserialize<TokenResponse>(text, new JsonSerializerOptions { PropertyNameCaseInsensitive = true })
					?? throw new InvalidOperationException("Token parse error.");

		TimeSpan ttl = TimeSpan.FromMinutes(fallbackTtl);
		if (parsed.ExpiresInSeconds.HasValue)
		{
			ttl = TimeSpan.FromSeconds(parsed.ExpiresInSeconds.Value - 30);
		}

		Debug.WriteLine($"Access token received with a TTL of {ttl.TotalSeconds:N0} seconds ({ttl.TotalMinutes:0} minutes or {ttl.TotalHours:0} hours)");
		cache.Set(cacheKey, parsed.AccessToken, ttl);
		return parsed.AccessToken;
	}

	private sealed class TokenResponse
	{
		[JsonPropertyName("access_token")]
		public string AccessToken { get; set; } = "";
		[JsonPropertyName("expires_in")]
		public int? ExpiresInSeconds { get; set; }
		[JsonPropertyName("scope")]
		public string Scope { get; set; }
	}
}

Chrome profile directory

 C:\Users\<username>\AppData\Local\Google\Chrome\User Data

Windows 11: slow loading to desktop after login prompt

 On some of my computers Windows 11 was taking a long time to show the desktop after logging in with your user credentials.

What happens is you get a build up of data in %userprofile%\AppData\Local\Temp.

Pre-cleansing, one of mine was 35.1GB. It was full of folders named with GUIDs.

Deleting this significantly speeds up the desktop load.

Using RSync on OpenMediaVault

 Attach the backup disk.

Confirm the device name and serial from Storage > Disks.

Mount an existing file system. Select the correct mount point (e.g. /dev/sdb2).

Apply the changes.

Create a shared folder:
Name: Data2
File system: /dev/sdb2
Relative Path: Data/

Create an Rsyn Task: Services > Rsync > Tasks

Type: Local
Source: Data
Destination: Data2
Delete: <optional>

The mount point can be accessed from a shell terminal at:
/srv/dev-disk-by-uuid-<uuid>

to query the number of files enter:
find . -ls | wc -l