Connections to a project’s default glitch.me domain appear to be much faster than connections to a project’s custom domain, which load slower than the default domain. Socket.io connections are also slow on custom domains and disconnect quite frequently. Any idea why this is?
2 Likes
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 chat.nutsa.cc
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 socket.io 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. https://developers.google.com/web/tools/chrome-devtools/network
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 socket.io 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 fly.io? 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 fly.io 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 fly.io, 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 
So I talked with another engineer and he confirmed that routing is the issue. So it goes from:
you ---> fly.io ---> 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 fly.io–>glitch portion. And sending a redirect to an https site makes the client redirect not fly.io. And that’s how I ended up a redirect. So the lesson is, do that stuff on the client side.
2 Likes
I couldn’t have described the weird glitches the fly.io proxy system introduces better myself! I will add that fly.io does not pass all of the client request headers onto the glitch app, most annoyingly it reports the requested URL as {hash}.glitch.me which makes it impossible to tell which domain was the origin of the request.
1 Like