3 ms·

Whenever I read articles about elaborate ways to optimize the delivery of webapps, I am reminded of the following advice from https://idlewords.com/talks/websit

Whenever I read articles about elaborate ways to optimize the delivery of webapps, I am reminded of the following advice from https://idlewords.com/talks/website_obesity.htm#fixes https://idlewords.com/talks/website_obesity.htm#fixes: > I want to share with you my simple two-step secret to improving the performance of any website. > 1. Make sure that the most important elements of the page download and render first. > 2. Stop there. > You don't need all that other crap. Have courage in your minimalism.

wtallis 6y ago
And since a lot of web developers clearly need some clarification on this: step one means that the important content needs to be included in the initial response to the HTTP GET, and delivered as HTML. You're failing at step 1 if the first thing you serve up is JS to request the real content, or if the first thing you serve up is JS that operates on bundled data to transform it into something the browser can start rendering. If you're obsessively worried about "flash of unstyled content", then recall that the user will always see something after they click the link to your page. Giving them an unresponsive blank screen for an indefinite period of time may not be the best first impression to make.
- steve_taylor 6y ago
  Native phone apps don’t render their initial screen server-side. Why should web apps? They’re pretty much the same as phone apps, just on a different runtime. I make a distinction between web apps and web sites. Web sites should be server-side rendered (at least the initial render) for obvious reasons.
  - no_wizard 6y ago
    Native apps deliver 80-100% of their application at most once, all things being equal. Web applications do not do this, even with aggressive caching and using service workers. I’d also argue that the web is far more accessible than native apps, in that it’s cross platform and independent of any one vendor, currently. So there are valid reasons for considering the page load price of websites/web apps. Also, know your target audience. I’m decidedly not okay with non application sites loading megabytes of JS just to function. However I’m okay with complex functionality provider by my very good and feature rich web based email client need a few MBs of JS to work on initial load, because the features justify the cost in that case It’s not all or nothing
  - wtallis 6y ago
    > I make a distinction between web apps and web sites. This is an important distinction to make. But far too many web sites try to place themselves in the "web app" category when they really don't belong. Using a heavyweight JS framework does not automatically make your blog or news site into an app; it just makes your blog or news site slow. I've long thought that browsers should move to formalize the distinction between traditional web sites, and web apps. Apps should get access to the richer, more invasive APIs but only when the user instructs the browser to grant app-level permissions to the site, and at the expense of having stricter security and privacy policies enforced (ie. no third-party cookies, and probably no third-party scripts). > Native phone apps don’t render their initial screen server-side. Why should web apps? An extra RTT to local storage is pretty much always quicker than an extra RTT to a server. And it's not exactly unheard of for a mobile OS to cache a raster image of an app's screen to use the next time the user launches that app or browses through their collection of running apps.
    - kittiepryde 6y ago
      I second that. Browser distinction between web apps and web pages is an awesome idea. I think the hard part is preventing users from learning to always click 'yes' to web-app level permissions just because the page instructs the browser to do so. I don't know the solution to this.
      - wtallis 6y ago
        > I think the hard part is preventing users from learning to always click 'yes' to web-app level permissions just because the page instructs the browser to do so. I don't know the solution to this. The key requirement is that putting a site into app mode must be a tradeoff, not a mere expansion of capabilities/permissions. There has to be a disincentive to discourage non-app sites from unnecessarily requesting app-mode permissions. The most natural way to accomplish this would be restrictions that make it less practical and more expensive to exploit broader permissions to abuse users. Eg. if you want the browser to prompt me to give your site access to my location data, your site should have to surrender the ability to load trackers and ads from somebody else's servers—you should have to serve that up yourself from your own domain, or not at all. This would obviously break a lot about how things are commonly done on the current web, but most of what would be broken is the creepy stuff that we probably shouldn't be tolerating to begin with, like the monstrosity that reCAPTCHA has turned into under Google's stewardship.
