The file contains 48,140,288 frames. There are only two colors - white and black.
Only the very center of the image (where the number is) needs to be updated for each frame. This area is 400x65 pixels, so up to 26,000 pixels could be updated on each frame, minus the space between the numbers, etc., so I'd guesstimate an average of 10,000 pixels changing each frame.
Each of those 10,000 pixels can actually only be one of two values, but each occupies exactly one byte when uncompressed. So uncompressed (which GIFs normally are not), it'd be about 481,402,880,000 bytes (~0.5TB), plus the full first frame.
However, GIFs use LZW compression. While I do not know a lot about it, I would guess it would probably do quite well in this case. Perfect 100% compression would mean 1 bit per pixel rather than 8. But let's assume LZW would only manage - say - 2 bits per pixel. That'd quarter the total size, making the total about 120GB.
Of course, this all assumes that it is actually a single GIF, which I believe is extraordinarily unlikely. I would expect it's actually rendered on the fly.
Edit: I'm also assuming that the overall image is actually 1280x960 as the image in the article suggests.
https://en.wikipedia.org/wiki/GIF suggests that long runs of a single color compress rather well.
I still don't see how that is a valid conclusion that follows from what you wrote before it. It is an optimal representation of the data before you would apply any form of compression.
For most frames, only the final digit needs to be updated (or the final two digits, etc)
People have exploited this to create a hackish one-way websocket [1].
I made a live png view counter for funsies with this idea: http://drewgottlieb.net/2012/07/29/real-time-user-count.html
1. http://hyperallergic.com/wp-content/uploads/2015/09/ASLAP-on...