Choose a version:
48% The original file has 785469 bytes (767.1k) and is available from the project website.
There you can find the official minified version, too, which brings down the size to 379586 bytes (370.7k, 48%).

After GZIP compression these minified files vary in size:
Boot
  112660 bytes (110.0k)
CDN
cdnjs
  95111 bytes (92.9k)
CDN
gzip -6 (default)
  94166 bytes (92.0k)
local copy
cdnhttps
  94124 bytes (91.9k)
CDN
gzip -9
  93795 bytes (91.6k)
local copy
libdeflate -12
  90930 bytes (88.8k)
local copy
7zip -mx=9 -tgzip
  90850 bytes (88.7k)
local copy
pigz -11 -n
  90648 bytes (88.5k)
local copy
kzip -s0 -rn -b8
  90560 bytes (88.4k)
local copy
Zopfli
  90489 bytes (88.4k)
local copy
Zopfli (defluff)
  90487 bytes (88.4k)
local copy

perma-link to the smallest file on my server:
http://minime.stephan-brumme.com/files/threejs/three-r52.min.js

You will automatically get the smallest ThreeJS 52 file, ETag caching is available and
if your browser doesn't support GZIP decompression then the uncompressed version will be sent.

Currently best Zopfli settings

Save 3635 bytes by using my ThreeJS 52 Zopfli version instead of the best available CDN (4.02% smaller than cdnhttps, 90489 vs. 94124 bytes):
You can use my super-compressed files for whatever purpose you like as long as you respect the library's original license agreement.
There are no restrictions from my side - but please avoid hot-linking if you run a high-traffic website.

These command-line settings yielded the best compression ratio so far (Linux version of zopfli-krzymod):
zopfli --i1000000 --mb8 --mls128 --bsr20 --lazy --ohh

(found February 16, 2017)
Description Value Parameter
iterations 1000000  --i1000000
maximum blocks 8  --mb8
maximum length score 128  --mls128
block splitting recursion 20  --bsr20
lazy matching in LZ77 yes  --lazy
optimized Huffman headers yes  --ohh
initial random W for iterations 1  --rw1
initial random Z for iterations 2  --rz2

Even Smaller Files Thanks To Defluff

Zopfli's output can be further optimized by the defluff tool.
In this particular case, defluff saves 2 more bytes (90487 bytes).

Verify file integrity

After decompression, my uncompressed files are identical to the original ones:

MD5:
curl --silent --compressed https://raw.githubusercontent.com/mrdoob/three.js/r52/build/three.min.js --location | md5sum
a2d7df78f02b88938fd48b4868574685  -
curl --silent --compressed http://minime.stephan-brumme.com/files/threejs/three-r52.min.zopfli.js.gz | md5sum
a2d7df78f02b88938fd48b4868574685  -

SHA1:
curl --silent --compressed https://raw.githubusercontent.com/mrdoob/three.js/r52/build/three.min.js --location | sha1sum
d4e1d68e1a04e3dd1c079b03c063a467bdb84b52  -
curl --silent --compressed http://minime.stephan-brumme.com/files/threejs/three-r52.min.zopfli.js.gz | sha1sum
d4e1d68e1a04e3dd1c079b03c063a467bdb84b52  -

All listed CDNs deliver identical contents:
CDN Size (compressed) MD5 (uncompressed) Timestamp
Boot 112660 bytes a2d7df78f02b88938fd48b4868574685 (invalid)
cdnjs 95111 bytes a2d7df78f02b88938fd48b4868574685 (invalid)
cdnhttps 94124 bytes a2d7df78f02b88938fd48b4868574685 December 24, 2015 @ 07:36

Note: only the MD5 hashes are shown to keep things simple.

Other Versions

Available ThreeJS versions at minime.stephan-brumme.com:

92, 91, 90, 89, 88, 87, 86, 85, 84, 83, 82, 81, 80, 79, 78, 77, 76, 75, 74, 73, 72, 71, 70, 69, 68, 67, 66, 65, 64, 63, 62, 61, 60, 59, 58, 57, 56, 55, 54, 53, 52, 51, 50

