<h1>JavaScript Bundler Benchmark 2026: Webpack vs Rollup vs Rolldown vs ESBuild vs Farm vs Parcel vs Snowpack vs RSPack</h1>
This year we have decided to re-test the results from <a href="/blog/post/performance-of-js-bundlers-in-2025">2025</a>.
As in the previous year, all benchmarks were run under the
same controlled conditions. We used a single machine with identical hardware
and software configurations for each test, keeping tool versions fixed to
avoid version-related performance differences. Each bundler compiled the
same minimal React project containing only one <code>index.jsx</code> file, ensuring
that the benchmark focused on bundler overhead rather than application 
complexity. Every test was executed 10 times, and we calculated averages
to reduce the impact of random system fluctuations. While this setup provides
a clear comparison, it’s important to note some limitations: we did not
measure warm-cache performance, advanced configurations, or cross-platform 
differences such as Windows or macOS environments.
<h2>Test Environment &amp; Setup</h2>
We reused the same React project but now we will bundle it using:
<ul>
<li><a href="https://webpack.js.org">Webpack</a> (version 5.105.4)</li>
<li><a href="https://rollupjs.org/">Rollup</a> (version 4.48.0)</li>
<li><a href="https://esbuild.github.io/">ESBuild</a> (version 0.27.3)</li>
<li><a href="https://www.farmfe.org">Farm</a> (version 1.6.7)</li>
<li><a href="https://rolldown.rs">Rolldown</a> (version 1.0.0-rc.6)</li>
<li><a href="https://www.snowpack.dev/">Snowpack</a> (version 3.8.8)</li>
<li><a href="https://parceljs.org/">Parcel</a> (version 2.16.4)</li>
<li><a href="https://rspack.rs/">RSPack</a> (version 1.7.6)</li>
</ul>
System Configuration
<ul>
<li>OS: Linux ArchHost 6.18.13-arch1-1</li>
<li>Node.js: v22.14.0</li>
<li>Cores: 16</li>
<li>RAM: 16 GB (2 × 8 GB)</li>
</ul>
<h2>Benchmark Command</h2>
This benchmark measures cold build performance, meaning no previous
cache or build artifacts were used. Many modern bundlers such as
Webpack, RSPack, and Parcel heavily optimize incremental builds, so
their performance during development may differ significantly from
these results.
We used <code>/usr/bin/time -v</code> to measure peak RAM usage and CPU
load during the bundling process:
<pre><code class="hljs language-bash">for i in {1..10}; do
/usr/bin/time -v yarn build:esbuild 2&gt;&amp;1 | awk &#x27; # replaced with corresponding bundler
 /Maximum resident set size/ {ram=$6/1024}
 /Elapsed $wall clock$ time/ {seconds=$0; sub(/.*: /,&quot;&quot;,seconds)}
 /Percent of CPU this job got/ {cpu=$0; sub(/.*: /,&quot;&quot;,cpu)}
 END {printf &quot;Peak RAM: %.2f MB\nCPU Load: %s\nSeconds: %s\n&quot;, ram, cpu, seconds}&#x27;
