The progress indicator measures the article element rather than the whole document, so the footer and comments do not count against the reader's sense of how much is left. This matters more than it sounds: a bar that reaches eighty percent while three screens of comments remain reads as a broken promise.
Reading time is calculated from the same element at two hundred and twenty five words per minute, which is a reasonable average for considered non-fiction. It is written into the page as a fallback so the number is present even before scripting runs.
Behaviour worth copying
Both elements only stick on desktop. On narrow viewports the share rail collapses to a horizontal row above the article and stops following the scroll, because a floating rail on a phone spends its life covering the thing you are trying to read.
The share links are built from the page URL and title at runtime, so the same markup can be dropped into any post without editing five href attributes by hand.
Implementation notes
Scroll handling is throttled through a single animation frame, and the listener is registered as passive so it never blocks scrolling on touch devices. The whole thing is a few hundred bytes of vanilla script with no dependency on the carousel or lightbox bundles.
If the article is shorter than the viewport the bar simply reports complete, rather than dividing by a negative number and producing something strange.
Keep scrolling to watch the bar fill. It reaches one hundred percent as the last paragraph of the article body leaves the top third of the screen, which is roughly the point at which a reader has actually finished rather than merely arrived.
That final detail is the one most implementations get wrong. Tying completion to the bottom of the document means the bar is still climbing while the reader is scrolling past a newsletter form and four related posts, long after the writing itself has ended.