8 min

TheVerge.com still a bloated mess in September 2016

The dumbest story that I read in 2015 was this one.

  • July 20, 2016 - TheVerge.com - The mobile web sucks - It's going to get worse before it gets better

The article's slant is stunning when considering the author's bio. My emphasis added.

Years later, he became a technology journalist.

Nilay was a co-founder of The Verge and the site's first Managing Editor before taking over as Editor-in-Chief. He also was the acting Managing Editor for the launch of Vox.com.

... SAY Media naming Nilay one of 10 "voices that matter" in technology journalism.

Technology journalism is on life-support.

From the July 2015 Verge article:

But man, the web browsers on phones are terrible. They are an abomination of bad user experience, poor performance, and overall disdain for the open web that kicked off the modern tech revolution.

The overall state of the mobile web is so bad that tech companies have convinced media companies to publish on alternative platforms designed for better performance on phones. Apple doesn't allow anyone else to build a new browser engine for the iPhone, so Facebook's Instant Articles is really just Facebook's attempt to sidestep that restriction by building an entirely new content rendering system.

The web and the web browsers for any device are not slow. Websites are slow. Media publishers have created a reader-hostile web. Blaming browsers is ignoring reality. TheVerge.com author is living an alternative universe.

No need to rehash everything. My lengthy thoughts can be found here:

At least TheVerge.com author had a momentary bout of intelligence when he wrote:

And yes, most commercial web pages are overstuffed with extremely complex ad tech, but it's a two-sided argument: we should expect browser vendors to look at the state of the web and push their browsers to perform better, just as we should expect web developers to look at browser performance and trim the fat.

Two-sided argument? Even if web browsers and the phone hardware were able to process unnecessarily bloated web pages quickly, publishers would simply add more bloat to their pages. And then publishers would complain again about web browsers being slow.

Other fleeting moments of intelligence by the author:

Now, I happen to work at a media company, and I happen to run a website that can be bloated and slow. Some of this is our fault: The Verge is ultra-complicated, we have huge images, and we serve ads from our own direct sales and a variety of programmatic networks.

Only some is The Verge's fault?? Nope. 100 percent of the slowness is The Verge's fault because it's their website.

A commenter to that Verge article said:

Turn off Java Script, suddenly TheVerge is less crappier and loads faster. Go figure.

Yep. It's that way for all media websites. It's how I often view the web.

But JavaScript is not the problem. The misuse or abuse of JavaScript is the problem.

Another commenter correctly observed:

So problem is not the browser, but website itself. Web browsers are fine, the web itself is overbloated.

The web is bogged down by poorly-designed, bloated websites.

Another commenter said:

Content blockers on iOS 9 have resulted in 4x faster loading times on many pages

One you disable all the unneded JavaScript and eliminate literally dozens of useless server requests, the web loads quite fast on mobile.

Don’t blame the browser vendors for the shitty performance of webpages. It’s not their fault that web developers can’t stop stuffing their websites with crap

Another commenter:

Exactly, the same is true for Android. Install an ad blocker and mobile Chrome is perfectly usable and nowhere close to the mess described in the article. The problem primarily lies with poor web development.

Comment:

Here’s a fun solution: turn off JavaScript. Boom! Suddenly the Verge loads in less than a second.

Comment:

The browsers aren’t perfect, but the real problem is shitty web development. Huge bloated and slow javascript frameworks. CDNs that deliver content hanging for long periods of time. 13 trackers. Video ads. But sure, you go ahead and blame the browsers. Good grief!!!

Web pages like TheVerge are huge and bloated and take many seconds to load. That is sad beyond belief.

I'm glad that at least a few other people see the real problem the way that I do.

Another comment:

Phones got more efficient at the web, so now we get more web shoved to our phones.

Does an article with a headline image and text really need to be 10+ MB and have 20+ javascripts running, no they don’t.

Comment:

My 2007 MacBook that is as current as it can be (Lion, current Chrome or Safari) runs The Verge slower than my iPhone 6 Plus with less RAM. UNLESS, I turn on adblocker. Then it flies. Gee, imagine that.

The adblocker probably blocks JavaScript. Bloated web pages in 2016 will bog down older computers, unless JavaScript is disabled.

But simple web pages will load quickly on older computers and old-style phones. I've experienced this.

Even in 2016, most of the content on media websites is text.