done
</code></pre><h2>Bundler Performance Results</h2>
<h3>RAM Performance</h3>
<table>
<thead>
<tr>
<th></th>
<th>I</th>
<th>II</th>
<th>III</th>
<th>IV</th>
<th>V</th>
<th>VI</th>
<th>VII</th>
<th>VIII</th>
<th>IX</th>
<th>X</th>
</tr>
</thead>
<tbody><tr>
<td>ESBuild v0.27.3</td>
<td>70.45 MB</td>
<td>69.91 MB</td>
<td>69.48 MB</td>
<td>69.95 MB</td>
<td>69.72 MB</td>
<td>69.75 MB</td>
<td>69.32 MB</td>
<td>69.69 MB</td>
<td>70.08 MB</td>
<td>69.00 MB</td>
</tr>
<tr>
<td>Webpack v5.105.4</td>
<td>276.52 MB</td>
<td>274.02 MB</td>
<td>277.04 MB</td>
<td>274.40 MB</td>
<td>274.80 MB</td>
<td>275.27 MB</td>
<td>274.68 MB</td>
<td>278.59 MB</td>
<td>274.01 MB</td>
<td>272.69 MB</td>
</tr>
<tr>
<td>Rollup v4.48.0</td>
<td>357.73 MB</td>
<td>362.33 MB</td>
<td>367.27 MB</td>
<td>381.02 MB</td>
<td>357.71 MB</td>
<td>427.97 MB</td>
<td>360.65 MB</td>
<td>360.67 MB</td>
<td>417.84 MB</td>
<td>417.89 MB</td>
</tr>
<tr>
<td>Rolldown v1.0.0-rc.6</td>
<td>175.20 MB</td>
<td>167.57 MB</td>
<td>167.23 MB</td>
<td>168.74 MB</td>
<td>173.33 MB</td>
<td>171.36 MB</td>
<td>169.12 MB</td>
<td>166.23 MB</td>
<td>166.34 MB</td>
<td>178.21 MB</td>
</tr>
<tr>
<td>Farm v1.6.7</td>
<td>250.58 MB</td>
<td>249.99 MB</td>
<td>250.42 MB</td>
<td>255.43 MB</td>
<td>255.07 MB</td>
<td>284.44 MB</td>
<td>250.88 MB</td>
<td>261.84 MB</td>
<td>257.49 MB</td>
<td>254.38 MB</td>
</tr>
<tr>
<td>Snowpack v3.8.8</td>
<td>1118.01 MB</td>
<td>1135.81 MB</td>
<td>1073.27 MB</td>
<td>1096.96 MB</td>
<td>975.15 MB</td>
<td>1070.26 MB</td>
<td>1135.87 MB</td>
<td>1061.93 MB</td>
<td>1216.10 MB</td>
<td>1063.56 MB</td>
</tr>
<tr>
<td>Parcel v2.16.4</td>
<td>277.23 MB</td>
<td>299.34 MB</td>
<td>299.88 MB</td>
<td>300.23 MB</td>
<td>301.37 MB</td>
<td>299.62 MB</td>
<td>300.39 MB</td>
<td>300.01 MB</td>
<td>300.21 MB</td>
<td>301.19 MB</td>
</tr>
<tr>
<td>RSPack v1.7.6</td>
<td>387.02 MB</td>
<td>393.48 MB</td>
<td>393.72 MB</td>
<td>390.38 MB</td>
<td>384.49 MB</td>
<td>395.74 MB</td>
<td>401.41 MB</td>
<td>393.58 MB</td>
<td>388.91 MB</td>
<td>390.15 MB</td>
</tr>
</tbody></table>
<h3>CPU Performance</h3>
<table>
<thead>
<tr>
<th></th>
<th>I</th>
<th>II</th>
<th>III</th>
<th>IV</th>
<th>V</th>
<th>VI</th>
<th>VII</th>
<th>VIII</th>
<th>IX</th>
<th>X</th>
</tr>
</thead>
<tbody><tr>
<td>ESBuild v0.27.3</td>
<td>117%</td>
<td>117%</td>
<td>116%</td>
<td>117%</td>
<td>117%</td>
<td>116%</td>
<td>117%</td>
<td>117%</td>
<td>116%</td>
<td>116%</td>
</tr>
<tr>
<td>Webpack v5.105.4</td>
<td>172%</td>
<td>186%</td>
<td>185%</td>
<td>185%</td>
<td>185%</td>
<td>186%</td>
<td>187%</td>
<td>186%</td>
<td>184%</td>
<td>186%</td>
</tr>
<tr>
<td>Rollup v4.48.0</td>
<td>204%</td>
<td>206%</td>
<td>205%</td>
<td>205%</td>
<td>204%</td>
<td>203%</td>
<td>208%</td>
<td>207%</td>
<td>206%</td>
<td>206%</td>
</tr>
<tr>
<td>Rolldown v1.0.0-rc.6</td>
<td>106%</td>
<td>128%</td>
<td>126%</td>
<td>125%</td>
<td>125%</td>
<td>128%</td>
<td>124%</td>
<td>125%</td>
<td>126%</td>
<td>128%</td>
</tr>
<tr>
<td>Farm v1.6.7</td>
<td>144%</td>
<td>149%</td>
<td>148%</td>
<td>146%</td>
<td>148%</td>
<td>142%</td>
<td>147%</td>
<td>146%</td>
<td>148%</td>
<td>146%</td>
</tr>
<tr>
<td>Snowpack v3.8.8</td>
<td>162%</td>
<td>175%</td>
<td>168%</td>
<td>166%</td>
<td>163%</td>
<td>167%</td>
<td>174%</td>
<td>158%</td>
<td>170%</td>
<td>157%</td>
</tr>
<tr>
<td>Parcel v2.16.4</td>
<td>202%</td>
<td>209%</td>
<td>208%</td>
<td>208%</td>
<td>210%</td>
<td>209%</td>
<td>212%</td>
<td>207%</td>
<td>208%</td>
<td>209%</td>
</tr>
<tr>
<td>RSPack v1.7.6</td>
<td>151%</td>
<td>192%</td>
<td>191%</td>
<td>183%</td>
<td>192%</td>
<td>192%</td>
<td>192%</td>
<td>191%</td>
<td>193%</td>
<td>192%</td>
</tr>
</tbody></table>
Now, the question is - why some of the results for CPU are showing more than 100%. The reason is that in Linux it shows the cores. When it reaches more than 100% - that means, 
that the process is using 2 cores, when it reaches more than 200 - then process is using 3 cores and so on. As we can see, Rollup and Parcel are requiring much more cores for 
their runtime, which is due to their architecture, and plain JavaScript implementation. ESBuild is written in Go, RSPack and Rolldown are written in Rust, which is visible on the 
usage of the cores. 
<h3>Execution time (in seconds)</h3>
<table>
<thead>
<tr>
<th></th>
<th>I</th>
<th>II</th>
<th>III</th>
<th>IV</th>
<th>V</th>
<th>VI</th>
<th>VII</th>
<th>VIII</th>
<th>IX</th>
<th>X</th>
</tr>
</thead>
<tbody><tr>
<td>ESBuild v0.27.3</td>
<td>0.20</td>
<td>0.19</td>
<td>0.20</td>
<td>0.19</td>
<td>0.19</td>
<td>0.20</td>
<td>0.19</td>
<td>0.19</td>
<td>0.19</td>
<td>0.19</td>
</tr>
<tr>
<td>Webpack v5.105.4</td>
<td>2.04</td>
<td>1.97</td>
<td>1.96</td>
<td>1.97</td>
<td>1.96</td>
<td>1.96</td>
<td>2.00</td>
<td>1.98</td>
<td>1.97</td>
<td>2.03</td>
</tr>
<tr>
<td>Rollup v4.48.0</td>
<td>4.47</td>
<td>4.42</td>
<td>4.41</td>
<td>4.44</td>
<td>4.43</td>
<td>4.42</td>
<td>4.45</td>
<td>4.47</td>
<td>4.40</td>
<td>4.43</td>
</tr>
<tr>
<td>Rolldown v1.0.0-rc.6</td>
<td>0.27</td>
<td>0.27</td>
<td>0.27</td>
<td>0.27</td>
<td>0.27</td>
<td>0.28</td>
<td>0.28</td>
<td>0.28</td>
<td>0.28</td>
<td>0.27</td>
</tr>
<tr>
<td>Farm v1.6.7</td>
<td>0.78</td>
<td>0.76</td>
<td>0.77</td>
<td>0.77</td>
<td>0.78</td>
<td>0.77</td>
<td>0.77</td>
<td>0.76</td>
<td>0.77</td>
<td>0.79</td>
</tr>
<tr>
<td>Snowpack v3.8.8</td>
<td>7.37</td>
<td>7.41</td>
<td>7.30</td>
<td>7.12</td>
<td>7.13</td>
<td>7.03</td>
<td>7.02</td>
<td>7.33</td>
<td>7.20</td>
<td>6.85</td>
</tr>
<tr>
<td>Parcel v2.16.4</td>
<td>0.72</td>
<td>0.72</td>
<td>0.71</td>
<td>0.72</td>
<td>0.74</td>
<td>0.75</td>
<td>0.75</td>
<td>0.75</td>
<td>0.75</td>
<td>0.75</td>
</tr>
<tr>
<td>RSPack v1.7.6</td>
<td>1.57</td>
<td>1.56</td>
<td>1.56</td>
<td>1.58</td>
<td>1.58</td>
<td>1.59</td>
<td>1.58</td>
<td>1.57</td>
<td>1.57</td>
<td>1.59</td>
</tr>
</tbody></table>
<h2>Security of the packages &amp; traceability</h2>
As with any open source solution, every time that you or your company is depending from public libraries, 
you need to understand the risks that it brings. One of such risks is the fact that with the big amount of the packages you expose yourself to a bigger vector of attacks, such as <a href="https://en.wikipedia.org/wiki/Typosquatting">typosquatting</a>. 
Also, when you have a lot of dependencies, you need to make sure that you use the latest patched version, to reduce the risks towards 
zero-day vulnerabilities. In order to check that, let us see the situation with dependencies for the bundlers that we have mentioned 
previously. 
Dependencies will be counted in yarn.lock as in the following screenshot, meaning we will count only the 1st-level children:
<img src="/blog/2026/bundlers-comparison/webpack-dependencies.png" alt="webpack dependencies">
<h3>Dependencies downloaded</h3>
<table>
<thead>
<tr>
<th>Bundler</th>
<th>Dependencies</th>
</tr>
</thead>
<tbody><tr>
<td>ESBuild v0.27.3</td>
<td>1</td>
</tr>
<tr>
<td>Webpack v5.105.4</td>
<td>26</td>
</tr>
<tr>
<td>Rollup v4.48.0</td>
<td>2</td>
</tr>
<tr>
<td>Rolldown v1.0.0-rc.6</td>
<td>2</td>
</tr>
<tr>
<td>Farm v1.04 (cli + core)</td>
<td>31</td>
</tr>
<tr>
<td>Snowpack v3.8.8</td>
<td>53</td>
</tr>
<tr>
<td>Parcel v2.16.4</td>
<td>15</td>
</tr>
<tr>
<td>RSPack v1.7.6 (cli+core)</td>
<td>7</td>
</tr>
</tbody></table>
Also, those packages are usually occupying disk space of your device. Let us look in the table of 
the memory used on disk. We will measure the total amount of the packages installed in an empty folder 
by running <code>yarn add &lt;name-of-bundler&gt;</code>, where <code>&lt;name-of-bundler</code> will be changed to the ones mentioned previously
<table>
<thead>
<tr>
<th>Bundler</th>
<th>Size</th>
</tr>
</thead>
<tbody><tr>
<td>ESBuild v0.27.3</td>
<td>11M</td>
</tr>
<tr>
<td>Webpack v5.105.4</td>
<td>29M</td>
</tr>
<tr>
<td>Rollup v4.48.0</td>
<td>6.8M</td>
</tr>
<tr>
<td>Rolldown v1.0.0-rc.6</td>
<td>41M</td>
</tr>
<tr>
<td>Farm v1.04 (cli + core)</td>
<td>183M</td>
</tr>
<tr>
<td>Snowpack v3.8.8</td>
<td>58M</td>
</tr>
<tr>
<td>Parcel v2.16.4</td>
<td>217M</td>
</tr>
<tr>
<td>RSPack v1.7.6 (cli+core)</td>
<td>151M</td>
</tr>
</tbody></table>
<h2>Average Benchmark Results: 2026</h2>
Now, based from the previous results let&#39;s calculate the average for the bundlers and compare them with the 2025 results:
<table>
<thead>
<tr>
<th>Bundler</th>
<th>RAM 2026</th>
<th>CPU 2026</th>
<th>Execution Time (seconds) 2026</th>
<th>RAM 2025</th>
<th>CPU 2025</th>
</tr>
</thead>
<tbody><tr>
<td>ESBuild</td>
<td>62.76M</td>
<td>117%</td>
<td>0.19</td>
<td>91.79M</td>
<td>117%</td>
</tr>
<tr>
<td>Webpack</td>
<td>219.88M</td>
<td>184%</td>
<td>1.98</td>
<td>294.35M</td>
<td>187%</td>
</tr>
<tr>
<td>Rollup</td>
<td>381.11M</td>
<td>205%</td>
<td>4.43</td>
<td>392.81M</td>
<td>212%</td>
</tr>
<tr>
<td>Rolldown</td>
<td>170.33</td>
<td>112%</td>
<td>0.27</td>
<td></td>
<td></td>
</tr>
<tr>
<td>Farm</td>
<td>257.05M</td>
<td>146%</td>
<td>0.77</td>
<td>235.96M</td>
<td>149%</td>
</tr>
<tr>
<td>Snowpack</td>
<td>1094.69M</td>
<td>166%</td>
<td>7.18</td>
<td></td>
<td></td>
</tr>
<tr>
<td>Parcel</td>
<td>297.95M</td>
<td>208%</td>
<td>0.74</td>
<td></td>
<td></td>
</tr>
<tr>
<td>RSPack</td>
<td>391.89</td>
<td>187%</td>
<td>1.58</td>
<td></td>
<td></td>
</tr>
</tbody></table>
<img src="/blog/2026/bundlers-comparison/js_bundlers_ram_usage_2026.jpeg" alt="JavaScript Bundlers RAM Usage 20226">
<img src="/blog/2026/bundlers-comparison/js_bundlers_cpu_usage_2026.jpeg" alt="JavaScript Bundlers CPU Usage 20226">
<h2>Running the test locally</h2>
You can find the project on <a href="https://github.com/FallenAngel97/bundlers-comparison">Github</a>
Run the following commands: 
<pre><code class="hljs language-bash">git clone https://github.com/FallenAngel97/bundlers-comparison
cd bundlers-comparison
yarn install
# run the commands for benchmarks noted at the top with /usr/bin/time
</code></pre><h2>Results</h2>
Although ESBuild shows the best performance in this benchmark,
Webpack still dominates the ecosystem due to its mature plugin
architecture and large community.
Newer bundlers such as Rolldown and RSPack are rapidly gaining
adoption because they aim to provide Webpack compatibility with
Rust-level performance.
Also, we can see that Snowpack is standing a bit differently with it&#39;s results. 
It&#39;s due to it&#39;s philosophy. Snowpack, contrary to webpack, is providing you the possibility 
to run the application unbundled. This means, faster local development, because your dependencies 
are not changing. As we can see during the build, this is exacly the reason why it&#39;s performing 
differently to it&#39;s competitors. It is processing each dependency and converts it to the browser-compatible 
module, so that your browser can cache dependencies and optimize the bandwidth
Background photo by <a href="https://unsplash.com/@homaappliances?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Homa Appliances</a> on <a href="https://unsplash.com/photos/a-factory-with-a-lot-of-machines-in-it-5hPe-Tr2wog?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a>

