Cell width

I'm don't understand the purpose of the Cell Width setting. Why would you ever change it? It seems like if I want a particular map to be 40 cells wide instead of 20, I'd upload the map at double size (2800 px instead of 1400 px). What am I missing?

There is a big difference if the players can walk 20 or 40 units of movement. 

I'm having trouble explaining my question. I meant: If I want players to be able to walk 40 cells, then I'd create a page that is 2800px wide. I'd upload a map that is roughly that size and stretch it to 2800 px. If I want them to walk 80 cells, then I'd create a page that is 80 cells and 5600px wide, then I'd upload the same map and stretch it to 5600px. If I want them to walk 80 cells, is there any advantage to creating a 40 cell (2800px) wide page, uploading the same map, and then setting the grid size to to 35px? Isn't the effect the same?

If your map is too large (in px used on the VTT), the game can exhibit decreases in performance. So, lets say that you wanted to have a single battle map for something taking place over 2000 squares x 2000 squares (140,000 px X 140,000 px). This is exponentially larger than the largest recommended map size, and twice the height and width as the largest map I've personally ever successfully loaded. The limit here is not the number of squares (although it does have some impact), but the sheer size of the map. If however, we reduce the size of the cell, we can use a map with an area a fourth the size (70,000 px X 70,000 px). This is still a massive map, but is much more manageable for systems to load than the full sized map. And of course, we can go lower to make it even more manageable. Note: The sizes shown above are way past what I would ever recommend running with purely to demonstrate the principle. EDIT: And an alternative use. Not everyone has the skills (I sure as heck don't) or time to create their own custom battle maps. If you wanted to use a battle map, but couldn't get it at the proper pixel resolution, you could change the square size to use it at the lower resolution, but still get the same play space out of it.

In my example I was assuming you'd upload the same JPG map in both the 40x40 and 80x80 example, though in the larger example it would be stretched more... Are you saying that the grid size can impact performance, independent of the file size of the map? And that if I upload that same map to a 40x40 grid with 1/2 size cells (so I'm back to 80x80), it will have better performance than uploading to 80x80? I don't know if I'm making sense.

Yes, although at the sizes you listed, you may not see an impact. Essentially, the page has a pixel size. Let's say your cell width is set to 70px (1 x 70px), and you make a map that is 100 squares X 100 squares. This map is actually 7000px X 7000px wide. Any image that you put on this map is then up/downsampled depending on it's original size and what percentage of the page it takes up. So, let's say we have an image that is 10px X 10px natively and we (for some reason) want this image to be stretched across the entire map. The image is still 10px X 10px natively, but we've now enlarged it to 7000px X 7000px and so it is using resources as if it was 7000px X 7000px, not 10px X 10px. Going to ping someone more knowledgeable than me on this to make sure I'm giving you the right information here as well.

That's basically the gist of it. My recommendation would be to keep the cell width at normal and cut your map into four slices, aligning them on the page. Something similar to this is done on some of the marketplace modules, since module designers (WotC, Paizo), design for print, and VTT performance isn't even on their radar. I hate what the token interface does when you change the cell width, and avoid changing it whenever possible.

Does that mean 4x 50x50 pics take up less resources than 1x 100x100, even though both take up 10,000 area? I guess i can see why it might. 

Generally, several smaller files are easier to deal with than one big one.  Easier to cache and page out as needed.  Of course, everything is a balance and you can take that too far.

Oh, I didn't understand your question. Sorry! Glad others have more knowledge about this filesizeperformancebalancewizardry. I learned something. Thanks! :) 

This was enlightening. My maps aren't that large, but still, very interesting and a good practice to keep in mind.

I've found that when a map image has an existing grid at a different resolution, that it's often easier to re-size the roll20 grid to fit the image rather than the other way round, especially when the image grid doesn't line up neatly with the edge of image. I've also found it very helpful when using the dynamic lighting feature to set the grid very small, use snap-to-grid drawings to make sure that I have the correct angles and placement for the lighting map I'm drawing, and the revert the grid to it's default size before playing.