The project site contains an overview how well these versions were compressed.
Other interesting projects are AngularJS, BackboneJS, Bootstrap, D3, Dojo, Ember, jQuery, Knockout, lodash, React, Socket.IO, UnderscoreJS and Vue.

Changelog

Best Zopfli parameters so far:
Size Improvement Parameters Found
90489 bytes -4 bytes zopfli --i1000000 --mls128 --bsr20 --lazy --ohh February 16, 2017 @ 16:29
90493 bytes -1 byte zopfli --i100000 --mls128 --bsr20 --lazy --ohh December 28, 2015 @ 16:50
90494 bytes -10 bytes zopfli --i100000 --mls1024 --bsr11 --lazy --ohh December 22, 2015 @ 20:01
90504 bytes -5 bytes zopfli --i10000 --mls1024 --bsr11 --lazy --ohh November 17, 2015 @ 06:05
90509 bytes -1 byte zopfli --i10000 --mls128 --bsr7 --lazy --ohh November 17, 2015 @ 06:00
90510 bytes -2 bytes zopfli --i10000 --mls16 --bsr12 --lazy --ohh November 17, 2015 @ 05:03
90512 bytes -5 bytes zopfli --i10000 --mls64 --bsr18 --lazy --ohh November 17, 2015 @ 04:48
90517 bytes -1 byte zopfli --i1000 --mls16 --bsr12 --lazy --ohh November 16, 2015 @ 23:12
90518 bytes -3 bytes zopfli --i1000 --mls64 --bsr18 --lazy --ohh November 16, 2015 @ 09:31
90521 bytes -14 bytes zopfli --i1000 --mls128 --bsr20 --lazy --ohh November 16, 2015 @ 09:29
90535 bytes zopfli --i100 --mls128 --bsr20 --lazy --ohh November 15, 2015 @ 11:20

If there are multiple parameter sets yielding the same compressed size, only the first one found is shown.

Most recent activity on February 16, 2017 @ 16:47.

Heatmaps

This Zopfli heatmap visualizes how compression changes when modifying the --bsr and --mls parameter.
Cell's contents is the best filesize achieved (in bytes, hover with mouse over cells to see number of iterations).

Good parameters are green, bad are red. The best and worst are bold as well.
The brightness of the blue background color indicates how many iterations were processed:
10,000, 100,000 or 1,000,000.
bsr \ mls
2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768
bsr \ mls
2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768
90657 90671 90637 90567 90690 90691 90692 90697 90687 90689 90683 90696 90686 90696 90694
90619 90621 90592 90563 90574 90569 90553 90674 90692 90563 90644 90585 90654 90667 90662
90595 90663 90568 90628 90592 90528 90534 90705 90685 90676 90564 90563 90573 90663 90678
90596 90557 90555 90559 90563 90574 90509 90672 90577 90680 90557 90594 90612 90665 90666
90651 90624 90629 90637 90632 90608 90608 90678 90574 90546 90561 90618 90584 90702 90661
90577 90608 90613 90556 90587 90568 90677 90680 90686 90551 90566 90556 90606 90657 90667
90657 90658 90615 90603 90553 90556 90553 90679 90679 90553 90641 90669 90631 90665 90672
90580 90554 90627 90547 90565 90586 90528 90674 90688 90494 90547 90701 90538 90726 90679
90581 90621 90561 90510 90635 90522 90514 90675 90613 90603 90546 90557 90595 90663 90668
90645 90583 90621 90598 90642 90612 90515 90680 90677 90556 90556 90596 90641 90667 90668
90654 90652 90622 90562 90602 90587 90566 90681 90679 90613 90555 90596 90618 90705 90672
90600 90557 90611 90608 90572 90577 90518 90678 90689 90511 90574 90695 90602 90705 90667
90625 90642 90621 90567 90600 90615 90511 90675 90569 90612 90561 90556 90586 90666 90687
90585 90564 90618 90557 90594 90576 90518 90698 90684 90564 90560 90532 90571 90662 90667
90570 90560 90569 90605 90549 90512 90583 90674 90572 90558 90570 90557 90601 90701 90672
90618 90661 90626 90556 90631 90619 90514 90675 90563 90613 90554 90607 90593 90661 90667
90585 90593 90571 90549 90572 90521 90489 90675 90677 90565 90551 90567 90589 90657 90668
90622 90574 90610 90600 90550 90547 90516 90681 90678 90612 90579 90563 90611 90665 90675
90583 90565 90562 90554 90496 90593 90576 90678 90568 90565 90545 90564 90597 90666 90661
90564 90608 90572 90598 90563 90558 90576 90680 90564 90615 90555 90607 90600 90663 90669
90567 90560 90613 90551 90554 90564 90516 90680 90560 90617 90552 90563 90592 90666 90663
90574 90577 90582 90562 90538 90562 90574 90677 90579 90564 90574 90565 90599 90665 90677
90561 90576 90565 90571 90542 90560 90577 90679 90687 90543 90575 90569 90617 90665 90670

Due to the Monte Carlo design of my search algorithm, not all parameters have reached the same number of iterations yet:
Iterations Min. Bytes Reduction Coverage
100 90535 bytes 100%
1,000 90517 bytes -18 bytes 100%
10,000 90504 bytes -13 bytes 100%
100,000 90493 bytes -11 bytes 0.87%
1,000,000 90489 bytes -4 bytes 0.29%
10,000,000

KZIP has far less options available for tuning/optimization. I only played around with the number of blocks (parameter -n):
Blocks Min. Bytes Compared To Best Zopfli Compared To Best KZIP
90581 bytes +92 bytes (+0.10%) +21 bytes
90801 bytes +312 bytes (+0.34%) +241 bytes
90790 bytes +301 bytes (+0.33%) +230 bytes
90729 bytes +240 bytes (+0.27%) +169 bytes
90721 bytes +232 bytes (+0.26%) +161 bytes
90624 bytes +135 bytes (+0.15%) +64 bytes
90628 bytes +139 bytes (+0.15%) +68 bytes
90604 bytes +115 bytes (+0.13%) +44 bytes
90560 bytes +71 bytes (+0.08%)

Non-DEFLATE Algorithms

Archivers based on completely different compression algorithms often produce superior results.
Unfortunately, browsers only support gzip compression at the moment.
Algorithm Program Parameters Size Compared To Best Zopfli
ZPAQ (Wikipedia) zpaq zpaq -method 69 61791 bytes -28698 bytes (-31.71%)
RAR (proprietary) RAR rar a -m5 -md64m -mc63:128t -mt1 71684 bytes -18805 bytes (-20.78%)
Brotli (Wikipedia) brotli brotli -q 11 76362 bytes -14127 bytes (-15.61%)
LZMA2 (Wikipedia) xz xz -9 76772 bytes -13717 bytes (-15.16%)
PPMd (Wikipedia) 7zip 7za a -mx=9 -m0=ppmd 76956 bytes -13533 bytes (-14.96%)
ZSTD (Wikipedia) zstd zstd -19 82066 bytes -8423 bytes (-9.31%)
Burrows-Wheeler transform (Wikipedia) bzip2 bzip2 -9 83148 bytes -7341 bytes (-8.11%)

Detailled Analysis

I wrote a DEFLATE decoder in Javascript. Click the button below to start a client-side analysis of the smallest gzipped files (may take a second):


Notes: pigz is a fast open source multi-threaded implementation of gzip written by one of the original authors of gzip.
However, when using compression level 11, pigz actually switches to the slower Zopfli algorithm and isn't multi-threaded anymore.
KrzyMOD's extensions to Zopfli offer the highest level of configuration and is therefore used for my brute-force search.
Ken Silverman wrote the closed-source KZIP compression program and Jonathon Fowler ported it to Linux.
Defluff was created by Joachim Henke; DeflOpt is a tool by Ben Jos Walbeehm.

website made by Stephan Brumme in 2015 and still improving in 2018.
all timestamps are displayed in central european time. see my changelog.
no flash, not even images or external css files - and everything squeezed into a single html file.
which was handsomely compressed before releasing it into the wild internet - obviously.

please visit my homepage and my blog, too.
email: minime (at) stephan-brumme.com