onion2k 6y ago
I like idlewords' advice and I'd follow it for websites, but for web apps if there is a point where you can split the code then it is faster to load in stages. For example, in the app I work on when you first load the page it shows you a login form. While you're filling that in your browser is busy prefetching some assets (components, styles, icons) you'll need after you've logged in. It reduces the waiting time when you're using the app by a few seconds. (To answer the obvious 'what a waste if the user fails to log in!' criticism, that's fewer than 0.2% of log in attempts. Most people benefit.)
youngtaff 6y ago
Challenge is Chrome downloads images at a lower priority than scripts Even bottom of body scripts (unless marked as defer) will download before images

wtallis 6y ago

And since a lot of web developers clearly need some clarification on this: step one means that the important content needs to be included in the initial response to the HTTP GET, and delivered as HTML. You're failing at step 1 if the first thing you serve up is JS to request the real content, or if the first thing you serve up is JS that operates on bundled data to transform it into something the browser can start rendering. If you're obsessively worried about "flash of unstyled content", then recall that the user will always see something after they click the link to your page. Giving them an unresponsive blank screen for an indefinite period of time may not be the best first impression to make.

steve_taylor 6y ago
Native phone apps don’t render their initial screen server-side. Why should web apps? They’re pretty much the same as phone apps, just on a different runtime. I make a distinction between web apps and web sites. Web sites should be server-side rendered (at least the initial render) for obvious reasons.
- no_wizard 6y ago
  Native apps deliver 80-100% of their application at most once, all things being equal. Web applications do not do this, even with aggressive caching and using service workers. I’d also argue that the web is far more accessible than native apps, in that it’s cross platform and independent of any one vendor, currently. So there are valid reasons for considering the page load price of websites/web apps. Also, know your target audience. I’m decidedly not okay with non application sites loading megabytes of JS just to function. However I’m okay with complex functionality provider by my very good and feature rich web based email client need a few MBs of JS to work on initial load, because the features justify the cost in that case It’s not all or nothing
- wtallis 6y ago
  > I make a distinction between web apps and web sites. This is an important distinction to make. But far too many web sites try to place themselves in the "web app" category when they really don't belong. Using a heavyweight JS framework does not automatically make your blog or news site into an app; it just makes your blog or news site slow. I've long thought that browsers should move to formalize the distinction between traditional web sites, and web apps. Apps should get access to the richer, more invasive APIs but only when the user instructs the browser to grant app-level permissions to the site, and at the expense of having stricter security and privacy policies enforced (ie. no third-party cookies, and probably no third-party scripts). > Native phone apps don’t render their initial screen server-side. Why should web apps? An extra RTT to local storage is pretty much always quicker than an extra RTT to a server. And it's not exactly unheard of for a mobile OS to cache a raster image of an app's screen to use the next time the user launches that app or browses through their collection of running apps.
  - kittiepryde 6y ago
    I second that. Browser distinction between web apps and web pages is an awesome idea. I think the hard part is preventing users from learning to always click 'yes' to web-app level permissions just because the page instructs the browser to do so. I don't know the solution to this.
    - wtallis 6y ago
      > I think the hard part is preventing users from learning to always click 'yes' to web-app level permissions just because the page instructs the browser to do so. I don't know the solution to this. The key requirement is that putting a site into app mode must be a tradeoff, not a mere expansion of capabilities/permissions. There has to be a disincentive to discourage non-app sites from unnecessarily requesting app-mode permissions. The most natural way to accomplish this would be restrictions that make it less practical and more expensive to exploit broader permissions to abuse users. Eg. if you want the browser to prompt me to give your site access to my location data, your site should have to surrender the ability to load trackers and ads from somebody else's servers—you should have to serve that up yourself from your own domain, or not at all. This would obviously break a lot about how things are commonly done on the current web, but most of what would be broken is the creepy stuff that we probably shouldn't be tolerating to begin with, like the monstrosity that reCAPTCHA has turned into under Google's stewardship.

onion2k 6y ago

I like idlewords' advice and I'd follow it for websites, but for web apps if there is a point where you can split the code then it is faster to load in stages. For example, in the app I work on when you first load the page it shows you a login form. While you're filling that in your browser is busy prefetching some assets (components, styles, icons) you'll need after you've logged in. It reduces the waiting time when you're using the app by a few seconds. (To answer the obvious 'what a waste if the user fails to log in!' criticism, that's fewer than 0.2% of log in attempts. Most people benefit.)

youngtaff 6y ago

Challenge is Chrome downloads images at a lower priority than scripts Even bottom of body scripts (unless marked as defer) will download before images