well, actually , if one page has UCSS already , it will not generate again unless UCSS has been explicitly purged
so basically , it’s not about the “efficiency” but more like which pages get UCSS first and which get it last.
so let’s say you have 1000 pages , and name them as page1, page2 , page3 … page1000 , for simplicity sake
now imagine you have an UCSS queue that shows page1 , page 2 … page 500
if you don’t do anything and just let it process , then it will process the UCSS one by one from 1 to 500 until you reach the limit or run out of quota
imagine when it finishes the page100’s UCSS , you did something that clean up the queue , and next time by crawler or some visitor , the queue is rebuilt but with a more randomized order , it could be like page101, page200, page333, page444, page321 …etc until it fills up 500 queue
at this point , you have only consumed 100 quota for UCSS
the only difference right now is:
if you don’t do anything , the UCSS will be generated in previous order , from page 1 to page 500 and so on
if you did something , the generation order will be more “random” now , like above example , you got UCSS for page1 to page100 , but next one could be page 101 , then page200 , then page444 …and so on
under the hood , nothing is changed, your credit is still used as it should , only the order and time for when of each page gets UCSS is changed.
