3 ms·

I was pleasantly surprised it loaded so fast. So I wanted to check the size of it. I opened the firefox debugger, and it went blank O_o Chrome was ok with it

I was pleasantly surprised it loaded so fast. So I wanted to check the size of it. I opened the firefox debugger, and it went blank O_o Chrome was ok with it: it's about 220kb, which is not bad at all for a whole runtime + stdlib. Python pyiodide (https://pyodide.org/en/stable/ https://pyodide.org/en/stable/) is several Mb. 220kb is still too much to pay upfront, since I usually want my webpages to be under 1Mb, and I can't justify burning 1/4 of the size budget. As for the Firefox story, maybe it's a good obfuscation trick :)

41b696ef1113 5y ago
>I opened the firefox debugger, and it went blank O_o No problems here?
zamadatix 5y ago
57k post Brotli. Measuring the decompressed size of your page's static text content is like measuring your static image content by the size of the decompressed bitmap the browser generates instead of the size of the PNG (or whatever format). Server side both examples should be precompressed as they are static assets.
- MobiusHorizons 5y ago
  Uncompressed size matters for parse time. Although you are correct about network latency.
  - zamadatix 5y ago
    If the goal is strictly to keep things low on bandwidth compressed size is all that matters. If the goal is strictly to keep things fast time to various user events is all that matters. If the goal is a balance of both then both will matter. In none of these is uncompressed asset wire size <1 MB the relevant metric. Nor parse time based on uncompressed size even. Barring any other information whatsoever while knowing a script is 10 MB vs 10 KB should give you a strong hint on "parse time" it's not actually telling you what the metric is named for which should be a red flag. What you actually want to know is what the parse time was regardless of what the file size was or, more likely in the bigger picture, how using the resource changes time to certain user noticeable events. Perceived slower pages much smaller than 1 MB are certainly easy to generate by optimizing for the wrong things as are perceived faster pages with much bigger payloads. On the other hand if you're just using 1 MB as a quick and simple yardstick you probably don't intend to measure some of your assets compressed and some others uncompressed, particularly when picking which to axe.
  - hunterb123 5y ago
    220kb is fine for a parse time alone, you'd ship Fengari in a separate bundle, probably in a worker. Speaking of bundles, the webpack loader is pretty cool, it allows you to import .lua files: https://github.com/fengari-lua/fengari-loader https://github.com/fengari-lua/fengari-loader
- BiteCode_dev 5y ago
  It matters very much on mobile, decompression + parsing can really hinder loading page.
deleted 5y ago
[deleted]

41b696ef1113 5y ago

>I opened the firefox debugger, and it went blank O_o No problems here?

zamadatix 5y ago

57k post Brotli. Measuring the decompressed size of your page's static text content is like measuring your static image content by the size of the decompressed bitmap the browser generates instead of the size of the PNG (or whatever format). Server side both examples should be precompressed as they are static assets.

MobiusHorizons 5y ago
Uncompressed size matters for parse time. Although you are correct about network latency.
- zamadatix 5y ago
  If the goal is strictly to keep things low on bandwidth compressed size is all that matters. If the goal is strictly to keep things fast time to various user events is all that matters. If the goal is a balance of both then both will matter. In none of these is uncompressed asset wire size <1 MB the relevant metric. Nor parse time based on uncompressed size even. Barring any other information whatsoever while knowing a script is 10 MB vs 10 KB should give you a strong hint on "parse time" it's not actually telling you what the metric is named for which should be a red flag. What you actually want to know is what the parse time was regardless of what the file size was or, more likely in the bigger picture, how using the resource changes time to certain user noticeable events. Perceived slower pages much smaller than 1 MB are certainly easy to generate by optimizing for the wrong things as are perceived faster pages with much bigger payloads. On the other hand if you're just using 1 MB as a quick and simple yardstick you probably don't intend to measure some of your assets compressed and some others uncompressed, particularly when picking which to axe.
- hunterb123 5y ago
  220kb is fine for a parse time alone, you'd ship Fengari in a separate bundle, probably in a worker. Speaking of bundles, the webpack loader is pretty cool, it allows you to import .lua files: https://github.com/fengari-lua/fengari-loader https://github.com/fengari-lua/fengari-loader
BiteCode_dev 5y ago
It matters very much on mobile, decompression + parsing can really hinder loading page.

deleted 5y ago

[deleted]