Live data from Hacker News

Page Weight Matters (2012)

blog.chriszacharias.com

61–70 of 171 posts

Re: Page Weight Matters (2012)

#62
post #19

Coming from a low bandwidth, high latency part of the world, I can't confirm this enough. Today, I have 2 mbit and can use Netflix or Youtube just fine, but mere 4 years ago, I had 600k and, boy, that was hard. Hard as in loading youtube URL and go for a coffee. UPDATE: In case Duolingo developers are listening, please test your site on high latency and very low bandwidth scenarios. I just love your site, but lessons…

> Hard as in loading youtube URL and go for a coffee.

You can't even to that now. Youtube videos buffer about 1m30 of videos and stops after that :(

Re: Page Weight Matters (2012)

#63

Page weight may matter, but I think amortized page weight matters most. It's like the marshmallow experiment for the web. If you can make one request at 10x the size, but it's only made 1/100th as often (presumably spans multiple pages) then as long as people come back enough to justify that initial extra cost, you've effectively decreased to 1/10th again. That's why I think AJAX, web manifest [1], indexedDB, localSt…

The initial page load matters a lot. That's the one where the user is deciding whether he'll be coming back to your site. The unfortunate thing about many caching technologies is that they speed up subsequent page loads, but do nothing for the initial one. You still need to pay attention to clean-cache load times. Indeed, it can often be worth it to pay a cost on total page load time to get first-paint time down - that's the time at which the first visual representation of the webpage appears, even if it's just the header, layout, and a bunch of boxes.

Re: Page Weight Matters (2012)

#64
post #43
post #7

If you have an engineering mind and care about such things - you care about complexity. Even if you don't - user experience matters to everyone. Have you ever seen something completely insane and everyone around doesn't seem to recognize how awful it really is. That is the web of today. 60-80 requests? 1MB+ single pages? Your functionality, I don't care if its Facebook - does not need that much. It is not necessary.…

I took this screenshot yesterday. This was a page showing a news article (text). http://i.imgur.com/hmFaW3M.png

Oh, why are you blocking them? They are trying to enhance your experience on that website. /s

Re: Page Weight Matters (2012)

#65

When I joined Google in 2009, we were on the tail-end of a latency optimization kick that Larry had started in 2007. At the time, we had a budget of 20K gzipped for the entire search results page. I remember working on the visual redesign of 2010, where we had increased the page weight from 16K to 19K and there was much handwringing at the higher levels about how we were going to blow our entire latency budget on one…

Remember, http://google.com/custom still loads instantly ;)

Re: Page Weight Matters (2012)

#66
post #7

If you have an engineering mind and care about such things - you care about complexity. Even if you don't - user experience matters to everyone. Have you ever seen something completely insane and everyone around doesn't seem to recognize how awful it really is. That is the web of today. 60-80 requests? 1MB+ single pages? Your functionality, I don't care if its Facebook - does not need that much. It is not necessary.…

There are reasons for it: it takes more work to write an efficient, simpler application with the same functionality. Developer time is expensive.

Re: Page Weight Matters (2012)

#67
post #65

When I joined Google in 2009, we were on the tail-end of a latency optimization kick that Larry had started in 2007. At the time, we had a budget of 20K gzipped for the entire search results page. I remember working on the visual redesign of 2010, where we had increased the page weight from 16K to 19K and there was much handwringing at the higher levels about how we were going to blow our entire latency budget on one…

Remember, http://google.com/custom still loads instantly ;)

[deleted]

Re: Page Weight Matters (2012)

#68
post #42
post #35

Earlier quoted context omitted.

The fact that there isn't a daily drumbeat about how bloated, how needlessly complex, how ridicuous most of the world's web appliactions of today really are - baffles me Well there is, or at least there used to be. The reason native apps in mobile became so popular is exactly because web sites are bloated. It might not matter in the PC but in a device running on batteries it matters a lot. The real problem of web dev…

JavaScript isn't the problem, but it seems to always take the blame. And its not even slow. Here are a couple of real culprits: * Advertising / analytics / social sharing companies. They deliver a boatload of code that does very little for the end-user. * REST and HTTP 1 in combination. A page needs many different types of data. REST makes us send multiple requests for different kinds of data, often resulting with th…

> Want to download all the comments with the user info for every user? You have a choice between repeating the user info per comment, requesting the comments first then the users by id (two requests) or using a serialisation mechanism that supports object references (isn't pure JSON)

Or you send it like

    {
      "users": [
        {
          "id": "de305d54-75b4-431b-adb2-eb6b9e546014",
          "name": "Max Mustermann",
          "image": "https://news.ycombinator.com/y18.gif"
        },
        ...
      ],
      "comments": [
        {
          "user": "de305d54-75b4-431b-adb2-eb6b9e546014",
          "time": "2015-10-15T18:51:04.782Z",
          "text": "Or you can do this"
        },
        ...
      ]
    }
Which is a standard way to do it that works here, too. Because you can have references in JSON, you just have to do them yourself.

Re: Page Weight Matters (2012)

#69

Page weight may matter, but I think amortized page weight matters most. It's like the marshmallow experiment for the web. If you can make one request at 10x the size, but it's only made 1/100th as often (presumably spans multiple pages) then as long as people come back enough to justify that initial extra cost, you've effectively decreased to 1/10th again. That's why I think AJAX, web manifest [1], indexedDB, localSt…

This is a bad idea, because users may not give you a second chance. The research says over and over again, users respond negatively to small increases in latency.

In fact, if I knew of a way to decrease the size of the first load, at the expense of making the second load take longer, I'd probably do it.

Post reply on HN