Help troubleshooting long load times for going to base custom domain

Given a fresh browser session using a Private Window, making two requests that should be roughly the same thing is giving wildly different response times.

Requesting app.ca.la (6160ms of waiting):

Screen Shot 2020-01-13 at 11.22.46 AM

Requesting https://app.ca.la (30ms of waiting):

Screen Shot 2020-01-13 at 11.23.06 AM

I would suspect something in the http -> https redirect except that requesting something like app.ca.la/login returns quickly.

We’re doing the SPA redirect rule with /* /index.html 200, and that seems to work just fine and is as fast as I would expect it to be. DNS is being served by Cloudflare, but is not proxied by them. Any ideas on how to troubleshoot this?

Thanks!

1 Like

Hi, @scotttrinh, would you be willing to make a HAR capture of the long load time issue and send that to us?

I’ve enabled private messages (PMs) for your community account if you don’t want to post that publicly for any reason.

Also, if the HAR file isn’t an option, would you be willing to send the x-nf-request-id response header for the slow load? That will also help us to troubleshoot.

@luke,
I’d be happy to provide a HAR, and any other debugging material that you think would be helpful. Trying it out this morning and it’s running fast in browser, but still is showing the lag (sometimes!) in our uptime monitoring tool. Here is a x-nf-request-id from the most recent run that took 6.12 seconds: 21072030-814a-4cdf-9183-1eda287e2420-1276341. And a run that took 95ms: cc968310-b3f2-457c-b990-92985350cde2-301902.

I’ll try a few times throughout the day and try to get a HAR to send over. Thanks for following up! :raised_hands:

Not that it’s super helpful for troubleshooting, but this is the graph that had me looking into this! :sweat_smile:

Hi, same (similar) problem here, I have a SPA and the redirect configuration in my .toml file.

Har screenshot:

Hi, @ignaciocabeza, and welcome to our Netlify community site.

Would you please send us the x-nf-request-id header for an HTTP request showing this behavior? If that header isn’t available, please send us the following details instead for this HTTP request:

  • the complete URL requested
  • the IP address for the system making the request
  • the IP address for the CDN node that responded
  • the day of the request
  • the time of the request
  • the timezone the time is in

With these details we can start troubleshooting the issue in more detail.

Hi, @scotttrinh. We have a known issue where there is slow fetching of uncompressed versions of URLs (no gzip/deflate request headers). I believe this is the reason for the slow requests.

The User-Agent header sent to Netlify for the HTTP requests which returned the x-nf-request-id header 21072030-814a-4cdf-9183-1eda287e2420-1276341 indicates that this request was made by an automated monitor. It had a user agent similar to this (only an example - this isn’t the User-Agent):

user-agent: url-scanner/2.0

I also checked other requests for this User-Agent (the actual one).

I mention this because, depending on the domain being checked, that same `User-Agent is always fast for some other domains hosted at Netlify. However, for your domain is it always 6 seconds or longer.

I suspect there is a setting to request the compressed site version at this is occurring for other sites using the same monitor. Would you be willing to please check if there is a way to change the monitor to requested the compressed version of the URL? This might resolve the timing issue with the monitor service in the meantime while the open issue at Netlify remains.

Again, it is less than ideal that the uncompressed version loads slowly and we do have an issue filed for this. That issue is now cross-linked with this community topic and we’ll post an update here if/when this issue is resolved.

Please note, while the monitor is showing a slow page load, this is not indicative of the page load speed a person’s web browser would experience. A browser will send a request header similar to this:

accept-encoding: gzip, deflate, br

These HTTP requests for people visiting the site (not bots) are unaffected by this issue.

If possible, adding this header above to the automated monitor should cause the monitor to get the fast page load just like a browser would.

If there are other questions about this, please let us know.

1 Like

hi @luke i stumbled upon this thread but i think i may have a relevant issue to this topic.
in a portfolio site, subfolders are accessed much faster than the parent folder (which has a 6s delay too). ive been trying to figure this out but these 6seconds are a pretty big coincidence.

root: https://portfolio.narudesign.com.br/
project: Home | Relatório Anual 2017

While that seems reasonable, I was definitely experiencing these delays with both Chrome and Firefox (Nightly) when I first reported the problem. The initial screenshots are from a Firefox session. I just tried from FF again and was able to reproduce the issue and save a HAR! :tada: I’ll send a DM and hopefully we can see if there is something to be learned from it.

x-nf-request-id: 6e69b6de-12dc-4b41-9a67-218d9214f478-1212062
Took 6.33 seconds and did include Accept-Encoding: gzip, deflate, br with a FF user agent.

Thanks again for the detailed help! You’re correct in saying that the typical user experience is fast, but it’s definitely intermittent! I’ll keep my monitoring service setup the same, since it’s not really affecting anything on our end, so we notice the fix when it arrives.

Thanks again, and look out for my DM with the HAR session.

Please see this thread - we think these issues are related:

2 Likes

Hi everyone, we have some great news :tada:

We have tested & rolled out a fix for these issues.

More information here:

Please feel free to discuss on that thread, I will close this one (and others) so to contain the conversation a bit more. Thank you all for your patience :pray:

1 Like