Hey team, for FS load + FS filter optimization, I typically set the collection list size to 100 to minimize the number of page loads needed.
However I notice that in some of the FS cloneables like the car store, the page size is set to a smaller amount like this;
Which requires more page loads;
Is there an official best practice here?
Hey @memetican! It depends on if you are using the speed boost setting or not, as this setup improves the page load speed the more pages you have.
Having 100 items per page may reduce the number of paginated pages but this hurts the site loading as all 100 items need to be loaded and rendered, instead of only loading say 50 and having the double amount of pages.
In my opinion, it is best to find a middle point, depending on the end design, and looking to always improve user experience.
Faster than pre-rendered? 
I’d always assumed the speed boost metrics were comparing the with-and-without speed boost scenarios.
I need to experiment more- I usually set the limit to 100, plus use speed boost, but then limit the number of items that appear in the page by adjusting the FS load page size, usually by breakpoint.
In my head, that maximizes the data load performance ( fewest fetches, though larger pages ), without sacrificing anything on the rendering side, i.e. the user isn’t force-fed 100-item pages.
I could be missing something entirely obvious, so please let me know if you see it.
I did just realize I’m still thinking in terms of HTTP/1.1’s 6 concurrent download limit, while Webflow’s servers are now HTTP 2 which I believe is 100 concurrent.
That is a clever setup, and I see the reason behind setting the 100 items per page = fewer fetches. My fear with this is that all 100 items will be rendered upon page load anyway but then readjusted by the Attributes API.
Fewer fetches but more rendering for the first page load
As you say, more testing would be needed with this setup, then decide with the pros/cons of each.
