Ask HN: Is web app “specific gravity” a good metric?
7 comments
I think measuring "human-usable information" is a slippery slope. You'll start with just believing that only human-language text qualifies, but the definition can be pushed.
For example, "human-usable information" could be added by changing the color of certain words. If our site is meant to teach English, changing all nouns to the color green is useful and definitely "human-usable information," right? But how do you measure the amount of information it conveys?
It's ultimately very philosophically hard. This matters because a webapp's assets (images, styling, scripts) are as much a part of its content as the actual text on a page. But if you confine your definition to encompass only human-readable text, I don't think it's useful.
For example, "human-usable information" could be added by changing the color of certain words. If our site is meant to teach English, changing all nouns to the color green is useful and definitely "human-usable information," right? But how do you measure the amount of information it conveys?
It's ultimately very philosophically hard. This matters because a webapp's assets (images, styling, scripts) are as much a part of its content as the actual text on a page. But if you confine your definition to encompass only human-readable text, I don't think it's useful.
And good like trying to deal with image size and resolution...
Professional Web Analyst here. My day job is working with metrics on web sites. I'll try and weigh in.
First, we can argue and pontificate and philosophize all we want, but ultimately there is no proof of the pudding except the tasting. This is a falsifiable hypothesis. It can be tested, so it should be tested.
That said... I can see two potential issues with this metric.
1. It's a ratio metric. Whenever you metric by taking two numbers and combining them into a single number (in this case, by division), you are losing information. You are saying that several very different scenarios are basically equivalent. You are saying that your current density of 25 story links in a 500KB app, is basically indistinguishable from 1 story link in a 20KB app, which is also the same as 500 story links in a 10MB app.
It also means that there are two ways to "improving" this metric. If you want to double the current density of 5% up to 10%, you have two options: One is trimming the fat from the app so it takes up half the space. The other is making your stories twice as long. Your metric will not distinguish between these two cases. I'm not sure that's a good thing. In particular, having stories twice as long has no impact whatsoever on the homepage.
2. It's a "means-to-an-end" metric. If this metric is meaningful at all, it's because of the relationship to content load times and how much extraneous junk is on your homepage. But... you can just measure load times and homepage click-through directly, and optimize for those. This provide additional value beyond what those metrics give you. If anything, it provides less value by over-focusing on just two things, which is only one part of content load time, and is only tangentially related to design bloat.
If you've already decided that content load times are unacceptable and you want to make them faster, this is a metric that you can look at and it will make an engineer say "huh" and give you an idea of how much room for improvement it is. You can use it as a benchmark, and compare to other apps to get an idea of whether your design can be streamlined. But setting this as a top-level metric and optimizing for it is just as likely to lead you astray as to have a meaningful impact. And if your content load time is already acceptable, I don't see the value in what this brings.
tl;dr It has use as a secondary metric, if you've already decided to slim down your page, to compare against other sites and give an idea of how much you can improve. As a top-line stat, improving this metric does not have a strong connection to improving your app.
First, we can argue and pontificate and philosophize all we want, but ultimately there is no proof of the pudding except the tasting. This is a falsifiable hypothesis. It can be tested, so it should be tested.
That said... I can see two potential issues with this metric.
1. It's a ratio metric. Whenever you metric by taking two numbers and combining them into a single number (in this case, by division), you are losing information. You are saying that several very different scenarios are basically equivalent. You are saying that your current density of 25 story links in a 500KB app, is basically indistinguishable from 1 story link in a 20KB app, which is also the same as 500 story links in a 10MB app.
It also means that there are two ways to "improving" this metric. If you want to double the current density of 5% up to 10%, you have two options: One is trimming the fat from the app so it takes up half the space. The other is making your stories twice as long. Your metric will not distinguish between these two cases. I'm not sure that's a good thing. In particular, having stories twice as long has no impact whatsoever on the homepage.
2. It's a "means-to-an-end" metric. If this metric is meaningful at all, it's because of the relationship to content load times and how much extraneous junk is on your homepage. But... you can just measure load times and homepage click-through directly, and optimize for those. This provide additional value beyond what those metrics give you. If anything, it provides less value by over-focusing on just two things, which is only one part of content load time, and is only tangentially related to design bloat.
If you've already decided that content load times are unacceptable and you want to make them faster, this is a metric that you can look at and it will make an engineer say "huh" and give you an idea of how much room for improvement it is. You can use it as a benchmark, and compare to other apps to get an idea of whether your design can be streamlined. But setting this as a top-level metric and optimizing for it is just as likely to lead you astray as to have a meaningful impact. And if your content load time is already acceptable, I don't see the value in what this brings.
tl;dr It has use as a secondary metric, if you've already decided to slim down your page, to compare against other sites and give an idea of how much you can improve. As a top-line stat, improving this metric does not have a strong connection to improving your app.
How would you measure, say, Google Drive's specific gravity? GitHub's? I'm confused because you use a single page as a representation of the entire application.
The information density of English text itself is also fairly low. Regardless, the metric you are proposing is not only bad it's also dangerous.
What you want to measure is how "good" is this site? But you can't measure goodness easily, so you use different proxies like number of returning visitors, how long each reader stays on the site and also the average latency of page loads.
How large a web page is, in bytes, though, is not a good proxy for anything. It has a marginal impact on latency (which is much more dependant on how you serve the page, if you use gzip, cdn:s, blocking javascript files etc) but other than that it's not a relevant metric for "web site goodness."
What you want to measure is how "good" is this site? But you can't measure goodness easily, so you use different proxies like number of returning visitors, how long each reader stays on the site and also the average latency of page loads.
How large a web page is, in bytes, though, is not a good proxy for anything. It has a marginal impact on latency (which is much more dependant on how you serve the page, if you use gzip, cdn:s, blocking javascript files etc) but other than that it's not a relevant metric for "web site goodness."
I think I'd be a lot less happy if I worried about things like this.
I think it's an interesting metric that can act as a starting point for a more in depth understanding, but by itself its pretty hollow.
Good idea.
The metric seems like it could show false positives for pages, that have "bad" values, so you could investigate if it's okay or not.
But when it shows a "good" value, it has probably a size that matches the content and nothing is critical.
The metric seems like it could show false positives for pages, that have "bad" values, so you could investigate if it's okay or not.
But when it shows a "good" value, it has probably a size that matches the content and nothing is critical.
Sounds great, and no, that doesn't seem optimal--1.7MB total for those 25 links.
But that seems to be where we're at now, unfortunately.
But that seems to be where we're at now, unfortunately.
But yesterday a page was loading slowly, despite the minimalist layout and I decided to "view source" to find the culprit. And there was a 40K LoC closure compiled behemoth.
The Medium home page contains about 25 story links. The web app loads about 500kB (gzip) of html, js, css. Ignoring images, and assuming each story link contains about 1kB of information this yields a very low info to app density.
Formally we define the web app information density to be the amount of human-usable information on the page (number of unicode chars * 16-bits for example) divided by the size of the web app payload. The value can be normalized against some "ideal" value for comparison sake.
Is this a meaningful metric?
And is Medium.com's 8% specific gravity optimal?