With the knowledge of how Google Ads affect Core Web Vitals (redirecting users to googleadservices.com before redirecting them to the actual destination), it would make sense to think that the same applies to redirects happening when users are clicking on a link in their Twitter feed.
Although users would actually see the URL of the destination page, users would actually be redirected to a t.co page. However, in case of a real user, the t.co domain would respond with an HTML page. And this is where nuances begin.
Not a real redirect
I wrote about how Twitter's t.co redirects work on my personal site. And instead of actually redirecting users with a server side 301, the browser would get an HTML page containing further information. Specially a line of JavaScript that would trigger a new client side redirect.
No Core Web Vitals impact
Because of this in-between succesfully loaded HTML page, the TTFB timing since the first click would stop tracking when the first byte of t.co is loaded. And a new TTFB starts to track when the JavaScript is being executed.
This could still add a bit of latency because of browser work, but this is neglectable compared to a direct click without the help of t.co. So, the answer here is that it won't hurt your TTFB nor your Core Web Vitals.
But it is impacting real users
So, website owners won't see these redirects and delays in their monitoring data. However, as a domain lookup to t.co first needs to be resolved first, and contents then needs to be downloaded, there actually is a delay before the final client side redirect is happening.
Bad feeling and bouncing back
And that's where the crux is. While it doesn't become part of your data, the delay is actually there. And as t.co is serving HTML which new homework for the browser, it is actually showing a white page. And users will think that the destination page is slow to load, while t.co might be the one to blame. They might end up having a bad feeling about your site as a result, causing them to bounce back to their Twitter feed instead.
It also works the other way around: When t.co was able to respond quickly, but the origin site takes long to load due to server side redirects on their own, long DNS lookup times or server response times, users will actually still be on t.co. They might think t.co is to blame, while they are not.
Test your TTFB
To be able to exclude your own server response times from being the UX issue, track and check your TTFB regularly. You can do this using our free tools based on experiences from real users, or start monitoring with more detailed insights.
