-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Why is the Tesla website so horrendously slow?
- Thread starter neko
- Start date
TES-E
Member
Probably overwhelmed with people checking on their orders 10 times a day... :wink:. (I did it too not all that long ago).
Last edited:
bonnie
I play a nice person on twitter.
We can all speculate, but it's a question best answered 'over there'. Any answer here is a guess.
I support secure web based applications for a living. I agree that the TM website is slow to respond but on an average connection it takes 5-15 secs to respond, and is particularly slow to respond to My Tesla. This looks like the wait is down to the database back end needing this time to supply the data for the web application then to display. Once the database query has run the page builds very quickly so it is not a bandwidth issue.
The forum is also slow to respond.
I am surprised that the recent upgrade did not improve performance but perhaps that was a refresh of style and content only.
If I was the company supporting the Tesla site I would be concerned at the lack of performance and working to optimize the database queries. However, I suspect that this maybe run in house because of the tie in with manufacturing etc., Hence why they get away with it.
The forum is also slow to respond.
I am surprised that the recent upgrade did not improve performance but perhaps that was a refresh of style and content only.
If I was the company supporting the Tesla site I would be concerned at the lack of performance and working to optimize the database queries. However, I suspect that this maybe run in house because of the tie in with manufacturing etc., Hence why they get away with it.
mejojo
Active Member
It would seem that if they alerted (SMS or email) of any change in status, it would greatly relieve the number of refreshes anxious soon-to-be owners make.
I am sorry but how can you possibly know this based on browsing alone? There is no way to know which layer is responsible for the slowdown without having monitoring tools available to you within the "server cluster".
This could also easily be a bad router close to the servers, a clogged / misconfigured web server, lack of caching on the programming part (less likely), or as you suggest, a problem between the db and web server.
It seems to be hosted at akamitechnologies.
Media Delivery and Content Delivery Network (CDN) Solutions | Akamai
And any information required from manufacturing would be from a proxy server and / or heavily firewalled link to who knows where?
No?
breser
AutoPilot Nostradamus
So I took some time looking at this. I used the "Vehicle Profile" page, which is the page you get when looking at a specific vehicle's information. For people with a single Tesla this is the same as the front of their dashboard. If you have multiple vehicles there is another extra page in there.
So let's look at what makes this page slow. I'm doing this on a machine that already has caches of pretty much everything and that possibly even has connections still open since I did several refreshes of the page. So this is best case behavior.
By and far the worst thing about this page is the waiting on the first request.
As you can see in the above screenshot it takes nearly 5 seconds for that first request to start sending data. You can also see that 1.2 seconds after the first request is received the rest of the content is loaded and then it takes another 1.5 seconds for the page to be loaded. So ultimately the page takes 7.36 seconds to load.
As mentioned above it's hard to be sure what all constitutes that 5 seconds without more access than what we have from the outside. But there are a few things we can see and we can draw some conclusions from this.
As mentioned above Tesla is using Akamai which is a Content Delivery Network (CDN). The purpose of a CDN is to cache a copy of the website content closer to the user and thus make it load faster. As a result Akamai has servers all over the world and whenever you ask for a site that's being hosted by Akamai you're directed to the nearest server. This server then does one of two things. If it already has a copy of the URL you're asking for locally it returns that to you or it goes to the remote server and asks for it and returns the URL as well as making a local copy, thus speeding up the next request.
Using some special headers I can see that Akamai is not actually caching this page. They simply pass the request through to Tesla. This means Akamai is essentially just extra overhead. Behind Akamai I can also see that Tesla is using Varnish. I'd guess, but can't say for sure, that the Varnish servers are also not caching this page. Nor is the local browser as the Cache-Control header is set to disallow caching this page. This lack of caching has up and downsides. The upside is that reloading really does get the info from Tesla pretty much every time. But it also means that Tesla's servers take the load from us reloading all the time to check order status. A 15-60 minute cache might speed up load times without degrading accuracy by much. Akamai also has the capabilities to cache only portions of the page and serve identical pieces to everyone. I don't believe, but can't be sure, that Tesla is taking advantage of this. Ultimately, at least some of that load time is caused by this extra infrastructure in the path. Not every piece of the page of course is not cached. Many of the images and other assets that make up the page are cached and are improved by this setup. It is possible to configure different pieces to have different cache times and so that would be my recommendation here.
One thing to note here is that this page is of course served over HTTPS. HTTPS does have a certain amount of extra overhead to negotiate the encryption. It's almost certain that the connection from Akamai to Tesla constitutes another encrypted connection adding to the overhead of the HTTPS setup. Though often Akamai can reuse these connections for multiple requests, but I'm not sure if Tesla is big enough to really be benefiting from this.
On the backend it's difficult to say anything about what's causing the delay beyond whatever is added by the Akamai setup. But I'd bet it's a slow database setup. There could be any number of reasons for this. The queries in the database could be poorly written (not having indexes, requiring more joining of tables than necessary, etc), there could be insufficient connections from the application on the server side to the database server and so requests have to wait to ask the database for information, etc... Without changing anything improvements here could probably speed this page load up pretty dramatically.
However, as I mentioned before there's still an extra 1.2 seconds of time in loading other assets. Two of these assets stand out as major time sinks. Tesla is getting fonts from typekit.com and typography.com. The typography.com one is particularly bad. The DNS servers for typography.com are slow to respond, adding nearly a 3rd of a second to the load time. While the CSS for the font from typograhpy is cached it has to be revalidated every request. This means that you pay that cost of the DNS request every time and it sadly takes the server 2 tenths of a second to provide the information to the browser to decide it doesn't need to download the CSS again. So between the DNS, connection, and waiting on the servers that accounts for 688 ms (or 6 tenths of a second) added to the load time. Typekit.com ends up being much better since it's allowed to be cached. But it can be somewhat slow the first time. Both of these things should be on Tesla's servers not 3rd party servers since the DNS lookup could be removed entirely and existing connections could be reused. However, it's not clear what the font licensing requires in this case, so they may not be able to do this. Both of these happen in parallel so you're really only paying for the worst of them anyway.
Tesla also uses Google Analytics, Eloqua and Google Ad Services. All of which probably are there to provide tracking for who's looking at that page (and possibly let them serve ads in the future to those same people on other sites). These add a small amount of extra load time.
Finally, there are two extra requests that are made back to Tesla's servers that like the first one aren't cached. The owner-manuals request (which fills in what owners manuals to show) and the documents list request (which fill sin links to your order agreement and other documents that show up under My Documents). Neither of these are cached. The owners-manual request spends 317ms waiting on the server and the documents list spends 1.25 seconds waiting on the server. I can't imagine why the owners manual information couldn't be cached for as long as a day and the documents list could be cached for a reasonable amount of time as well. But they aren't.
Ultimately, in my opinion I don't think Tesla has really done too much effort on optimizing for page load times. If they did this they could probably reduce this load time by a fairly significant amount.
So let's look at what makes this page slow. I'm doing this on a machine that already has caches of pretty much everything and that possibly even has connections still open since I did several refreshes of the page. So this is best case behavior.
By and far the worst thing about this page is the waiting on the first request.
As you can see in the above screenshot it takes nearly 5 seconds for that first request to start sending data. You can also see that 1.2 seconds after the first request is received the rest of the content is loaded and then it takes another 1.5 seconds for the page to be loaded. So ultimately the page takes 7.36 seconds to load.
As mentioned above it's hard to be sure what all constitutes that 5 seconds without more access than what we have from the outside. But there are a few things we can see and we can draw some conclusions from this.
As mentioned above Tesla is using Akamai which is a Content Delivery Network (CDN). The purpose of a CDN is to cache a copy of the website content closer to the user and thus make it load faster. As a result Akamai has servers all over the world and whenever you ask for a site that's being hosted by Akamai you're directed to the nearest server. This server then does one of two things. If it already has a copy of the URL you're asking for locally it returns that to you or it goes to the remote server and asks for it and returns the URL as well as making a local copy, thus speeding up the next request.
Using some special headers I can see that Akamai is not actually caching this page. They simply pass the request through to Tesla. This means Akamai is essentially just extra overhead. Behind Akamai I can also see that Tesla is using Varnish. I'd guess, but can't say for sure, that the Varnish servers are also not caching this page. Nor is the local browser as the Cache-Control header is set to disallow caching this page. This lack of caching has up and downsides. The upside is that reloading really does get the info from Tesla pretty much every time. But it also means that Tesla's servers take the load from us reloading all the time to check order status. A 15-60 minute cache might speed up load times without degrading accuracy by much. Akamai also has the capabilities to cache only portions of the page and serve identical pieces to everyone. I don't believe, but can't be sure, that Tesla is taking advantage of this. Ultimately, at least some of that load time is caused by this extra infrastructure in the path. Not every piece of the page of course is not cached. Many of the images and other assets that make up the page are cached and are improved by this setup. It is possible to configure different pieces to have different cache times and so that would be my recommendation here.
One thing to note here is that this page is of course served over HTTPS. HTTPS does have a certain amount of extra overhead to negotiate the encryption. It's almost certain that the connection from Akamai to Tesla constitutes another encrypted connection adding to the overhead of the HTTPS setup. Though often Akamai can reuse these connections for multiple requests, but I'm not sure if Tesla is big enough to really be benefiting from this.
On the backend it's difficult to say anything about what's causing the delay beyond whatever is added by the Akamai setup. But I'd bet it's a slow database setup. There could be any number of reasons for this. The queries in the database could be poorly written (not having indexes, requiring more joining of tables than necessary, etc), there could be insufficient connections from the application on the server side to the database server and so requests have to wait to ask the database for information, etc... Without changing anything improvements here could probably speed this page load up pretty dramatically.
However, as I mentioned before there's still an extra 1.2 seconds of time in loading other assets. Two of these assets stand out as major time sinks. Tesla is getting fonts from typekit.com and typography.com. The typography.com one is particularly bad. The DNS servers for typography.com are slow to respond, adding nearly a 3rd of a second to the load time. While the CSS for the font from typograhpy is cached it has to be revalidated every request. This means that you pay that cost of the DNS request every time and it sadly takes the server 2 tenths of a second to provide the information to the browser to decide it doesn't need to download the CSS again. So between the DNS, connection, and waiting on the servers that accounts for 688 ms (or 6 tenths of a second) added to the load time. Typekit.com ends up being much better since it's allowed to be cached. But it can be somewhat slow the first time. Both of these things should be on Tesla's servers not 3rd party servers since the DNS lookup could be removed entirely and existing connections could be reused. However, it's not clear what the font licensing requires in this case, so they may not be able to do this. Both of these happen in parallel so you're really only paying for the worst of them anyway.
Tesla also uses Google Analytics, Eloqua and Google Ad Services. All of which probably are there to provide tracking for who's looking at that page (and possibly let them serve ads in the future to those same people on other sites). These add a small amount of extra load time.
Finally, there are two extra requests that are made back to Tesla's servers that like the first one aren't cached. The owner-manuals request (which fills in what owners manuals to show) and the documents list request (which fill sin links to your order agreement and other documents that show up under My Documents). Neither of these are cached. The owners-manual request spends 317ms waiting on the server and the documents list spends 1.25 seconds waiting on the server. I can't imagine why the owners manual information couldn't be cached for as long as a day and the documents list could be cached for a reasonable amount of time as well. But they aren't.
Ultimately, in my opinion I don't think Tesla has really done too much effort on optimizing for page load times. If they did this they could probably reduce this load time by a fairly significant amount.
Last edited:
dennis
Model S Plaid
breser
AutoPilot Nostradamus
That's strange. Probably a forum issue since it loads for me (though it's not inlining). Hopefully time or the mods will fix this.
OConnorStP
Member
breser gets a gold star! I bet his hints would really help a lot. I love the "no-cache" cache...
breser
AutoPilot Nostradamus
R²B
All Star
Similar threads
- Article
