This article by Dan Rayburn, self proclaimed "voice for the streaming & online video industry" has been making the rounds on twitter and briefly hacker news (until it was appropriately downvoted for being nonsensical rubbish). The article is so void of anything which remotely resembles reasoned argument that one could easily mistake it for satire.
Unlike the last live stream Apple did, this time around Apple decided to add some JSON (JavaScript Object Notation) code to the apple.com page which added an interactive element on the bottom showing tweets about the event.
Firstly JSON isn't code, it was JS code that pulled in JSON.
As a result, this was causing the page to make refresh calls every few milliseconds.
You would have to be pretty forgiving with your definition of "few" here.
By Apple making the decision to add the JSON code, it made the apple.com website un-cachable
Again, not JSON, js - and this doesn't make it uncacheable at all. Every single page on apple.com has javascript. If you had said that the JSON it was fetching couldn't be cached then I would have let you off (although even this isn't true - it just would need a really small cache expiry) but it is just completely untrue to say that apple.com was uncacheable.
By contrast, Apple usually has Akamai caching the page for their live events but this time around there would have been no way for Akamai to have done that, which causes a huge impact on the performance when it comes to loading the page and the stream.
As I have just said this is trollop.
And since Apple embeds their video directly in the web page, any performance problems in the page also impacts the video.
Lol what, I'm not even sure what you are trying to say here.
Because of all the refresh calls from the JSON code, it looks like it artificially forced the player to degrade the quality of the video, dropping it down to a lower bitrate, because it thought there were more requests for the stream than there was.
It was going so well with the first half of this sentence - constantly loading images at the same time as streaming a video may well lead to the bit rate to drop but then you sabotaged yourself with the second half "more requests for the stream than there was".
As for the foreign language translation that we heard for the first 27 minutes of the event, that’s all on Apple as they do the encoding themselves for their events, from the location the event is at.
Hooray the first sentence I don't have an immediate problem with.
Looking at the metadata from the event page, you could see that Apple was hosting content from the interactive element on the apple.com event page on Amazon’s S3 cloud storage service. From what I can tell, it looks like Apple setup the content in a single bucket on S3 with little to no cache hit ratio, with poor bucket configuration.
You can have a low cache hit ratio but you can't not have it - it is a ratio. And in any case the images were using the appropraite cache headers so this is again just plain wrong. You would expect a pretty low cache hit ratio (where a hit is a 302 response) on the s3 bucket since everyone is loading the images for the first time.
The below chart from third-party web performance provider Cedexis shows Akamai’s availability dropping to 98.5% in Eastern Europe during the event, which isn’t surprising if no caching is being used.
Dan what do you think availability means? Because whatever you think it means, it doesn't mean that.
The javascript was downloading from S3, the video was being streamed via akamai - two completely different networks.