4 ms·

What I wonder about is what's the best: 1) lightweight pages, that link out to lots of stuff (javascript libraries, images, ...). AJAX request to load page con

What I wonder about is what's the best: 1) lightweight pages, that link out to lots of stuff (javascript libraries, images, ...). AJAX request to load page content. 2) more heavyweight page, but everything into one. Only inline javascript, <img src="data:image/gif;base64,R0lGODlhEgA... Everything into one. Because page weight doesn't really matter. Time to display matters.

h2odragon 4y ago
Satellite users have long latency, each separate resource request waits 500ms before a connection can begin. Argues for "all in one". However: the user may be throttled, in which case any connection is likely to have an interruption about 3MB of data transfer. So you get bit coming and going.
cout 4y ago
Time to interact matters as much as (perhaps even more than?) time to display; I would rather wait a little bit longer for the page to display than have the page display immediately but behave erratically until everything has settled.
- lelandfe 4y ago
  Every site is different, but in general I have seen the greatest correlation between bounce rate and FCP. Ensuring sites are quickly responsive also matters, of course. But users will straight up leave after a few seconds of blank.
maxloh 4y ago
Resources could be cached with (1). So subsequent visits will be a lot faster.
- giantrobot 4y ago
  Until you make any sort of update. Many web apps are constantly seeing updates pushed. So there's no guarantee when any particular user loads the app they will have a valid cache. Browsers also no longer share caches between origin domains, so even if App A and App B load a resource from the same CDN they won't share the cached version. On mobile caches tend to be evicted with higher frequency then the desktop. This all adds up to relying on cached resources for page load performance is fragile at best and completely broken at worst. Relying on caches ends up with a worse experience on average because whenever a user loads the app they may get wildly different load performance based on the state of the cache.
  - perilunar 4y ago
    I would think that an empty cache between visits, but a full cache between different pages of the same visit would be a realistic assumption. i.e. not relying on the cache to speed up initial page load, but accepting it will speed up subsequent pages.
    - giantrobot 4y ago
      A slow initial page load won't necessarily get you subsequent page loads. Resources used in the same visit will be resident in memory rather than loaded from the cache. The cache will be hit if the load takes place in a new tab or window. Also if your uncached page is slow loading, then any of the multitude of reasons a returning user has an empty/invalid cache, they get a nice unexpected slow load experience. Even two page loads a day apart might have had the cache invalidated by an update on the server. Use patterns don't neatly align with deployment patterns.

h2odragon 4y ago

Satellite users have long latency, each separate resource request waits 500ms before a connection can begin. Argues for "all in one". However: the user may be throttled, in which case any connection is likely to have an interruption about 3MB of data transfer. So you get bit coming and going.

cout 4y ago

Time to interact matters as much as (perhaps even more than?) time to display; I would rather wait a little bit longer for the page to display than have the page display immediately but behave erratically until everything has settled.

lelandfe 4y ago
Every site is different, but in general I have seen the greatest correlation between bounce rate and FCP. Ensuring sites are quickly responsive also matters, of course. But users will straight up leave after a few seconds of blank.

maxloh 4y ago

Resources could be cached with (1). So subsequent visits will be a lot faster.

giantrobot 4y ago
Until you make any sort of update. Many web apps are constantly seeing updates pushed. So there's no guarantee when any particular user loads the app they will have a valid cache. Browsers also no longer share caches between origin domains, so even if App A and App B load a resource from the same CDN they won't share the cached version. On mobile caches tend to be evicted with higher frequency then the desktop. This all adds up to relying on cached resources for page load performance is fragile at best and completely broken at worst. Relying on caches ends up with a worse experience on average because whenever a user loads the app they may get wildly different load performance based on the state of the cache.
- perilunar 4y ago
  I would think that an empty cache between visits, but a full cache between different pages of the same visit would be a realistic assumption. i.e. not relying on the cache to speed up initial page load, but accepting it will speed up subsequent pages.
  - giantrobot 4y ago
    A slow initial page load won't necessarily get you subsequent page loads. Resources used in the same visit will be resident in memory rather than loaded from the cache. The cache will be hit if the load takes place in a new tab or window. Also if your uncached page is slow loading, then any of the multitude of reasons a returning user has an empty/invalid cache, they get a nice unexpected slow load experience. Even two page loads a day apart might have had the cache invalidated by an update on the server. Use patterns don't neatly align with deployment patterns.