Improve the realism of the estimated reading time

[AllThingsSmitty]

Why is this needed?

This Jekyll snippet improves reading time estimation accuracy by accounting for the fact that not all content types are read at the same speed:

{% assign content = page.content | default: post.content %}

{% assign clean_content = content 
  | replace: '<script type="math/tex">', ''
  | replace: '<script type="math/tex; mode=display">', ''
  | replace: '</script>', ''
  | replace_regex: '&[a-zA-Z#0-9]+;', ' '
%}

{% assign total_words = clean_content | strip_html | number_of_words | plus: 0 %}
{% assign text_no_code = clean_content 
  | replace: '<pre>', '<!--' 
  | replace: '</pre>', '-->' 
  | strip_html 
  | number_of_words | plus: 0 
%}

{% assign code_words = total_words | minus: text_no_code | at_least: 0 %}
{% assign prose_words = text_no_code | minus: code_words | at_least: 0 %}
{% assign math_words = total_words | minus: prose_words | minus: code_words | at_least: 0 %}

{%- comment -%}
  Weighting:
  - prose = 1×
  - code = 0.5×
  - math = 1.5×
{%- endcomment -%}

{% assign adjusted_words = prose_words 
  | times: 1.0 
  | plus: (code_words | times: 0.5) 
  | plus: (math_words | times: 1.5) 
  | round 
  | plus: 0 
%}

{%- comment -%}
  Divide as float to avoid truncation
{%- endcomment -%}

{% assign reading_time = adjusted_words | divided_by: 220.0 | ceil | at_least: 1 %}

🔍 Reasoning

The key improvement with this idea:

• Prose: 1× normal reading speed.
• Code: 0.5× (slower to read, but less “dense”, people often skim it).
• Math: 1.5× (takes longer to parse and mentally process).

This weighting reflects how readers actually spend time on different types of content.

💡 Why this approach works

Most “reading time” plugins assumes all words are equal, but technical posts rarely are. This code improves realism by:

• Removing HTML & special markup that inflates counts.
• Separating prose from code and math, which are read at different rates.
• Weighting each type according to realistic cognitive effort.
• Avoiding truncation errors with float division (220.0 instead of 220).

[AllThingsSmitty]

Are shorter posts in fact more popular?

There is data, but it doesn’t strongly support the idea that shorter blog posts are inherently more popular because they take less time to read/consume. In fact, the evidence mostly points in the other direction (i.e., longer, more in-depth posts often perform better).

What the research does show

Here are some key findings:

• According to one analysis by Master Blogging, readers spend on average about 96 seconds on a typical blog post. For B2B readers it’s about 77.6 seconds; for B2C about 92.3 seconds.
• That same study reports: “Reading time hits its peak if a blog post takes ~7 minutes (between 1,500-2,000 words)” and “Reading time can dip to below 10 seconds if the post takes over 14 minutes to finish.”
• Another report (from Pew Research Center) found that for articles: “While shorter news content is far more prevalent … long-form stories are accessed at nearly the same rate as short-form.”
• In general, content-marketing surveys (e.g., by Orbit Media) show that many bloggers who write longer/more in-depth posts report better results (higher traffic, more shares) than those who write shorter pieces.
• For example, a 2019 blog stat set reported: “Blog posts with more than 1,800 words receive the most links from other websites.”
• From the “ideal length” discussions: Many sources suggest an “ideal” blog post length in the range of 1,400-2,500 words (depending on topic/goal) rather than very short formats.

Why shorter isn't always better

Given those findings above, here are some reasons why very short posts may not automatically yield better popularity for a developer-audience blog:

• Attention and reading time: If your post is very short, it may simply be consumed quickly but that doesn't guarantee deeper engagement, shares, or sustained traffic. One source noted: “The longer the page, the smaller the percentage of words people read.”
• Search engine / SEO benefits: Longer posts tend to cover the topic more comprehensively, which helps with SEO and inbound links, both of which contribute significantly to traffic/popularity for technical or niche blogs.
• Audience expectations: For an audience of front-end web developers/engineers, you may be dealing with more complex content (tutorials, code samples, patterns, frameworks) where depth matters. Shorter posts may risk oversimplification and may not satisfy the intent of your readers.
• Correlation vs causation: Just because longer posts often perform better doesn't mean that length alone causes the improvement. Quality, topic relevance, promotion, and structure (readability, visuals, code samples) matter a lot.