Video ads within Facebook's Instant Articles

March 31, 2016

http://www.wsj.com/article_email/video-ads-are-coming-to-facebook-instant-articles-1459371404-lMyQjAxMTE2MTMyMTAzNzE4Wj

I'm pointing out the inadequate writing, contained within this WSJ article.

The social network said it will also allow publishers to place one additional ad unit at the bottom of every Instant Article, which it estimated could increase ad impressions by more than 20%. Currently publishers may include one ad for every 350 words of content.

It’s the latest evolution for the Instant Articles program, which allows publishers to host content directly on Facebook instead of posting links to direct users back to their own websites.

The writer failed to mention that Instant Articles can only be viewed by installing and using Facebook's native app on a mobile device.

A user cannot view Instant Articles by accessing Facebook with a web browser on desktop, laptop, tablet, or phone.

It's likely that most Facebook users access the service from a mobile device and not a PC (desktop or laptop).

And it's also likely that most mobile Facebook users access the service by using the Facebook app.

With that knowledge, maybe the writer felt that it was useless to mention that Facebook's Instant Articles only work within the app because "everybody" accesses Facebook from the company's mobile app.

More from the WSJ article:

[Instant Articles is] designed, in part, to help address the problem of slow loading times on the mobile Web.

The writer failed to mention the slow loading times on the mobile web are caused by the publishers. In my opinion, the writer implies that the slowness problem is caused by the mobile web infrastructure or protocol. Maybe the writer thinks that the slowness is caused by mobile web browsers.

The mobile web is not slow. Mobile web browsers are not slow.

My static blog site http://wren.soupmode.com loads quickly in all web browsers on all devices. Obviously, a post that contains many images will take longer.

The problem with the web and mobile web are the fact the publishers' websites are horribly bloated and slow.

When a 1000 bytes of text for a simple article is delivered to the user wrapped with 5 to 10 megabytes of bloat, how is that the fault of the mobile web?

100 percent of the blame for any slowness belongs to the publisher.

This WSJ article body text contains 467 words, which totals 2931 bytes. This includes the title and sub-title texts. No images were used in the article body. Just 2931 bytes of text.

WebPageTest.org results for the above WSJ article:

Chrome browser test from Dulles, VA - First view - Fully loaded:

• 13.311 seconds
• 201 requests
• 2,769 KB
• cost = $$$$$ (the max rating)

Actually, and sadly, that's pretty good for a media site, relatively speaking.

Only 200 requests. And the article page is "only" 2.8 megabytes. And 13 seconds to fully load is speedy for media orgs.

Testing the same WSJ article from Dulles, VA and using iPhone 5C iOS 9 - First view - Fully loaded:

• 23.745 seconds
• 208 requests
• 4,425 KB
• cost = $$$$$

Why would the mobile version be considerably larger than the PC version?

4.4 megabytes get sent to the user's phone in order for the user to view about 3,000 bytes of text.

And the problem is the mobile web??? Not even close to reality.

The WSJ, like nearly all media websites, are abusing the web by creating reader-hostile articles.

#ia #advertising #mobile #web #media #design #moronism