TMC is an independent, primarily volunteer organization that relies on ad revenue to cover its operating costs. Please consider whitelisting TMC on your ad blocker or making a Paypal contribution here: paypal.me/SupportTMC

Why is the Tesla website so horrendously slow?

Discussion in 'Model S: Ordering, Production, Delivery' started by neko, Jan 14, 2015.

  1. neko

    neko Member

    Joined:
    May 21, 2014
    Messages:
    17
    Location:
    Midwest
    Right now, it's taking many minutes to load, but even at the best of times, it takes many, many seconds. How am I going to check the status of my order 10 times a day? Seriously, though, Tesla seems to have one of the slowest servers around.
     
  2. TES-E

    TES-E Member

    Joined:
    Jun 23, 2014
    Messages:
    373
    Location:
    Casa Grande, AZ
    #2 TES-E, Jan 14, 2015
    Last edited: Jan 14, 2015
    Probably overwhelmed with people checking on their orders 10 times a day... :wink:. (I did it too not all that long ago).
     
  3. bonnie

    bonnie Oil is for sissies.

    Joined:
    Feb 6, 2011
    Messages:
    14,241
    Location:
    Columbia River Gorge
    We can all speculate, but it's a question best answered 'over there'. Any answer here is a guess.
    :)
     
  4. grahamsimmonds

    Joined:
    Dec 12, 2014
    Messages:
    64
    Location:
    United Kingdom
    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.
     
  5. Barry

    Barry Member

    Joined:
    Aug 9, 2013
    Messages:
    780
    Location:
    Colorado
    The server is fueled by oil.
     
  6. wayner

    wayner Active Member

    Joined:
    Oct 29, 2014
    Messages:
    1,586
    Location:
    Toronto
    If I was supporting them I would also recommend that they get proper Forum software, but I guess that doesn't matter as much since we can use TMC instead!
     
  7. aznt1217

    aznt1217 Active Member

    Joined:
    Aug 27, 2012
    Messages:
    2,238
    Location:
    New York, NY
    Probably a huge amount of press generated by NAIAS.
     
  8. mejojo

    mejojo Member

    Joined:
    Aug 4, 2014
    Messages:
    561
    Location:
    Santa Paula, CA
    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.
     
  9. GreenT

    GreenT Member

    Joined:
    Mar 14, 2014
    Messages:
    292
    Location:
    Here
    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?
     
  10. breser

    breser AutoPilot Nostradamus

    Joined:
    Aug 28, 2014
    Messages:
    2,310
    Location:
    North Bend, WA
    #10 breser, Jan 19, 2015
    Last edited: Jan 19, 2015
    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.

    Screen Shot 2015-01-19 at 10.41.22 AM.png

    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.
     
  11. dennis

    dennis P85D

    Joined:
    Jul 26, 2012
    Messages:
    1,219
    Location:
    Silicon Valley CA
    I could not get the attachment to load.
     
  12. breser

    breser AutoPilot Nostradamus

    Joined:
    Aug 28, 2014
    Messages:
    2,310
    Location:
    North Bend, WA
    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.
     
  13. OConnorStP

    OConnorStP Member

    Joined:
    Oct 25, 2014
    Messages:
    78
    Location:
    Praag, WI, USA
    breser gets a gold star! I bet his hints would really help a lot. I love the "no-cache" cache... :)
     
  14. breser

    breser AutoPilot Nostradamus

    Joined:
    Aug 28, 2014
    Messages:
    2,310
    Location:
    North Bend, WA
    Fixed it myself by editing the post and uploading the image again.
     
  15. R²B

    R²B All Star

    Joined:
    Aug 24, 2014
    Messages:
    340
    Location:
    Waddell, AZ
    It probably uses the same backend as the built-in Model S browser (I kid).
     

Share This Page