These videos don’ work on Chrome, I need to use Firefox
Hey Alex, what platform are you using? I’ve been able to access this video from Chrome on Mac and PC
I’m on Mac & Chrome (Version 44.0.2403.107 (64-bit)) too
Here’s what happens
Welcome to the web. :)
That could possibly be a temporary server issue or even a network issue on your side. I saw the same thing on Chrome here, but it loaded after a few seconds and it was fine. Likely just a temporary glitch somewhere.
I don’t think so, it’s still not working, and is was happening with other videos too on this website, I think it’s worth investigating maybe.
Thanks Alex! We’ll be looking into this issue further.
Hi Alex, thanks for letting us know! Do you think you could email our support team at email@example.com so that we can work with you to debug this with our system setup?
Player is not loading for me either, so I can’t watch the video. I’m seeing four 403’s erros in the console.
This video wold have been a lot more helpful if you showed examples of real code slowdowns instead of just using third-party libraries as your examples. In other words, show code on your own site that is slow and then how your updates/fixes made a difference (to the overall profile report).
I mean, with the example you showed your just guessing what the slowdowns are, right?
Hey Mike, thanks for the feedback! In my experience, real code slowdowns are very often due to 3rd party resources. In the case of ticketmaster, the fix would be to pull the third party service out, and reimplement (if possible). When doing performance audits on websites that you didn’t build, your findings are often only as good as the tools you’re using. In this case, we didn’t get a ton of helpful information, but we were able to pinpoint what file the issues were occurring in. This information would be very helpful to the developers of the site, who could then pinpoint what the file was responsible for, and fix as needed.
So, what about the s.c_r function? Because that’s where 1.2s are being spent, not sure why you focused on the sub-200ms slowdowns.
That’s what I was thinking the whole time
This was pretty interesting but I agree with Mike Badgley. It seemed like all you did was show how to identify where a try-catch was producing unoptimized code and how to find which file was doing that. Didn’t do much in terms of performing an in-depth performance analysis. Suggesting swapping out a slow 3rd party library for something faster isn’t really helpful.