Unfortunately, the efficiency of the proposed approach is only limited to the first 32 KB of the page being compressed. Once we move past the first 32 KB, LZ77'

Unfortunately, the efficiency of the proposed approach is only limited to the first 32 KB of the page being compressed. Once we move past the first 32 KB, LZ77's lookbehind window will no longer include the dictionary and the compression ratio of the rest of the page will stay the same. Pre-seeding the dictionary could have a better effect in an LZ78 scheme where there is an actual dictionary built and stored in memory as opposed to a moving lookbehind window. This also makes me wonder how the dictionary is delivered to the end client. If it's sent with each page request, then it hardly makes any sense as you are hauling an extra 16 KB or 32 KB of the dictionary just to have a better chance of compressing the page's first 32 KB. I wonder if the size of the dictionary itself is factored in the compression benchmarks provided in the article.