webpagetest.org Testing - Sat, Jul 13, 2019

Here's Toledo Blade editorial, published today that is a text-based opinion, containing around 550 words.

That editorial, however, contains a large, useless stock photo of the Toledo skyline. It's a nice image, but it's pointless. Make every image matter.

webpagetest.org results for the Blade's version of a web page.

From: Dulles, VA - Chrome - Cable
7/13/2019, 12:12:20 PM
First View Fully Loaded:
Download Time: 14.766 seconds
Web requests: 405
Bytes downloaded: 4,190 KB

70 requests were for JavaScript. 141 requests were for images. ?????

1.38 megabytes of the download were for JavaScript. 2.2 megabytes were for images.

All of that crap to read 550 words. It's all text, at least the part that matters.

4.1 megabytes??? The text version of War and Peace is 3.2 megabytes. The HTML version of War and Peace is 3.9 megabytes. In printed book form, War and Peace contains over 1000 pages.

The Blade has made a 550 word editorial larger than a 1000-plus page book.


My version of the same editorial.

webpagetest.org results.

From: Dulles, VA - Chrome - Cable
7/13/2019, 12:28:01 PM
Download Time: 0.552 seconds
Web requests: 3
Bytes downloaded: 4 KB

That's what would happen, approximately, if the Blade published their content in a manner similar to https://text.npr.org, which would be for subscribers. Leave the crapware website for non-paying readers.

4 megabytes vs 4 kilobytes. It's the same 550 words. My version contained no JavaScript, no images, no ads, no crapware.

For my version, I stored the CSS in an external file, instead of inline within the web page. That made the number of web requests 3, instead of 2.


I'm a digital subscriber to the Blade, but I don't use any of the Blade's digital products. I created my own web app to read the Blade. It's two web apps that work together. One consumes several Blade RSS feeds, and the other app displays Blade articles in a humane manner.

Here are the webpagetest.org results for same Blade editorial, dynamically displayed by my Blade web reading app.

From: Dulles, VA - Chrome - Cable
7/13/2019, 12:11:12 PM
First View Fully Loaded:
Download time: 0.881 seconds
Web requests: 2
Bytes downloaded: 5 KB


And finally, here's the webpagetest.org results for the Markdown file of my HTML version.

From: Dulles, VA - Chrome - Cable
7/13/2019, 1:01:34 PM
First View Fully Loaded:
Download Time: 0.257 seconds
Web Requests: 2
Bytes Downloaded: 2 KB

0.257 seconds to download plain text versus the Blade's abomination of a website that takes over 14 seconds to download one editorial.

2 KB of plain text versus 4.1 megabytes of who-knows-what from the Blade's website.

Both versions offer 550 words of text. And the media whines about Big Tech. Where's the concern and the investigations into the awful websites maintained by media orgs?

For this version, the text/plain Markdown markup is downloaded and optionally rendered for display by a Markdown viewer web browser extension.

That's probably the best web experience of all, since the display is controlled by the reader. I uploaded my own CSS to the browser extension, and for a theme, I chose my CSS.

If a reader did not want to create a custom CSS file, then the reader could chose from a small list of custom themes that came with the browser extension.

The server hosts the raw content while the client (reader) controls the display, including all typography.

More of my thoughts about this idea:

It means the elimination of HTML, being created by hand and by CMS apps. No more Hypertext Markup Language seems like an odd thought, but why not? Progressing might mean no need for markup except Markdown.

Oh dear, how will I live without using semantic HTML5 tags, such as <article>, <header>, <footer>, <section>, etc.? Except for applying CSS, I don't think that I have ever had a need to consume these HTML5 tags. It's semantic markup for something to consume. Maybe screen readers. But with the way web pages are horribly designed by media companies, what in the hell will a few HTML5 tags accomplish? Can screen readers consume plain text?

The web survived for many years without semantic HTML5 tags. To me, Markdown is semantic, I guess. I can view my Markdown files and immediately identify the title, sub-title, section headings, blockquotes, code, paragraphs, links, etc.

Anyway, the client-side apps would render the Markdown into a display that would appear like HTML being displayed by a web browser.

Dozens of Markdown implementations exist. In 2013 or 2014, an effort called CommonMark launched to create a standardized version of Markdown. Recently, at my test Sora website, I switched Markdown parsers to use one that supports CommonMark.

Instead of HTML, web authors and CMS apps would create CommonMark files on the servers. CommonMark (Markdown) browsers or web browsers with the appropriate extensions would render the content for display.

Here's my test site where the CMS only creates Markdown markup files, except for the homepage that explains the goofiness.

http://md.soupmode.com

When I backup my web posts here at sawv.org, I only backup the markup files. I don't backup the HTML pages. My content is created with either Textile or Markdown. I started using Textile in 2005, and I began using Markdown and MultiMarkdown in 2013.

In recent years, I have simplified my web post formatting, which meant that Markdown satisfied my needs at least 95 percent of the time. I have never used definition lists, except for testing. I rarely have a need to use tabular data, and now if I need to post tabular data, and if the table is small, I use a code block. I don't need fancy footnotes with links going down and up. I can highlight the footnote number and manually add a footnotes section at the bottom of the page.

I'm not writing books. I'm not writing scientific papers. I create simple web posts.


My recent related posts: