Choose a version:
50% The original file has 1194042 bytes (1,166.1k) and is available from the project website.
There you can find the official minified version, too, which brings down the size to 597015 bytes (583.0k, 50%).

After GZIP compression these minified files vary in size:
unpkg
  183175 bytes (178.9k)
CDN
cdnjs
  151296 bytes (147.8k)
CDN
gzip -6 (default)
  149735 bytes (146.2k)
local copy
jsdelivr
  149635 bytes (146.1k)
CDN
gzip -9
  149205 bytes (145.7k)
local copy
libdeflate -12
  144101 bytes (140.7k)
local copy
7zip -mx=9 -tgzip
  144056 bytes (140.7k)
local copy
kzip -s0 -rn -b0
  143697 bytes (140.3k)
local copy
pigz -11 -n
  143620 bytes (140.3k)
local copy
Zopfli
  143582 bytes (140.2k)
local copy
Zopfli (defluff)
  143580 bytes (140.2k)
local copy

perma-link to the smallest file on my server:
http://minime.stephan-brumme.com/files/threejs/three-r110.min.js (or via HTTPS)

You will automatically get the smallest ThreeJS 110 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 6053 bytes by using my ThreeJS 110 Zopfli version instead of the best available CDN (4.22% smaller than jsdelivr, 143582 vs. 149635 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 --mls4096 --bsr25 --lazy --ohh

(found November 2, 2019)
Description Value Parameter
iterations 1000000  --i1000000
maximum blocks 8  --mb8
maximum length score 4096  --mls4096
block splitting recursion 25  --bsr25
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 (143580 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/r110/build/three.min.js --location | md5sum
835d136879eebb8b933418e38df09a60  -
curl --silent --compressed https://minime.stephan-brumme.com/files/threejs/three-r110.min.zopfli.js.gz | md5sum
835d136879eebb8b933418e38df09a60  -

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

All listed CDNs deliver identical contents:
CDN Size (compressed) MD5 (uncompressed) Timestamp
unpkg 183175 bytes 835d136879eebb8b933418e38df09a60 (invalid)
cdnjs 151296 bytes 835d136879eebb8b933418e38df09a60 November 19, 2019 @ 20:59
jsdelivr 149635 bytes 835d136879eebb8b933418e38df09a60 October 31, 2019 @ 11:13

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

Other Versions

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

111, 110, 109, 108, 107, 106, 105, 104, 103, 102, 101, 100, 99, 98, 97, 96, 95, 94, 93, 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
143582 bytes -5 bytes zopfli --i1000000 --mls4096 --bsr25 --lazy --ohh November 2, 2019 @ 11:33
143587 bytes -10 bytes zopfli --i100000 --mls4096 --bsr25 --lazy --ohh November 1, 2019 @ 12:55
143597 bytes -3 bytes zopfli --i10000 --mls4096 --bsr25 --lazy --ohh October 31, 2019 @ 14:24
143600 bytes -25 bytes zopfli --i10000 --mls4096 --bsr9 --lazy --ohh October 31, 2019 @ 13:59
143625 bytes -2 bytes zopfli --i1000 --mls4096 --bsr9 --lazy --ohh October 31, 2019 @ 11:40
143627 bytes -19 bytes zopfli --i1000 --mls4096 --bsr25 --lazy --ohh October 31, 2019 @ 11:40
143646 bytes zopfli --i100 --mls4096 --bsr25 --lazy --ohh October 31, 2019 @ 11:20

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

Most recent activity on November 19, 2019 @ 20:59.

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
143815 143803 143850 143806 143898 143823 143943 143960 143934 143892 143929 143827 143835 143845 143859
143797 143786 143828 143829 143786 143726 143819 143818 143839 143783 143759 143772 143842 143850 143850
143804 143794 143761 143761 143764 143766 143788 143775 143772 143770 143770 143763 143902 143913 143728
143800 143802 143799 143803 143804 143802 143802 143692 143805 143696 143780 143726 143848 143815 143852
143774 143803 143779 143756 143762 143760 143754 143758 143753 143859 143781 143882 143855 143785 143829
143751 143753 143783 143785 143784 143783 143764 143772 143783 143761 143772 143589 143817 143873 143857
143767 143773 143767 143753 143771 143834 143773 143739 143825 143709 143749 143767 143905 143881 143834
143763 143760 143761 143806 143796 143818 143772 143772 143702 143686 143767 143750 143830 143847 143868
143758 143791 143788 143786 143783 143783 143767 143812 143765 143715 143783 143728 143837 143809 143820
143762 143794 143761 143763 143762 143740 143761 143773 143773 143841 143900 143782 143870 143846 143868
143773 143770 143779 143772 143784 143789 143761 143759 143760 143760 143775 143743 143718 143690 143788
143791 143794 143766 143762 143789 143763 143760 143759 143758 143695 143765 143721 143763 143762 143913
143751 143751 143757 143784 143750 143781 143733 143801 143802 143754 143770 143687 143802 143775 143809
143762 143805 143790 143765 143775 143795 143752 143779 143773 143761 143723 143698 143831 143825 143856
143779 143799 143749 143772 143792 143786 143757 143783 143771 143770 143725 143764 143803 143779 143831
143793 143787 143764 143771 143708 143709 143678 143771 143800 143767 143742 143800 143827 143828 143767
143790 143772 143790 143759 143763 143762 143712 143811 143823 143774 143778 143729 143716 143774 143866
143788 143783 143751 143776 143774 143785 143744 143810 143763 143698 143740 143612 143831 143825 143854
143766 143779 143749 143761 143752 143765 143757 143809 143823 143700 143765 143768 143838 143777 143833
143771 143768 143773 143785 143711 143724 143746 143773 143836 143685 143748 143712 143842 143835 143765
143792 143782 143776 143775 143797 143782 143756 143822 143768 143782 143767 143582 143856 143826 143850
143787 143778 143786 143787 143772 143785 143754 143767 143779 143827 143790 143767 143829 143781 143724
143790 143802 143754 143790 143758 143776 143755 143752 143762 143826 143755 143768 143858 143777 143693

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 143646 bytes 100%
1,000 143625 bytes -21 bytes 100%
10,000 143597 bytes -28 bytes 100%
100,000 143587 bytes -10 bytes 0.58%
1,000,000 143582 bytes -5 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
143697 bytes +115 bytes (+0.08%)
144319 bytes +737 bytes (+0.51%) +622 bytes
144267 bytes +685 bytes (+0.48%) +570 bytes
144076 bytes +494 bytes (+0.34%) +379 bytes
143963 bytes +381 bytes (+0.27%) +266 bytes
143984 bytes +402 bytes (+0.28%) +287 bytes
143905 bytes +323 bytes (+0.22%) +208 bytes
143833 bytes +251 bytes (+0.17%) +136 bytes
143840 bytes +258 bytes (+0.18%) +143 bytes

Non-DEFLATE Algorithms

Archivers based on completely different compression algorithms often produce superior results.
Unfortunately, browsers only support gzip compression at the moment.
However, support for Brotli is constantly growing - but your browser doesn't support it.
Algorithm Program Parameters Size Compared To Best Zopfli
ZPAQ (Wikipedia) zpaq zpaq -method 69 96291 bytes -47291 bytes (-32.94%)
RAR (proprietary) RAR rar a -m5 -md64m -mc63:128t -mt1 111086 bytes -32496 bytes (-22.63%)
PPMd (Wikipedia) 7zip 7za a -mx=9 -m0=ppmd 116591 bytes -26991 bytes (-18.80%)
Brotli (Wikipedia) brotli brotli -q 11 121860 bytes -21722 bytes (-15.13%)
LZMA2 (Wikipedia) xz xz -9 122508 bytes -21074 bytes (-14.68%)
Burrows-Wheeler transform (Wikipedia) bzip2 bzip2 -9 127884 bytes -15698 bytes (-10.93%)
Zstandard (Wikipedia) zstd zstd -19 128683 bytes -14899 bytes (-10.38%)

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 2019.
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

All trademarks are property of their respective owners. You know, the boring legal stuff.