Choose a version:
51% The original file has 1240381 bytes (1,211.3k) and is available from the project website.
There you can find the official minified version, too, which brings down the size to 630548 bytes (615.8k, 51%).

After GZIP compression these minified files vary in size:
unpkg
  192072 bytes (187.6k)
CDN
Boot
  158781 bytes (155.1k)
CDN
gzip -6 (default)
  157068 bytes (153.4k)
local copy
jsdelivr
  156885 bytes (153.2k)
CDN
gzip -9
  156442 bytes (152.8k)
local copy
libdeflate -12
  151109 bytes (147.6k)
local copy
zultra
  151015 bytes (147.5k)
local copy
7zip -mx=9 -tgzip
  150961 bytes (147.4k)
local copy
Zopfli
  150597 bytes (147.1k)
local copy
kzip -s0 -rn -b0
  150561 bytes (147.0k)
local copy
pigz -11 -n
  150516 bytes (147.0k)
local copy

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

You will automatically get the smallest ThreeJS 119 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 6288 bytes by using my ThreeJS 119 Zopfli version instead of the best available CDN (4.18% smaller than jsdelivr, 150597 vs. 156885 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 --mls2048 --bsr25 --lazy --ohh

(found August 4, 2020)
Description Value Parameter
iterations 1000000  --i1000000
maximum blocks 8  --mb8
maximum length score 2048  --mls2048
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 4 more bytes (150593 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/r119/build/three.min.js --location | md5sum
84b226149187529ed00eedda3486de5c  -
curl --silent --compressed https://minime.stephan-brumme.com/files/threejs/three-r119.min.zopfli.js.gz | md5sum
84b226149187529ed00eedda3486de5c  -

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

All listed CDNs deliver identical contents:
CDN Size (compressed) MD5 (uncompressed) Timestamp
unpkg 192072 bytes 84b226149187529ed00eedda3486de5c (invalid)
Boot 158781 bytes 84b226149187529ed00eedda3486de5c (invalid)
jsdelivr 156885 bytes 84b226149187529ed00eedda3486de5c July 31, 2020 @ 17:40

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

Other Versions

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

121, 120, 119, 118, 117, 116, 115, 114, 113, 112, 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
150597 bytes -2 bytes zopfli --i1000000 --mls2048 --bsr25 --lazy --ohh August 4, 2020 @ 10:33
150599 bytes -7 bytes zopfli --i100000 --mls2048 --bsr25 --lazy --ohh August 3, 2020 @ 09:55
150606 bytes -2 bytes zopfli --i100000 --mls2048 --bsr18 --lazy --ohh August 3, 2020 @ 09:54
150608 bytes -12 bytes zopfli --i10000 --mls2048 --bsr25 --lazy --ohh July 31, 2020 @ 21:36
150620 bytes -10 bytes zopfli --i1000 --mls2048 --bsr18 --lazy --ohh July 31, 2020 @ 18:12
150630 bytes -21 bytes zopfli --i1000 --mls2048 --bsr25 --lazy --ohh July 31, 2020 @ 18:10
150651 bytes zopfli --i100 --mls2048 --bsr25 --lazy --ohh July 31, 2020 @ 17:45

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

Most recent activity on August 4, 2020 @ 10:54.

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
150769 150782 150801 150809 150801 150765 150815 150800 150764 150836 150755 150670 150813 150796 150754
150706 150731 150696 150710 150704 150754 150768 150750 150692 150755 150730 150663 150766 150714 150736
150702 150738 150764 150761 150710 150725 150673 150685 150686 150854 150689 150693 150703 150735 150868
150880 150885 150719 150679 150697 150710 150662 150689 150849 150790 150791 150731 150813 150826 150848
150706 150848 150867 150865 150690 150679 150673 150684 150681 150638 150630 150698 150862 150700 150857
150711 150721 150733 150700 150698 150696 150694 150817 150850 150866 150692 150712 150817 150833 150723
150685 150858 150681 150869 150716 150684 150681 150719 150681 150860 150702 150700 150878 150823 150691
150693 150691 150729 150701 150690 150674 150685 150869 150685 150797 150802 150690 150792 150806 150760
150691 150695 150745 150720 150690 150682 150682 150678 150687 150692 150669 150688 150795 150725 150646
150690 150687 150721 150724 150725 150679 150826 150864 150693 150861 150651 150688 150795 150803 150713
150879 150708 150730 150866 150718 150675 150684 150682 150687 150694 150672 150699 150878 150700 150722
150847 150781 150736 150678 150707 150696 150855 150716 150686 150864 150619 150695 150793 150816 150759
150707 150768 150732 150701 150716 150684 150683 150860 150685 150683 150648 150687 150721 150723 150724
150861 150682 150756 150870 150872 150684 150673 150685 150695 150833 150693 150708 150789 150822 150749
150683 150699 150726 150730 150722 150683 150681 150676 150666 150684 150606 150691 150723 150695 150643
150782 150778 150779 150777 150786 150780 150791 150795 150778 150863 150695 150691 150762 150854 150649
150726 150703 150726 150730 150691 150687 150675 150682 150676 150671 150667 150691 150762 150692 150721
150780 150764 150729 150800 150789 150676 150792 150791 150787 150774 150716 150689 150768 150824 150723
150729 150700 150733 150733 150686 150678 150679 150691 150666 150672 150702 150689 150720 150724 150724
150684 150673 150730 150703 150725 150677 150785 150681 150780 150775 150773 150702 150816 150831 150780
150784 150722 150727 150730 150715 150682 150678 150695 150777 150769 150597 150690 150777 150814 150719
150673 150678 150735 150729 150688 150687 150677 150688 150684 150692 150651 150688 150709 150698 150718
150700 150699 150727 150719 150690 150682 150683 150689 150780 150766 150676 150708 150763 150693 150720

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 150651 bytes 100%
1,000 150620 bytes -31 bytes 100%
10,000 150608 bytes -12 bytes 100%
100,000 150599 bytes -9 bytes 0.58%
1,000,000 150597 bytes -2 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
150561 bytes -36 bytes (-0.02%)
151300 bytes +703 bytes (+0.47%) +739 bytes
151258 bytes +661 bytes (+0.44%) +697 bytes
150980 bytes +383 bytes (+0.25%) +419 bytes
150872 bytes +275 bytes (+0.18%) +311 bytes
150880 bytes +283 bytes (+0.19%) +319 bytes
150835 bytes +238 bytes (+0.16%) +274 bytes
150753 bytes +156 bytes (+0.10%) +192 bytes
150701 bytes +104 bytes (+0.07%) +140 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 - for example, your browser actually supports it !
Algorithm Program Parameters Size Compared To Best Zopfli
ZPAQ (Wikipedia) zpaq zpaq -method 69 100259 bytes -50338 bytes (-33.43%)
RAR (proprietary) RAR rar a -m5 -md64m -mc63:128t -mt1 116162 bytes -34435 bytes (-22.87%)
PPMd (Wikipedia) 7zip 7za a -mx=9 -m0=ppmd 121800 bytes -28797 bytes (-19.12%)
Brotli (Wikipedia) brotli brotli -q 11 127439 bytes -23158 bytes (-15.38%)
LZMA2 (Wikipedia) xz xz -9 128228 bytes -22369 bytes (-14.85%)
Burrows-Wheeler transform (Wikipedia) bzip2 bzip2 -9 133539 bytes -17058 bytes (-11.33%)
Zstandard (Wikipedia) zstd zstd -19 134627 bytes -15970 bytes (-10.60%)

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