

Ask HN: Is web app “specific gravity” a good metric? - ophuichi

I realized, like many of us, that I have been consuming a lot of tasty, long form content on Medium lately. It has evolved exactly into a kind of macro-micro-blog.<p>But yesterday a page was loading slowly, despite the minimalist layout and I decided to &quot;view source&quot; to find the culprit. And there was a 40K LoC closure compiled behemoth.<p>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.<p>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 &quot;ideal&quot; value for comparison sake.<p>Is this a meaningful metric?<p>And is Medium.com&#x27;s 8% specific gravity optimal?
======
jnaglick
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.

~~~
Retra
And good like trying to deal with image size and resolution...

------
lmkg
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.

------
Hytosys
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.

------
bjourne
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."

------
gobengo
I think I'd be a lot less happy if I worried about things like this.

------
aakilfernandes
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.

~~~
k__
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.

------
percept
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.

