Production database substantially bigger than Dev
Compression can cause you to see different table and index sizes for the same data across two tables. 

You asked in a comment if there's any reason not to apply compression. The general trade-off for page compression is that your tables take up less space and you can fit more data into memory at a cost of CPU overhead. As a very general rule, if your server has CPU to spare you might as well test your workload before and after applying compression to see what happens. There are even some workloads which will get more efficient from a CPU perspective after applying compression. In short, "it depends".

Another reason not to use compression is if you aren't licensed for it. Your development server could be using developer edition which allows data compression but your production server could be using standard edition, which doesn't allow data compression until SQL Server 2016 SP1.