The Sample Data
For this article I took the top 6 non-sponsored articles;
- SASS to PostCSS
- CSS Grid is Coming
- CSS Writing Modes
- The Inner Workings of the Virtual DOM
- Improving UX names with Vocalizer.js
- Learning From Lego a Step Forward in Modular Web Design
The Data I wanted
Here are the stats I (rather arbitrarily) wanted to know;
- Average word count
- Average image count
- Average link count (internal and external)
- Average lines of code
My General Method
My general method for grabbing all of this information is to find the DOM element we can consider the main content area, use it to hang code off to query for the things I care about. Once I have that information put it into an object that I can then query to get averages.
Everything I’ve written was written and ran in Chrome’s web console.
From SASS To PostCSS
The first article is where I will spend most of my time, because I will be figuring out a lot of the code that I will hopefully be able to copy and paste in future articles.
The first thing we need to do is find what I could consider to be the main post, I use the web inspector and eyeball the results. It didn’t take long to decide that the following code would work;
Here I am setting a constant called
mainPost to be the element returned by running
querySelector against the document. The
.e-content part is saying look for a class called “e-content”. If you know CSS selectors then any of them will work, if you don’t, fear not, I will explain any new ones I use in this article.
Getting an accurate word length isn’t a trivial task, there are certain things like emojis that you may or may not want to consider words and do you want to consider words that make up figure captions or code samples in your word count?
textContent returns for a node as a word. Making the code I would need to write be;
Which gives us a figure of
Before I go on, let me talk about what I’ve done here.
I asked the
mainPost for its
textContent, this returns a massive string with all the text of the post.
I then split this string into an array, I want to split on spaces so in theory I should now have a list of words.
I want to
filter this array to only show me non-empty words (note: this could be improved to also filter out other things I don’t want to be considered words).
Now I have a filtered array, which allows me to ask its
Now we want to find the images, this is a much smaller bit of code;
This code asks the
mainPost to query all the things in it for
img elements, using
This will return a
NodeList, which we can ask for its length.
This gives us
Next up I wanted to grab the count of links, I wanted to do this for internal links and external links. Normally internal links are relative, so start with a
/, which means we can do something like;
Which gives us
Instead of just asking for instances of an element, we’ve used the attribute selector syntax to say
a elements with an attribute of
href that starts with
We can make one small change in order to find links to external resources;
This gives us
The final thing we wanted was lines of code. I decided that this meant lines with
pre elements, I eyeballed the content to make sure that was fine, it seems to be.
We are doing quite a few things here.
First, we want to turn our
NodeList into an
Array this is because you can ask
NodeList for things like its length, but you can’t do things like
reduce or iterate over a
NodeList. We do this with
Once we have our array we want to
reduce it, reducing is the act of iterating over an object and combining parts of it to turn it into one output, in this case we want to iterate over each
pre element and return the count of the lines within that
0 in our code is us seeding the
reduce with a count value which we can add stuff to.
To get the amount of lines (which we will add to
count) I take the
codeBlock, ask for its
textContent (like we did for counting words) and split based on
\n, which is the new line character. Once I have this array of lines I want to filter over them to remove and empty lines.
Once that mouthful is complete it returns
125, which is the final stat we wanted.
- WordCount = 1873
- ImageCount = 3
- LinkCountInternal = 0
- LinkCountExternal = 17
- LinesOfCode = 125
CSS grid is coming
The next article should go a lot more smoothly since we should be able re-use most of our code.
The main difference will be selecting the
mainPost, I found a class called
.content which would do it, but to be different I wanted to hang it off an element, which in this article’s case was
All of the other code was exactly as I had written before, so I won’t bore you with it again.
- WordCount = 913
- ImageCount = 1
- LinkCountInternal = 2
- LinkCountExternal = 8
- LinesOfCode = 0
CSS Writing Modes
We are building up a head of steam now and can jump straight into our third article.
Again, all the code was identical bar setting the
- WordCount = 3009
- ImageCount = 20
- LinkCountInternal = 0
- LinkCountExternal = 14
- LinesOfCode = 46
The Inner Workings of the Virtual DOM
For our fourth article I had to make a some small changes.
mainPost was set using;
When it came to working out internal vs external links I couldn’t do what I had done before because this was posted on Medium. Medium has a subdirectory for the user account and has no notion of relative links for internal content.
To get internal links I went with a small variation, simply asking for content that started with the author’s Medium URL;
The external link is a bit more exciting, I had to use
What this does is
map over all our
a elements and return their
filter these to only return elements that don’t include the author’s Medium URL.
Finally I can get the length of this
- WordCount = 2047
- ImageCount = 66
- LinkCountInternal = 22
- LinkCountExternal = 26
- LinesOfCode = 6
Improving the UX of Names with Vocalizer.js
For our fifth article I was able to use the original code again, with one small change because Smashing Magazine references internal links with a fully qualified domain name so I used the same method we did for the Medium post.
As you can see I was a bit devil may care with this one and just went for the
- WordCount = 1513
- ImageCount = 5
- LinkCountInternal = 16
- LinkCountExternal = 9
- LinesOfCode = 49
Learning from Lego: A Step Forward in Modular Web Design
Our final article was a bit of a doozy. I had to write new code for all of this.
There wasn’t one good container that just held the article, it also held a lot of ad/cruft that I didn’t want to count towards anything.
There are a few ways I could have addressed this, I decided to select only the elements I care about;
This says we have our
mainPost but the thing we want to eventually hang other queries off is
mainContent, which is a subset of the stuff inside
mainPost that we actually care about. I got the list of these elements by eyeballing the source code.
In order to get the word count I had to use
I had to do the same sort of thing to get the image count;
Likewise for link grabbing, although I was able to revert back to using just
/ for my lookup.
This article also had code samples using CodePen. I decided for lines of code to ignore these examples as digging into
iframes isn’t fun.
- WordCount = 2424
- ImageCount = 14
- LinkCountInternal = 1
- LinkCountExternal = 10
- LinesOfCode = 78
Working out the Averages
Great, so now we have this data, I’ve stored it off as 5 Arrays (it could have been stored many different ways).
Which means I can do the following;
The meat of this article
NOPE. This is a think-piece on the stats you NEED TO FOLLOW in order to get a top position on Frontend Focus.
Unless you have EXACTLY
1963.1666666666667 words in your article with
18.166666666666668 images for good measure, along with
6.833333333333333 internal links and
14 external ones, and of course you need
50.666666666666664 lines of code. You will never get featured and your startup will fail, or worse, get acquired by Yahoo.
Want proof? This article doesn’t conform to those numbers and I bet you won’t be reading this in Frontend Focus anytime soon!