5 ms·

> Nothing that is visible "below the fold" should ever run or load until the page is scrolled down by the site visitor. On the other extreme, completely deferr

> Nothing that is visible "below the fold" should ever run or load until the page is scrolled down by the site visitor. On the other extreme, completely deferring any loading of 'below-the-fold' content until it's visible can also have horrendous consequences, if that loading involves downloading any external resources. Not every visitor can just make further requests near-instantly, and it's those RTTs that really slow pages down, in my experience. Excess API calls are just one (very common) source of excess RTTs. The obvious compromise would be to load 'below-the-fold' content ASAP once all 'above-the-fold' content is finished, unless it's unacceptably heavy for the target device. (Then again, some people still won't be happy: I recently talked to one person who derided the load times of a certain blog, but I found that all of its meaningful content was loaded and visible very quickly: they were only taking issue with the Disqus comment widget at the bottom at the page.)

eastbound 2y ago
I generate a report in our software and 70.000 cells work like a breeze (1000 rows, 70 columns). React just can’t handle adding an input to a cell. It’s unacceptable. React touts its shadow-dom “because it’s much more efficient than updating the DOM directly”, well, that’s a big lie. React is better than all predecessors, but it’s still the wrong abstraction.
- throwaway2037 2y ago
  What about AG Grid? We have apps at work with 1M+ cells. I am pretty sure that AG Grid has React support.
leptons 2y ago
> Not every visitor can just make further requests near-instantly We use a "loading" spinner. People know they have a shitty computer, and they'll wait an extra second instead of spending $1000 on a new computer. That kind of page speed problem isn't one we could ever fix, and it's something the user is typically well aware of being on their end, because every site is slow, not just ours. > completely deferring any loading of 'below-the-fold' content until it's visible can also have horrendous consequences We use a combination of lazy loading and SSR (not React SSR, it's hosted on a custom CMS). Content is SSR to maximize SEO. In some places we'll only render the first 3 or 4 items and then lazy-load the rest if it's a lot of data. Too many DOM elements at page load is also bad for the page speed score. Javascript is lazy-parsed, meaning the text of the script can be loaded in-line, but not parsed until the page is scrolled and the content is in view. Loading the text of a script isn't what slows the page down, it's the parsing of larger scripts that causes page speed issues. When the page scripts can be parsed in smaller chunks, the scrolling experience can be more fluid and the page speed test is satisfied. All images below the fold are lazy loaded. All 3rd party widgets are lazy loaded where possible, because they all suck and they mess with page speed pretty badly. There are lots of other tricks to get to a perfect 100 score on Google Lighthouse. Fortunately for us, "below the fold" is generally easy to accomplish across all of our sites, by the nature of the type of sites we are building. It doesn't work for all kinds of sites, but for ours it works very well.

eastbound 2y ago

I generate a report in our software and 70.000 cells work like a breeze (1000 rows, 70 columns). React just can’t handle adding an input to a cell. It’s unacceptable. React touts its shadow-dom “because it’s much more efficient than updating the DOM directly”, well, that’s a big lie. React is better than all predecessors, but it’s still the wrong abstraction.

throwaway2037 2y ago
What about AG Grid? We have apps at work with 1M+ cells. I am pretty sure that AG Grid has React support.

leptons 2y ago

> Not every visitor can just make further requests near-instantly We use a "loading" spinner. People know they have a shitty computer, and they'll wait an extra second instead of spending $1000 on a new computer. That kind of page speed problem isn't one we could ever fix, and it's something the user is typically well aware of being on their end, because every site is slow, not just ours. > completely deferring any loading of 'below-the-fold' content until it's visible can also have horrendous consequences We use a combination of lazy loading and SSR (not React SSR, it's hosted on a custom CMS). Content is SSR to maximize SEO. In some places we'll only render the first 3 or 4 items and then lazy-load the rest if it's a lot of data. Too many DOM elements at page load is also bad for the page speed score. Javascript is lazy-parsed, meaning the text of the script can be loaded in-line, but not parsed until the page is scrolled and the content is in view. Loading the text of a script isn't what slows the page down, it's the parsing of larger scripts that causes page speed issues. When the page scripts can be parsed in smaller chunks, the scrolling experience can be more fluid and the page speed test is satisfied. All images below the fold are lazy loaded. All 3rd party widgets are lazy loaded where possible, because they all suck and they mess with page speed pretty badly. There are lots of other tricks to get to a perfect 100 score on Google Lighthouse. Fortunately for us, "below the fold" is generally easy to accomplish across all of our sites, by the nature of the type of sites we are building. It doesn't work for all kinds of sites, but for ours it works very well.