Performance of JS Bundlers in 2026

<h1>JavaScript Bundler Performance Benchmark 2025: Webpack vs Rollup vs ESBuild vs Farm</h1>
Looking for the fastest JavaScript bundler in 2025?
In 2025, you cannot imagine the frontend job without using some kind of 
bundler. But have you ever thought, how many resources do you need to 
run it, in order to compile your frontend application? We benchmarked Webpack, Rollup, ESBuild, and Farm to see how much RAM and CPU each tool uses while bundling a simple React project.
To ensure fair and consistent results, all benchmarks were run under the
same controlled conditions. We used a single machine with identical hardware
and software configurations for each test, keeping tool versions fixed to
avoid version-related performance differences. Each bundler compiled the
same minimal React project containing only one <code>index.jsx</code> file, ensuring
that the benchmark focused on bundler overhead rather than application 
complexity. Every test was executed 10 times, and we calculated averages
to reduce the impact of random system fluctuations. While this setup provides
a clear comparison, it’s important to note some limitations: we did not
measure warm-cache performance, advanced configurations, or cross-platform 
differences such as Windows or macOS environments.
<h2>Test Environment &amp; Setup</h2>
We created a minimal React project (<code>index.jsx</code>) and bundled it using:
<ul>
<li><a href="https://webpack.js.org">Webpack</a> (version 5.101.3)</li>
<li><a href="https://rollupjs.org/">Rollup</a> (version 4.48.0)</li>
<li><a href="https://esbuild.github.io/">ESBuild</a> (version 0.25.9)</li>
<li><a href="https://www.farmfe.org">Farm</a> (version 1.6.7)</li>
</ul>
System Configuration
<ul>
<li>OS: Linux ArchHost 6.16.4-arch1-1</li>
<li>Node.js: v22.14.0</li>
<li>Cores: 16</li>
<li>RAM: 16 GB (2 × 8 GB)</li>
</ul>
<h2>Benchmark Command</h2>
We used <code>/usr/bin/time -v</code> to measure peak RAM usage and CPU
load during the bundling process:
<pre><code class="hljs language-bash">for i in {1..10}; do
/usr/bin/time -v yarn build:esbuild 2&gt;&amp;1 | awk &#x27; # replaced with corresponding bundler
 /Maximum resident set size/ {ram=$6/1024}
 /Percent of CPU this job got/ {cpu=$0; sub(/.*: /,&quot;&quot;,cpu)}
 END {printf &quot;Peak RAM: %.2f MB\nCPU Load: %s\n&quot;, ram, cpu}&#x27;
