This blog is about my musings and thoughts. I hope you find it useful, at most, and entertaining, at least.
Like most Americans, websites has by-and-large gotten heftier as the web's grown older. With the web in it's mid-twenties we are facing an obesity crisis on the web.
I opened a local news site's webpage and watched the requests made in the background, as the browser sat in the background.
And continued to watch the Chrome's network inspector. (Yes, JPGs for a screenshot of text. It's smaller and they're still readable.)
I could have let it go on longer, but I think having loaded 62MB over 8 minutes and no interactions hammers home my point: publishers, and many web developers in general, are designing heavy websites. While this is a notoriously bad site, even the a large national paper loads 17MB after only a minute.
Another local publisher didn't even have content in their initial viewport! The majority of their bandwidth needs were, almost needless to say, ads.
For the publishers, the obvious advantage to having lightweight pages is user retention. There are a lot of reasons to have a fast load time -- users will only wait so long website to load; as high as 50% of users will bail for load times over 2 seconds, and 80% after 3 seconds. However, publishers also have competing goals of gathering analytics, advertising, and looking like a "modern" site. These concerns can, and need to be balanced. Like exercising and having a balanced, correctly-portioned diet, sliming down a website requires thought and effort. It takes time and often hard choices ("Do I really need to have the cupcake someone brought in?" "Is serving three-quarters of the initial viewport good?" "Getting up an house earlier will allow me a quick exercise in the morning at the expense of a little sleep." "Serving image- or text- only ads will speed page load, decrease bandwidth, and increase our reputation among readers, at the cost of diminished returns of Flash and video ads.")
While the AMP Projoect is suppose to be "open", it's largely to fully controlled and used by Google. IA is completely controlled by FaceBook. By using AMP or IA, the publisher is turning complete control over to Google and FaceBook for the types of components and interface that your page will have. Publishers looking to innovate or create interactive features relevant are out of luck -- they're constrained to simple types of common widgets. While prescribing only certain content from specific domains does help with caching and "quality control", it unreasonably constrains developers and creates Single Points of Failure.
Moreover, both AMP and IA are ways that Google and IA prevent users from entering the publisher's ecosystem. By featuring the publisher's content within the Google or Facebook ecosystem. While the publisher's navigation may be present, it's fighting with the display ecosystems more native navigation.
While a convincing publishers to value load times (and by proxy page weight) is a noble goal, AMP and Instant Articles (IA) accomplish this goal by purposely limiting the types of content a publisher can load. While this has some advantages, including resource caching and forcing developers to consider these issues, the straight-jacket approach is antithetical to how we should advance web technology. It solves Google's and FaceBooks problems, but only tangentially works in favour of the publisher, at the expense of diluting the publisher's brand and making the publisher "work" for Google or FaceBook, not the other way around.
Publishers would be better off realizing that they can offer lightweight pages on their own, without needing to be led-on by someone who is re-hosting their content, diluting their brand, straight-jacketing them, and making it more difficult for readers to stay within the publisher's ecosystem.