Custom domains are slower

Connections to a project’s default domain appear to be much faster than connections to a project’s custom domain, which load slower than the default domain. connections are also slow on custom domains and disconnect quite frequently. Any idea why this is?


Hmm I’ll have to do some benchmarking. Do you have any examples I can test?

Sure, try nutsacc-chat.

what custom domain is that app on?

Should be

So I did a network performance test on Chrome and I can’t find any particular bottlenecks here:

Some things loaded faster on the custom domain

Strange, for me the connection is actually slower on the custom domain. I did my own test by sending messages.

Hmm you can try doing the network test yourself on Chrome. You should click record and then try sending messages.

Is there a tool like that on Firefox? I don’t use Chrome.

P.S: Even without a networking testing utility I do notice a difference in latency.

There is a network tab on Firefox as well

i did a network activity analysis and it appears that latency is indeed higher for GET and POST requests on the custom domain

default domain:

custom domain:

Interesting thanks for providing that, I looked into it more and are you using In the requests I see some different params for the domain including one that starts with fly. I’m thinking if it’s slower it’s because it is having to route through but I’m going to ask the team for more info.

When I was registering a custom domain for my glitch project I saw it was powered by, so I assume that I am using it

I’ll talk to the team about this. Thanks for reporting it!

No problem, please do update me on this :slight_smile:

So I talked with another engineer and he confirmed that routing is the issue. So it goes from:
you ---> ---> glitch
instead of
you---> glitch
Adding an extra step can make things slower depending on network conditions.

As for a solution, I don’t have one but we have improvements to custom domains on the roadmap.

1 Like

That makes sense, I’ll use the default domain until a fix is implemented, please do update me when there’s a fix

Adding the extra stuff also breaks things. For example if you were detecting https on the server side you would always get http because that’s the–>glitch portion. And sending a redirect to an https site makes the client redirect not And that’s how I ended up a redirect. So the lesson is, do that stuff on the client side.


I couldn’t have described the weird glitches the proxy system introduces better myself! I will add that does not pass all of the client request headers onto the glitch app, most annoyingly it reports the requested URL as {hash} which makes it impossible to tell which domain was the origin of the request.

1 Like