done
</code></pre><h2>Bundler Performance Results</h2>
<h3>Rollup Performance</h3>
<table>
<thead>
<tr>
<th>RAM</th>
<th>CPU</th>
</tr>
</thead>
<tbody><tr>
<td>420.66 Mb</td>
<td>210%</td>
</tr>
<tr>
<td>376.51 Mb</td>
<td>211%</td>
</tr>
<tr>
<td>420.25 MB</td>
<td>213%</td>
</tr>
<tr>
<td>369.96 MB</td>
<td>212%</td>
</tr>
<tr>
<td>370.79 MB</td>
<td>216%</td>
</tr>
<tr>
<td>368.41 MB</td>
<td>211%</td>
</tr>
<tr>
<td>371.82 MB</td>
<td>211%</td>
</tr>
<tr>
<td>431.74 MB</td>
<td>210%</td>
</tr>
<tr>
<td>375.54 MB</td>
<td>212%</td>
</tr>
<tr>
<td>371.10 MB</td>
<td>213%</td>
</tr>
<tr>
<td>444.08 MB</td>
<td>212%</td>
</tr>
</tbody></table>
<h3>Webpack Performance</h3>
<table>
<thead>
<tr>
<th>RAM</th>
<th>CPU</th>
</tr>
</thead>
<tbody><tr>
<td>298.85 MB</td>
<td>187%</td>
</tr>
<tr>
<td>281.30 MB</td>
<td>189%</td>
</tr>
<tr>
<td>297.50 MB</td>
<td>186%</td>
</tr>
<tr>
<td>294.16 MB</td>
<td>185%</td>
</tr>
<tr>
<td>298.09 MB</td>
<td>185%</td>
</tr>
<tr>
<td>297.80 MB</td>
<td>185%</td>
</tr>
<tr>
<td>300.30 MB</td>
<td>187%</td>
</tr>
<tr>
<td>295.35 MB</td>
<td>188%</td>
</tr>
<tr>
<td>293.68 MB</td>
<td>188%</td>
</tr>
<tr>
<td>295.55 MB</td>
<td>189%</td>
</tr>
<tr>
<td>294.28 MB</td>
<td>188%</td>
</tr>
</tbody></table>
<h3>Farm Performance</h3>
<table>
<thead>
<tr>
<th>RAM</th>
<th>CPU</th>
</tr>
</thead>
<tbody><tr>
<td>262.68 MB</td>
<td>149%</td>
</tr>
<tr>
<td>261.49 MB</td>
<td>152%</td>
</tr>
<tr>
<td>261.98 MB</td>
<td>146%</td>
</tr>
<tr>
<td>260.79 MB</td>
<td>150%</td>
</tr>
<tr>
<td>257.18 MB</td>
<td>150%</td>
</tr>
<tr>
<td>259.48 MB</td>
<td>146%</td>
</tr>
<tr>
<td>259.43 MB</td>
<td>151%</td>
</tr>
<tr>
<td>257.86 MB</td>
<td>149%</td>
</tr>
<tr>
<td>259.36 MB</td>
<td>147%</td>
</tr>
<tr>
<td>257.00 MB</td>
<td>145%</td>
</tr>
<tr>
<td>258.05 MB</td>
<td>150%</td>
</tr>
</tbody></table>
<h3>ESBuild Performance</h3>
<table>
<thead>
<tr>
<th>RAM</th>
<th>CPU</th>
</tr>
</thead>
<tbody><tr>
<td>91.71 MB</td>
<td>115%</td>
</tr>
<tr>
<td>91.55 MB</td>
<td>114%</td>
</tr>
<tr>
<td>91.10 MB</td>
<td>117%</td>
</tr>
<tr>
<td>91.14 MB</td>
<td>118%</td>
</tr>
<tr>
<td>91.86 MB</td>
<td>118%</td>
</tr>
<tr>
<td>92.61 MB</td>
<td>120%</td>
</tr>
<tr>
<td>91.88 MB</td>
<td>118%</td>
</tr>
<tr>
<td>91.41 MB</td>
<td>117%</td>
</tr>
<tr>
<td>92.12 MB</td>
<td>119%</td>
</tr>
<tr>
<td>92.14 MB</td>
<td>114%</td>
</tr>
<tr>
<td>92.16 MB</td>
<td>118%</td>
</tr>
</tbody></table>
<h2>Average Benchmark Results: 2025</h2>
Now, based from the previous results let&#39;s calculate the average for the bundlers
<table>
<thead>
<tr>
<th>Bundler</th>
<th>RAM</th>
<th>CPU</th>
</tr>
</thead>
<tbody><tr>
<td>Webpack</td>
<td>294.35 Mb</td>
<td>187%</td>
</tr>
<tr>
<td>Rollup</td>
<td>392.81 Mb</td>
<td>212%</td>
</tr>
<tr>
<td>ESBuild</td>
<td>91.79 Mb</td>
<td>117%</td>
</tr>
<tr>
<td>Farm</td>
<td>235.96 Mb</td>
<td>149%</td>
</tr>
</tbody></table>
<h2>Key Takeaways</h2>
<ul>
<li>ESBuild is the fastest bundler with the lowest RAM usage and CPU consumption.</li>
<li>Farm is the second most efficient option for modern projects.</li>
<li>Webpack and Rollup remain popular but are heavier on resources.</li>
</ul>
If performance and build speed matter in 2025, ESBuild or Farm should be your top choices.
You can find the project on <a href="https://github.com/FallenAngel97/bundlers-comparison">Github</a>
Photo by <a href="https://unsplash.com/@simonkadula?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">Simon Kadula</a> on <a href="https://unsplash.com/photos/a-factory-filled-with-lots-of-orange-machines-8gr6bObQLOI?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">Unsplash</a>

