Lightweight Google AMP Gaining Weight

Today I received a notification from Google AMP that the images I use in my posts are smaller than their recommended size. This came as quite a surprise to me – all this time I thought I was helping AMP’s mission to keep things lightweight for mobile browsers. It keeps my blog posts from unnecessarily using up readers’ cell phone data plans, but maybe this is just a grumpy old man talking. It is clear that Google wants me to use up more bandwidth.

AMP stands for Accelerated Mobile Pages, an open source initiative that was launched by Google to make web pages that are quick to download and easy to render by cell phones. Cutting the fat also meant cutting web revenue for some publishers, because heavyweight interactive ads were forbidden. Speaking for myself, I am perfectly happy to leave those annoying “Shock the Monkey” ads behind.

As a WordPress.com blog writer I don’t usually worry about AMP, because they automatically creates and serves an AMP-optimized version of my page to appropriate readers. And since I don’t run ads on my page there’s little loss on my side. As a statistics junkie, I do miss out on knowing about my AMP viewership numbers, because people who read AMP cached versions of my posts don’t interact with WordPress.com servers and don’t show on my statistics. But that’s a minor detail. And in theory, having an AMP alternate is supposed to help my Google search rankings so I get more desktop visitors than I would otherwise. This might matter to people whose income depends on their web content. I have the privilege that I’m just writing this blog for fun.

Anyway, back to the warning about my content. While I leave AMP optimization up to WordPress.com, I do control the images I upload. And apparently I’ve been scaling them down too far for Google.

amp image recommend 1200 wide

I’m curious why they chose 1200 pixel width, that seems awfully large for a supposedly small lightweight experience. Most Chromebook screens are only around 1300 pixels wide, a 1200 pixel wide image is almost full screen! Even normal desktop web browsers visiting this site retrieves only a 700 pixel wide version of my images. Because of that fact, I had been uploading images 1024 pixels wide and thought I had plenty of headroom. Now that I know Google’s not happy with 1024, I’ll increase to 1200 pixels wide going forward.

Unexpected find: ThingLink and its business

A Science News article online experimented with interactivity not possible in their print edition. It was fairly simple at first glance: when a cursor hovers over certain places in the image, additional information pops up. Seen all over the web, like the little pieces of trivia behind bing.com background picture of the day.

What caught my attention is the link in the corner: “Made with ThingLink, Learn More” What I had thought was a simple piece of HTML is actually a business built around the concept.

A brief exploration found that ThingLink hosts the image (and associated server storage and bandwidth) plus the interactive scripting. The package of content is then available to be served alongside content hosted elsewhere, such as WordPress.com. I can embed a ThingLink right here in this post, if I had something interesting to show.

There’s a basic level of the service for free. To make money, they sell higher tiers with features like customization, branding, and analytic information. I’m ignorant on how this information might be valuable, but ThingLink has an idea: they believe the full set of features is worth over $200/month to some people.

So definitely not just a trivial piece of HTML. It is the tip of the iceberg of a corner of web commerce I didn’t even know existed before today.

WordPress clients everywhere

The first step of documenting my experience on WordPress is… talking about WordPress itself. Self-referential, yes, but it actually served as a great introduction into a different mindset: Software as a Service (SaaS).

WordPress is itself a content management system designed to run entirely over the web. Not only is the content stored on a remote server, the management UI (like the text editor I’m typing this in) is served by the WordPress service over the web. There is no application to install on my computer. When I want to work on my WordPress site, I use my web browser.

SaaS is gradually taking over a lot of the software world, and as a Windows developer, I’ve been missing a lot of the action. It’s time to get to know this new cloud-based world. A world where the service is available anywhere there’s a web browser, because a browser is all the client software you’d ever need.

Or… is it?

It turns out the client-side software concept is not dead, not quite. And not even at WordPress. While it was no surprise to learn that WordPress have mobile apps to access the service on iOS and Android, I was greatly amused to learn they have also introduced desktop client software for Linux, MacOS, and…. Windows.

Yep, Windows client software.

What is old is new again.