Let's view some stats for that 2015 TheVerge.com article.

  • https://www.webpagetest.org/result/160913_GF_PB4/
  • www.theverge.com/2015/7/20/9002721/the-mobile-web-sucks
  • From: Dulles, VA - Chrome - Cable - 9/13/2016, 10:43:55 AM
  • First View - Fully Loaded:
    • 119.658 seconds (two minutes!!!)
    • 382 requests (what is being downloaded?)
    • 5,061 KB (5 megs!!!)
    • 15.5% of the bytes downloaded were image related
    • 37.2% of the bytes downloaded were JavaScript (1.75 megabytes!!!)
    • 32.5% of the bytes downloaded were Flash (1.52 megabytes.???)
    • 3.4% of the bytes downloaded were HTML (159 KB)
    • 3.1% of the bytes downloaded were CSS (147 KB)

What mattered most, HTML and CSS, equaled 6.5% of the bytes downloaded.

If the article contained images that helped the article, then that's fine, and obviously, helpful images will add to the download amount.

Nearly 70% of the download bytes were JavaScript and Flash. Flash in 2016?

But according to the author of that article, the main problems are the web in general and mobile web browsers. Unbelievable.

Stat's for a post that I made at my website boghop.com. I try to use simple HTML and minimal CSS. I use no JavaScript for browsing-only users (readers).

  • https://www.webpagetest.org/result/160913_3G_PNR
  • boghop.com/design-by-writing.html
  • From: Dulles, VA - Chrome - Cable - 9/13/2016, 10:53:36 AM
  • First View - Fully Loaded:
    • 0.462 seconds
    • 2 requests
    • 9 KB

The boghop.com site responds quickly on desktop browsers and phone browsers. It responds fairly well over an LTE connection and even a 3G connection.

The web is not slow. Mobile web browsers are not slow. Bloated websites like TheVerge.com are slow.

I'd like to compare a TheVerge.com article to a boghop.com article over a 1G or 2G connection.

Here's a test with a media website that is beautifully designed: http://thin.npr.org

  • https://www.webpagetest.org/result/160913_4J_PYF
  • http://thin.npr.org/s.php?sId=493322073&rId=1001&x=1 (Why Pho Is Central To Vietnamese Identity)
  • From: Dulles, VA - Chrome - Cable - 9/13/2016, 11:01:55 AM
  • First View - Fully Loaded:
    • 0.373 seconds
    • 2 requests
    • 5 KB

How about that? From a media website. Well, from it's stripped down version of its website.

And NPR does not need to rely on advertising like TheVerge.

The business model of TheVerge.com requires inflating its website with ads and third party bilge distributors that force readers to download trackers and other crapware.

But thin.npr.org proves that the web is not slow. The site would need only a minimal amount of HTML and CSS to make it display better on a phone. And such changes would have little to no impact on download speed.

Another TheVerge.com test on a Sep 12, 2016 article.

  • https://www.webpagetest.org/result/160913_GN_P90
  • http://www.theverge.com/2016/9/12/12891562/twitter-tweets-140-characters-expand-photos
  • From: Dulles, VA - Chrome - Cable - 9/13/2016, 10:40:20 AM
  • First View - Fully Loaded:
    • 119.923 seconds
    • 394 requests
    • 4,833 KB

The article contained one stock photo that added nothing to the article.

The total text size of the article's title, subtitle, by-line, date, and body totaled only 2,465 bytes. That's plain text, not HTML text.

Surrounded by basic HTML and CSS, the total size of the article might be 6,000 bytes. Let's round up and say it would be 10,000 bytes. That's not including the useless, stock image.

I viewed this Twitter-related Verge article on my Linux desktop computer. From what I can determine, the size of the stock image was 76.5 KB.

Okay, total size of my version of the web article would be approximately 86,000 bytes. Let's round up to 100,000 bytes.

100 KB should be the max size of a simplified web version of that article. No JavaScript. No ads. No trackers. Unrealistic for a for-profit media org today.

100 KB. TheVerge.com makes a user download 4.8 megabytes.

And the alleged technology journalist blamed web browsers.

#web #design #media #moronism

From JR's : articles
1445 words - 9091 chars - 8 min read
created on
updated on - #
source - versions

Related articles
In 2016, digital publishers are finally concerned about UX - Jul 18, 2016
Webpagetest.org results thu, apr 14, 2016 - Apr 14, 2016
Webpage test results - fri, apr 15, 2016 - Apr 15, 2016
Newspapers are executing a war on the web - Mar 01, 2016
Video ads within Facebook's Instant Articles - Mar 31, 2016
more >>



A     A     A     A     A

© 2013-2017 JotHut - Online notebook

current date: Dec 3, 2024 - 4:37 p.m. EST