Performance of JS Bundlers in 2025

<h1>How to deal with the pace of changing the Android SDK?</h1>
In the modern day of mobile development, where everything is modular, 
and the updates is shipped rapidly, you can easily be lost in the 
process of manual updates of your dependencies. While there exists 
solutions like [Renovate] and [Dependabot], the best application of
these solutions are to maintain the external dependencies and libraries.
But how can we make sure, that if Android compileSDK and targetSDK are 
up-to-date, if the application logic is not shifting that often, as 
the SDK&#39;-s? Well, today we would like to share our journey with this, 
welcome aboard!
<h2>Determining the source of truth for Android SDK versions</h2>
Upon deep investigation and the <a href="https://android.googlesource.com/platform/tools/base/+/master/sdklib/src/main/java/com/android/sdklib/SdkManager.java">Android source code</a>, our team have found,
that SDKManager is fetching data from <a href="https://dl.google.com/android/repository/repository2-1.xml">https://dl.google.com/android/repository/repository2-1.xml</a>.
This XML contains a lot of information, but the most important to us is &quot;Android SDK Platform XX&quot;, where XX -
is the Android SDK version. Exactly this information we will need to determine 
if our application is behind the official SDK&#39;s provided by Android development team.
For ease of use, there&#39;s a docker image already with necessary steps done: ghcr.io/fallenangel97/android-fetcher:master
<h2>Process of bumping the SDK&#39;-s in the application code</h2>
Now, when we know, where to look at the most up-to-date Android SDK version, 
we need to find a way how to specify the logic to update necessary API&#39;s. 
In order to do that, we will create <code>scripts</code> folder inside the root folder of the 
necessary Android application. Now, whenever the docker image will detect versions of Android SDK, 
it will send them to that folder as an arguments, so that we can read them and 
construct the logic for updating necessary files. 
Example of such script can look like this:
<pre><code class="hljs language-bash">#!/bin/sh
# filename: &lt;project-root&gt;/scripts/bump-android-version.sh

