Twitter tried to reduce load times for external links, but it made things slower instead. It mistakenly normalizes domain names to a point where they’re no longer can be used to fulfill their task.
I’ve previously written about when to use <link rel="preconnect">. That article also serves as an introduction if you’re unfamiliar with the topic.
Twitter redirects links through its t.co link-shortening service. It was once a useful addition to its service as it helped people stay underneath the strict character limits. The link shortener reduced all links to 23 characters. Twitter gains some more data-insights about its users in the form of click-stream data and insight into popular links.
However, the link shortening service has another cost: links resolve slower. Instead of clicking-through directly to the destination website, the browser needs to connect to Twitter’s link-shortening service and then follow a redirect to the destination website. To speed up the process, Twitter preconnects to its link-shortening service every time you scroll a link card into view. Link cards are boxes that show an image, title, and description of a link. This shows that Twitter finds it highly likely that people will click on external links in tweets.
To speed things up even further, Twitter also preconnects to the destination website at the other end of the redirect. This is where it has made some mistakes, though.
You may be wondering why it’s even using the link-shortening service anymore if it already knows the destination address. Reread the previous paragraph for clarification on Twitter’s motivations.
Before I go on to discuss the issues, I have to talk a little bit about privacy. Preconnects doesn’t transmit any HTTP headers, cookies, or other identifying data. The destination website doesn’t have any idea why the client opened a connection to it at this point. It has just opened a connection and is waiting for a request to come in. Its servers can identify the TLS library and version used to establish the connection, but this is in no way unique data. A third-party that can observe the relevant network traffic will know that the user either tried to connect to or saw a link to the domain name or server in question.
That being said, Twitter will often preconnect to the wrong website. As an example, let’s look at the tweets by @nytimes. The links shared by this account link to the domain www.nytimes.com. Instead of preconnecting here, Twitter preconnects to nytimes.com. These connections are, of course, made to the wrong server so they’ll never be used.
Tweets posted through Twitter Advertising (whether you see that tweet as an advert or not) don’t have this problem. These tweets don’t use t.co and always preconnect to the right server (in addition to also preconnecting to the wrong server).
The incorrect domain name used for the preconnect seems to originate from the display URL property of Twitter’s API. It strips out the www. prefix to make a ”display version“ of the URL. I have no problem with this, as the prefix is entirely meaningless to humans. It does serve important technical functions, however. Twitter doesn’t remove it from the actual redirect URL.
Let us look in more detail what happens when a user clicks on a link and when the browser gets to use the preconnection.
Firstly, the browser now needs to resolve the domain name including the www. prefix. Secondly, the browser needs to establish a TCP connection and set up a TLS connection. All these steps would be done already had Twitter only connected to the correct domain in the first place.
It’s difficult to say exactly when this issue began. I can’t look at older versions of Twitter, as its pages don’t work well in the Internet Archive’s Wayback Machine. Come to think of it, should Twitter be preconnecting to all these websites in the first place?
In my article on when to use <link rel="preconnect">, I discuss the situations where it’s beneficial to use the preconnect technique. I agree with Twitter that it’s likely to be useful to preconnect to the destination address in some situations. Such as when the Twitter message or link card is the only thing on the page, or you’ve stopped scrolling and have it visible for a split second or two.
However, Twitter indiscriminately preconnects to every link that you scroll by in your feed. Technically, it only preconnects when you hover over the link. However, you hover over every link by default as you hold your mouse cursor over the main feed and scroll downwards. Depending on the link-sharing habits of those you follow, that number of preconnects adds up quickly. This can slow down your browsing experience in slow network conditions or on low-end devices.
Properly testing preconnection behavior requires specialist tools and skills. The developer tools in web browsers don’t do a good job with preconnects. They’re not even recorded in the Network tab. Safari displays a message for each preconnect and warns of unused preconnect in its Console tab.
Hey @Twitter, fix your stuff!
Update (): Twitter has now addresses the problem and preloads the correct domains.