I found Devansh Batham’s security article through LinkedIn. I also noticed that it ran on Bear.
Bear says its pages contain about 2 to 5 KB of content and use no client-side rendering. Its home page makes the sharper claim: no trackers, JavaScript, or stylesheets.
My site uses Astro on Cloudflare Workers. It has generated cover art, two self-hosted font families, theme controls, filters, analytics, and decorative shaders.
How much faster and smaller was Bear?
The honest answer is: the bare Bear page was much simpler, but the two customized Bear pages I measured were not always smaller or faster.
The test
On 7 September 2026, I used the built-in Chromium browser to load four live pages:
- Devansh’s Bear writing list.
- My Astro blog list.
- His
Needle in the haystackarticle. - My
What a Lighthouse Performance Audit Foundarticle.
I disabled the browser cache for each run. I ran each page three times and used the median. I waited three seconds before reading the Navigation and Resource Timing entries.
These are lab measurements from one machine and network path. They are not global field data.
Listing pages
| Metric | Bear writings | Astro blog | Difference |
|---|---|---|---|
| Compressed HTML | 5.4 KB | 12.9 KB | Astro 2.4x larger |
| Decoded HTML | 20.2 KB | 75.6 KB | Astro 3.7x larger |
| DOM elements | 93 | 621 | Astro 6.7x more |
| Resource requests | 2 | 24 | Astro 12x more |
| Measured transfer | 991 KB | 2,703 KB | Astro 2.7x larger |
| JavaScript | 0 KB | 9 KB | Bear shipped none |
| First contentful paint | 696 ms | 228 ms | Astro 3.1x faster |
| Server response start | 629 ms | 55 ms | Astro 11.4x faster |
Bear clearly won the structure test. Its HTML was smaller, its DOM was far smaller, and it shipped no JavaScript.
The transfer result needs context. Devansh’s custom Bear theme loaded a 984 KB Iosevka font file. My listing loaded about 2.56 MB of generated PNG cover images and 108 KB of fonts.
The first paint result was mostly a hosting result in this sample. My Cloudflare response started in 55 ms. The Bear subdomain started in 629 ms. A smaller document cannot recover time that it spends waiting for the first byte.
Article pages
| Metric | Bear article | Astro article | Difference |
|---|---|---|---|
| Compressed HTML | 19.3 KB | 12.4 KB | Bear 1.6x larger |
| Decoded HTML | 60.4 KB | 38.3 KB | Bear 1.6x larger |
| DOM elements | 349 | 408 | Astro 1.2x more |
| Resource requests | 9 | 19 | Astro 2.1x more |
| Measured transfer | at least 3,064 KB | 520 KB | Bear at least 5.9x larger |
| JavaScript | 0 KB | 7 KB | Bear shipped none |
| First contentful paint | 772 ms | 204 ms | Astro 3.8x faster |
| Server response start | 690 ms | 49 ms | Astro 14.1x faster |
The custom Bear article loaded three Iosevka weights. They measured about 3.04 MB together. It also contained five cross-origin WebP images. Their servers did not expose transfer sizes through Resource Timing, so the Bear transfer number is a lower bound.
My Astro article loaded one cover image and three font files. Its measured total was about 520 KB.
The platform did not force the three-megabyte font choice. The theme did. Astro also did not force my 2.56 MB listing image cost. I did.
What Bear gets right
Bear makes the cheap path easy.
A plain theme can have tiny HTML, no client script, and almost no DOM. That gives an author fewer ways to create accidental work for the browser.
Bear also keeps the publishing model narrow. A title and article body are enough. The performance budget is part of the product constraint.
Astro can also render static HTML without a client runtime. Astro’s documentation explains that scripts are optional and that small scripts can be inlined. My site uses that flexibility for features. Each feature has a cost.
What the headline comparison misses
Bear is faster than Astro is not what this test showed.
It showed four different layers:
- Platform defaults: Bear starts with less.
- Theme choices: custom fonts can erase a tiny default budget.
- Content choices: images dominated my listing.
- Delivery: Cloudflare gave my pages a much faster first byte in this location.
Framework labels do not explain a one-megabyte font or a 380 KB cover image. Page decisions do.
My action items
The listing page is the clear target.
- Generate WebP or AVIF covers beside the PNG source.
- Add responsive image widths instead of sending full cover files.
- Keep below-fold images lazy and confirm that they do not start early.
- Remove decorative script when the shader is outside the viewport.
- Reduce repeated card markup where it does not improve meaning.
- Keep the new full-text index lazy until the search box receives intent.
- Keep the 7.2 MB semantic model behind an explicit click-to-start switch.
- Add a transfer budget to the build, not only a Lighthouse score.
I will use two budgets first:
- No blog listing should transfer more than 500 KB before reader interaction.
- No font file should exceed 100 KB without a measured reason.
Bear did not give me a reason to rewrite the site. It gave me a cleaner baseline.
The fastest part of Bear was its refusal to add things. That is a design lesson I can use in Astro.