Do the arithmetic on the two-page session. Call A the footer's chunk, used on every page, and B the video player's chunk, used only on the home page; both sit in the home page's chunk group, so both are merge candidates [12]. Unmerged, the home page fetches A and B, two requests, and the legal page fetches nothing new because A is cached. Merged, the home page fetches AB in a single request [13], and the legal page needs A, cannot use the merged file, and downloads A on its own [14]. Same request count on both paths, plus one extra copy of the footer on the merged one [17].
So the merge is a bet on how the session ends. It always wins if the visitor loads one page and leaves [13]. Across a navigation it pays only when both pages need both chunks, and then the merged file is reused and a request is saved [15]. The same reasoning extends to sessions of three or more visits [16], where the number of ways a merged file can turn out to be the wrong shape only grows.
The containment is the part worth praising. Merging is restricted to chunks in the same group, and a group is by definition loaded together, so a merge cannot add a byte the page was not already fetching [11]. Over-shipping, the failure that ruled out the one-chunk-for-everything approach [4], is unreachable by construction. What is left is redundancy on later navigations, which is bounded and measurable.
The per-module option is the one that gets underestimated. It over-ships nothing and downloads a shared module once [6], but gzip can only find repeated patterns within a single file, so the same bytes split across hundreds of files compress worse, and according to nextjs.org compression dictionaries help without solving it [7]. Fewer requests and less code do not both arrive; bigger chunks cut requests and lose reusability across pages [8].
Where the reasoning runs out matters for anyone hoping to tune this. nextjs.org names the hard part as deciding which chunks to merge and when merging is truly beneficial [9], and the text available breaks off at "Here are the other poss", before those remaining cases, with no size threshold and no configuration flag for the merge decision in it [19]. What the post supports is a diagnosis, not a setting. When a route feels heavy, the question the design points at is which of its chunks are shared with the pages visitors open next, because across a navigation that is the only thing the merge decision keys on [15].