base_path=$(dirname -- &quot;$0&quot;)
node $base_path/js/bump-version.js $1
</code></pre><pre><code class="hljs language-javascript">const { execSync } = require(&#x27;child_process&#x27;);
const { readFileSync, writeFileSync } = require(&#x27;fs&#x27;);
const path = require(&#x27;path&#x27;);

const [,,remoteVersions] = process.argv;

const parsedVersions = JSON.parse(remoteVersions);
const latestAndroidVersion = Math.max(...parsedVersions);

const fileContents = readFileSync(path.join(__dirname,&#x27;../../app/build.gradle&#x27;)).toString();

const targetSdkRegex = /targetSdkVersion ([0-9]+)/;
const compileSdkRegex = /compileSdkVersion ([0-9]+)/;

const match = targetSdkRegex.exec(fileContents);

if (match.length &gt; 0) {
	const [,version] = match;

	if (parseInt(latestAndroidVersion) &gt; parseInt(version)) {
		console.log(&#x27;Replacing the android version...&#x27;);
		const newText = fileContents
			.replace(targetSdkRegex, &quot;targetSdkVersion &quot; + latestAndroidVersion)
			.replace(compileSdkRegex, &quot;compileSdkVersion &quot; + latestAndroidVersion);
		writeFileSync(path.join(__dirname, &#x27;../../app/build.gradle&#x27;), newText);
		execSync(&#x27;git add .&#x27;);
		execSync(`git checkout -b bump-android-${latestAndroidVersion}`);
		execSync(`git commit -m &#x27;Bumped targetSdkVersion and compileSdkVersion to ${latestAndroidVersion}&#x27;`);
		execSync(`git push -o merge_request.create -o merge_request.merge_when_pipeline_succeeds origin HEAD`);
	} else {
		console.log(&#x27;The version is up to date, exiting&#x27;);
	}
}
</code></pre>Of course, you should adjust the scripts up to your requirements.
<h2>Putting everything together as a periodic task</h2>
We&#39;ll use a wonderful <a href="https://crazymax.dev/swarm-cronjob/">docker-cron project</a> in order to connect our pieces together. 
Let&#39;s run our process for bumping Android version every 8 hours, so we can define the logic for swarm-cronjob like this:
<pre><code class="hljs language-yml">version: &quot;3.8&quot;

services:
 android_sdk_bumper:
 image: &quot;ghcr.io/fallenangel97/android-fetcher:master&quot;
 healthcheck:
 disable: true
 environment:
 - REPOSITORIES=&quot;&lt;path-to-your-git-repo&gt;&quot;
 volumes:
 - &quot;/root/.ssh:/root/.ssh&quot;
 deploy:
 mode: replicated
 replicas: 0
 labels:
 - &quot;swarm.cronjob.enable=true&quot;
 - &quot;swarm.cronjob.schedule=0 */8 * * *&quot;
 restart_policy:
 condition: none
</code></pre>Make sure, that you have generated SSH keys and added them in your Git 
service in order for the &quot;git clone&quot; to work properly, otherwise it might fail
You are welcome to create a PR for the project here: <a href="https://github.com/FallenAngel97/android-list-fetcher">https://github.com/FallenAngel97/android-list-fetcher</a>
Photo by <a href="https://unsplash.com/@jxk?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">Jan Kopřiva</a> on <a href="https://unsplash.com/photos/red-and-black-metal-tool-aHSejd0UGEo?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">Unsplash</a>

Automatically bump Android SDK versions

<h1>Preparing your blog for Telegram Instant View (IV)</h1>
If you are looking into making your website/blog more appealing for your 
customers, you can look into how social media/messengers are presenting 
your content to customers. Luckily, some of them allow you to control that 
process a bit. Let&#39;s dive into Telegram Instant Views and follow their 
<a href="https://instantview.telegram.org/">official tutorial</a>.
<h2>Pre-requisites:</h2>
<ol>
<li>Have an account in Telegram</li>
<li>Have a publicly accessible website</li>
</ol>
<h2>Example of implementation of Telegram IV</h2>
When we are starting to work on Telegram IV, we need to know the HTML part that 
we want to display and which section/domain we want to be understandable by IV 
system. 
First, we need to define the version of IV, by <code>~version: &quot;2.1&quot;</code>. 
Then, we will limit IV to work only on all links, which are located on <a href="https://decodeapps.pp.ua/blog">https://decodeapps.pp.ua/blog</a>,
we will do that by using <a href="https://instantview.telegram.org/docs#path">?path</a> condition. 
Every DeCODE blog post has an &lt;h1&gt; tag, we can use it for the title of IV. Description 
we will extract using the XPath specification, and for the date display - we will use the function <code>@datetime</code>
provided by Telegram IV engine. 
<pre><code>body: //div[has-class(&quot;content&quot;)]
title: $body//h1
description: /html/head/meta[@name=&quot;description&quot;]/@content
@datetime(0): ($body//span)[1]
published_date: $@
</code></pre>If you will also define <code>channel</code> property, you will also display a link to 
your public Telegram channel
<img src="/blog/telegram-instant-view/channel-join-button.png" alt="Telegram channel join button">
When you will declare <code>published_date</code>, you will have something like this: 
<img src="/blog/telegram-instant-view/date-parsed.png" alt="Published date of Instant View">
In order to remove all elements, which you don&#39;t want to show in IV, you can 
use <code>@remove</code> function.
<h2>Complete code for Telegram IV</h2>
<pre><code>~version: &quot;2.1&quot;

?path: /blog/.+

channel: &quot;@decode_news&quot;
body: //div[has-class(&quot;content&quot;)]
title: $body//h1
description: /html/head/meta[@name=&quot;description&quot;]/@content
@datetime(0): ($body//span)[1]
published_date: $@

&lt;figure&gt;: $body//p[.//img]

@remove: //div[@id=&quot;tags&quot;]
@remove: ($body//span)[1]
@remove: //div[@id=&quot;social_shares&quot;]
</code></pre>Photo by <a href="https://unsplash.com/@pluyar?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">Shane Aldendorff</a> on <a href="https://unsplash.com/photos/gray-and-black-metal-electronic-device-lot-3AzL-IR3v7Y?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">Unsplash</a>

How to prepare your website for Telegram Instant View

How to automate uploading of Android applications to Amazon

<h1>How to automate build and testing in Flutter with Gitlab</h1>
Let&#39;s use Docker image by <a href="https://github.com/PlugFox/docker_flutter">Plugfox</a>, which is targeting Flutter and comes with all dependencies required, such as Android SDK, JVM and so on. 
In this example, we&#39;ll be using free tier of Gitlab, and in order to minify the load on the flow, we&#39;ll define the GIT_DEPTH variable, which should speed up the 
cloning of repository alongside other environment variables, which are required during the building of <a href="https://developer.android.com/guide/app-bundle">APK/AppBundle</a>.
<h2>Prerequisites for this pipeline</h2>
<ol>
<li>Have a <a href="https://developer.android.com/studio/publish/app-signing#generate-key">android keystore</a> file. You can quickly generate it using following command:</li>
</ol>
<pre><code class="hljs language-bash">keytool -genkey -v -keystore example.keystore -alias alias_name -keyalg RSA -keysize 2048 -validity 10000
</code></pre><ol start="2">
<li>Setup your <a href="https://docs.gitlab.com/ee/ci/secure_files/">Gitlab secure files</a>.
</li>
<li>Prepare integration test, for example
</li>
</ol>
<pre><code class="hljs language-dart">import &#x27;package:flutter_test/flutter_test.dart&#x27;;
import &#x27;package:integration_test/integration_test.dart&#x27;;

void main() {
 IntegrationTestWidgetsFlutterBinding.ensureInitialized();

 group(&#x27;example test&#x27;, () {
 testWidgets(&#x27;dummy test&#x27;, (tester) async {
 expect(10, greaterThanOrEqualTo(2));
 });
 });
}
</code></pre><h2>Building release appbundle</h2>
In order to build the Flutter application, we will use the keystore, which you configured at the prerequisite 1 and upload it to 
the Gitlab secure files. In order to download secure files, Gitlab requires to execute shell script, let&#39;s run it: 
<pre><code class="hljs language-bash">curl --silent &quot;https://gitlab.com/gitlab-org/incubation-engineering/mobile-devops/download-secure-files/-/raw/main/installer&quot; | bash
</code></pre>Now, let&#39;s configure the signing process. In order to do so, we will use key.properties file. Make sure, that your build.gradle inside flutter 
application. Check the <code>android/app/build.gradle</code> file, and make sure it has something like this:
<pre><code class="hljs language-gradle">def keystoreProperties = new Properties()
def keystorePropertiesFile = rootProject.file(&#x27;key.properties&#x27;)
if (keystorePropertiesFile.exists()) {
 keystoreProperties.load(new FileInputStream(keystorePropertiesFile))
}

android {
 // rest of configuration...

 signingConfigs {
 release {
 keyAlias keystoreProperties[&#x27;keyAlias&#x27;]
 keyPassword keystoreProperties[&#x27;keyPassword&#x27;]
 storeFile keystoreProperties[&#x27;storeFile&#x27;] ? file(keystoreProperties[&#x27;storeFile&#x27;]) : null
 storePassword keystoreProperties[&#x27;storePassword&#x27;]
 }
 }
}
</code></pre>Now, let&#39;s prepopulate the key.properties file with necessary details for signing to work
<pre><code class="hljs language-bash">echo &quot;storeFile=$(pwd)/key.keystore&quot; &gt; android/key.properties
echo &quot;storePassword=$KEYSTORE_PASSWORD&quot; &gt;&gt; android/key.properties
echo &quot;keyAlias=$ALIAS&quot; &gt;&gt; android/key.properties ## Testing Flutter application in CI system
echo &quot;keyPassword=$KEY_PASSWORD&quot; &gt;&gt; android/key.properties
</code></pre>Finally, you can execute building command like this:
<pre><code class="hljs language-bash">flutter build appbundle --no-pub --obfuscate --split-debug-info=debug-info-appbundle # if you need appbundle format
flutter build apk --no-pub --obfuscate --split-debug-info=debug-info-apk # if you need apk
</code></pre><h2>Implementing CI testing in Flutter</h2>
In order to test, make sure that your Android device is visible with the <code>adb devices</code> command. The following steps assume that you have followed this step. 
Optional 
If you would like to precache the Android SDK, you can use following command for extracting the <code>compileSdk</code> value and pass it to sdkmanager for installation
<pre><code class="hljs language-bash">cat android/app/build.gradle | grep compileSdk | tr -d -c 0-9 | /opt/android/cmdline-tools/latest/bin/sdkmanager &quot;platforms;android-$(cat -)&quot;
</code></pre>Usually, tests assume that your screen is unlocked, so we can schedule unlocking of your screen beforehands by inputting following command:
<pre><code class="hljs language-bash">adb shell input keyevent 26 &amp;&amp; adb shell input touchscreen swipe 930 880 930 380
</code></pre>Optional 
If you want to have the screen opened upon installation of your application, you can modify your <code>MainActivity.kt</code> with the following changes: 
<pre><code class="hljs language-kotlin">override fun onCreate(savedInstanceState: Bundle?) {
 super.onCreate(savedInstanceState);
 if (BuildConfig.DEBUG) { // we don&#x27;t want to have this behavior on release builds, so keep it only to tests
 val keyguardManager = getSystemService(Context.KEYGUARD_SERVICE) as KeyguardManager;
 if (Build.VERSION.SDK_INT &gt;= Build.VERSION_CODES.P) {
 setShowWhenLocked(true)
 setTurnScreenOn(true)
 keyguardManager.requestDismissKeyguard(this, null)
 } else {
 // For older versions of Android, you can use the deprecated method as a fallback
 keyguardLock?.disableKeyguard()
 window.addFlags(WindowManager.LayoutParams.FLAG_TURN_SCREEN_ON or WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON);
 }
 }
}
</code></pre>We also were having timeouts while connecting to the device and Flutter VM. We solved it using following command: 
<pre><code class="hljs language-bash">sed -i &#x27;/).timeout(/,/);/{ s/).timeout.*/);/; t; d;}&#x27; /opt/flutter/packages/flutter_tools/lib/src/test/integration_test_device.dart
</code></pre>Finally, execute <code>flutter test path/to/your_test.dart</code> and you&#39;re ready to go!
<h2>Complete .gitlab-ci.yml</h2>
Here&#39;s the complete .gitlab-ci.yml for building and testing of Flutter applications
<pre><code class="hljs language-yaml">image: plugfox/flutter:3.10.6-android

variables:
 GIT_DEPTH: &quot;1&quot;
 KEYSTORE_PASSWORD: your_keystore_password
 ALIAS: your_alias
 KEY_PASSWORD: your_key_password

stages:
 - build
 - test
 - deploy

e2e_test:
 stage: test 
 interruptible: true
 only:
 - merge_requests
 script: 
 - flutter pub get
 - flutter precache --no-web
 - cat android/app/build.gradle | grep compileSdk | tr -d -c 0-9 | /opt/android/cmdline-tools/latest/bin/sdkmanager &quot;platforms;android-$(cat -)&quot;
 - flutter build apk --no-pub --debug
 - adb shell input keyevent 26 &amp;&amp; adb shell input touchscreen swipe 930 880 930 380
 - sed -i &#x27;/).timeout(/,/);/{ s/).timeout.*/);/; t; d;}&#x27; /opt/flutter/packages/flutter_tools/lib/src/test/integration_test_device.dart
 - flutter test integration_test/app_test.dart

build_flutter_bundle:
 stage: build
 timeout: 2 hours
 variables:
 SECURE_FILES_DOWNLOAD_PATH: &#x27;./&#x27;
 script:
 - curl --silent &quot;https://gitlab.com/gitlab-org/incubation-engineering/mobile-devops/download-secure-files/-/raw/main/installer&quot; | bash
 - echo &quot;storeFile=$(pwd)/key.keystore&quot; &gt; android/key.properties
 - echo &quot;storePassword=$KEYSTORE_PASSWORD&quot; &gt;&gt; android/key.properties
 - echo &quot;keyAlias=$ALIAS&quot; &gt;&gt; android/key.properties
 - echo &quot;keyPassword=$KEY_PASSWORD&quot; &gt;&gt; android/key.properties
 - flutter pub get --verbose
 - flutter precache --no-web
 - cat android/app/build.gradle | grep compileSdk | tr -d -c 0-9 | /opt/android/cmdline-tools/latest/bin/sdkmanager &quot;platforms;android-$(cat -)&quot;
 - apk add openjdk17-jre-headless openjdk17-jdk # you should install the java version that your application was written with during CI
 - flutter build appbundle --no-pub --obfuscate --split-debug-info=debug-info-appbundle
 - flutter build apk --no-pub --obfuscate --split-debug-info=debug-info-apk
 - cp build/app/outputs/bundle/app-release.aab ./app-release.aab
 - cp build/app/outputs/flutter-apk/app-release.apk ./amazon-release.apk
 artifacts:
 paths:
 - app-release.aab
 - app-release.apk
 expire_in: 1 week
 rules:
 - if: $CI_COMMIT_BRANCH == &#x27;master&#x27;
 when: manual
 - when: never
</code></pre>Photo by <a href="https://unsplash.com/@toluobde?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Tolu Olubode</a> on <a href="https://unsplash.com/photos/PlBsJ5MybGc?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a>