from Hacker News

AirPods Pro Page Performance

by golfer on 11/2/19, 7:48 PM with 69 comments

  • by jakear on 11/2/19, 8:17 PM

    Curious: does anyone have an actual negative user experience on the website? I tested it on both my shotty WiFi (for reference, I’m unable to stream YouTube at 720p), and cellular (2 bars), and I found the page to load quickly and be reasonably responsive either way. In the thread I think twitter user Kenneth Auchenberg puts it best:

    > Come on. Look at the experience and tell me you expected it to be 1kb? This is an interactive application, not a text document. [...] We have started to chase a false “unicorn” narrative of websites with expected app-like experiences, but sizes like text documents from the 2000s. Something doesn’t add up.

  • by mrtksn on 11/2/19, 8:20 PM

    Okay, this is something that I was thinking about: Are megabytes and seconds really a good indicator for UX quality of a website?

    Youtube is amazing, it starts playing the video before even the video title is rendered or any other part of the page is loaded. Who cares if it downloads who knows how many megabytes of JS or HTML before the DOM is ready?

    On the other hand, after clicking on a tweet link Twitter would show me multiple loading indicator, load the main page then show me some more loading indicator and then show me the tweet text and after a while, I can see the images attached to the tweet. It is often the same for any other "Web App".

    On Apple's case, the page actually becomes usable almost instantly. The page would first show me the title on the black background and then the airpods photo would fade in from the darkness and I would be able to scroll immediately. I would say, the experience is closer to Youtube than Twitter.

  • by IdontRememberIt on 11/2/19, 8:20 PM

    On holiday, with our 100MB datarooming package outside Europe at USD13, watching this page would cost me over USD8?!
  • by izacus on 11/2/19, 8:43 PM

    An extreme cynic could say: If you don't have a fast connection with dataplan for that, you're not rich enough to be the target market.

    A lot of iOS and macOS software and websites are designed with assumption of having good infrastructure only affluent western world has.

  • by reaperducer on 11/2/19, 9:18 PM

    There are a few comments in this thread about how the page is able to determine if you're on a low-bandwidth connection and sends pictures instead of videos.

    If anyone knows how this is achieved, I'd love to follow some links.

  • by why-oh-why on 11/3/19, 10:34 AM

    What really annoys me is that it’s 2019 and companies, even Apple, are still doing these unnerving “parallax” sites that force you to scroll riiight there to read a paragraph. Overscroll? You’ll have to scroll back.

    How’s that a good experience?

    On mobile it would be super easy to just have it snap in place: one flick goes to the next “slide.”

    But no. Let’s treat websites as videos and the scroll as a way to manually play them.

  • by rauchp on 11/2/19, 8:20 PM

    To be fair, it is a nice site.

    Those numbers definitely make it sound like it's not the ideal solution for the client. But from Apple's perspective, does anyone know how much more their servers are being taxed per-view? (Not sure if they have caching solutions to alleviate the load. That is a lot of packets to send, though.)

  • by droithomme on 11/2/19, 9:52 PM

    On my system it made 54 requests totaling 4.13MB of data. Artwork looks pretty good, like it's more than 4MB.

    This machine doesn't have retina. Maybe for retina machines it loads larger artwork. Also there's a bunch of errors in the console including:

    Error: WebGL: Disallowing antialiased backbuffers due to blacklisting.main.built.js:10:16167

    Error: Cannot find module '@marcom/ac-polyfills/Array/prototype.forEach' ac-analytics.js:1:166

    Strict-Transport-Security: The site specified a header that could not be parsed successfully

    The errors don't seem to have affected anything, but maybe more stuff didn't load because of the errors.

    Oh wait people are seeing video? Yeah I don't get any videos.

  • by ksec on 11/3/19, 6:36 PM

    Apple, ( And Stripe ) used to be very good in their Web Page design and performance, but over the page few years things has gone downhill, along with their product and software quality. This cant be all a coincidence.
  • by rcar on 11/2/19, 8:18 PM

    FWIW, I'm not able to replicate that - getting ~70-80 requests with 2.9MB transfer/4.8MB resources on Chrome.
  • by dang on 11/3/19, 4:27 AM

    We changed the URL from https://twitter.com/foobartel/status/1189135552949317632 to the blog post pointed to by a tweet in the thread.
  • by gandutraveler on 11/3/19, 5:46 AM

    I am planning to build a landing page for a small beverage product similar to this. Can anyone help me understand on how this web experience was implemented. Is it as simple as onScroll-> load next image ?

    Also what is a recommended tool of 2019 to convert video to images ?

  • by uxamanda on 11/2/19, 9:49 PM

    The page load doesn't seem to change with "Low Data Mode" enabled on Safari (seeing ~30MB).

    Does anyone know if there is a way to detect that setting from within Safari? Would be cool to provide a low-fi version of a page if that was detected.

  • by ErikAugust on 11/3/19, 4:55 AM

    https://beta.trimread.com/articles/368

    Trim strips it down to 12KB. And really it still conveys the message with just text just fine.

  • by jasonvorhe on 11/2/19, 10:00 PM

    I don't get how people can get upset about a website.
  • by jaunkst on 11/2/19, 8:32 PM

    Didn't read but sounds like web components without a bundling concept.
  • by m0zg on 11/2/19, 9:27 PM

    It's a "presentation" page. Who cares how many requests it makes. You'll only load it once, if that. Its only function is to present stuff in a way that'll make you buy it, which is something it accomplishes really well.
  • by jokoon on 11/2/19, 8:25 PM

    I'm no expert at rendering HTML, but I wonder if HTML can be "optimized" so that some css rules and redundant divs can be "merged".

    If that can be done server-side, it might reduce page weight. If it's not possible, well, I guess HTML should be removed from the face of the earth. The language has too much nonsense and ambiguity. The fact that html can now have its structure dynamically changed with javascript inserting string at random places means it will always let web developers build bloated websites like this.

    I really don't know how to solve such problem. Usually the language will encourage the flawed usages it allows. A language must always put constraints to avoid unwanted usages. Either that or have browsers not display pages that are too large, by having a size limit or something of that fashion.