4 ms·
Uncompressed size matters for parse time. Although you are correct about network latency.
by MobiusHorizons 5y ago
Uncompressed size matters for parse time. Although you are correct about network latency.
- zamadatix 5y agoIf 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 ago220kb 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