This blog post has been on my mind for quite a while given my background is in fullstack webdevelopment and a warning: I lack writing skills, so bare with me.

As the Internet grows, more and more challenges arise and more people are underserved by aging web technologies and paradigms need to be shifted in order for everyone in the world to have a fast browsing experience, almost with no regard to connection speeds.

The 2 most prominent initiatives in the past 3 years have been from Google and Facebook, the AMP Project and respectively Facebook Instant Articles. Before I go deeper into the topic, a bit about both of these new tools aimed at making the web faster and well, more instant.

The Google AMP project is more ambitious and has been launched in Oct 2015 according to Wikipedia. It stands for Accelerated Mobile Pages and its main purpose is to declutter current day means of webdevelopment and to make all pages load faster by caching the resulting page on Google’s servers ( coming back to this later on ). If you perform a Google search on your device and you click on an AMP enabled link, the page will magically appear inside an iframe, right there on the spot. The benefits are indeed visible, at least at first anyway.

The downside of AMP is that it brings a plethora of new HTML tags and rules that were not necessary ( and I firmly believe they won’t be ) complicating one’s application flow by having to serve AMP valid pages as an extra rel to your normal page, so the Google crawler can reach it.

Facebook’s Instant Articles is similar to what Google’s AMP is trying to achieve but in its own ecosystem ( inside Facebook apps: Facebook, Messenger, Instagram ) and with a smaller footprint in terms of HTML todos. One can get up and running with these new formats once you’ve connected your FB page to Instant Articles, submitted a minimum of 3 properly formatted instant articles for verification and use either an RSS feed to let FB pick them up or via the FB Api.

Now that I’ve covered what these 2 technologies do ( in a very short manner ) let’s dive deeper into what the issues are and using new, lighter and faster frontend web technology, we can make the internet great again.

First, the terminology seems to upset some folks at Google claiming AMP is an open source project that benefits everyone, but only works in Google Chrome and inside Google products like Search. Save it bud.

Next, why use a completely new but unnecessary HTML markup set when the original HTML is perfect as it is for delivering fast loading content?

The internet today is broken mostly because its progress when it comes to big publishers, has stalled. Big publishers given their mammoth like structure have always had issues with adapting to new technologies ( even if some might argue the contrary ). One of the first things I do when visiting any site is to open the source code to have a look at what new techniques I might find when reading the HTML code and to my surprise these findings are very rare.

Facebook’s Instant Articles are no better and lures its victims ( ie: publishers ) into its walled garden with an ever decreasing reach with the promise of a faster experience without actually disclosing you will be at the mercy of the app owner.

AMP differs from Instant Articles since it lets you format the page the way you want it visually whereas FB IA will restrict the styles to templates which do not vary from pub to pub making it harder to distinguish different publishers or to mitigate brand theft.

On the other hand, having spent the last month more on LinkedIn’s app, I noticed most pubs have opted for putting their pages on AMP ( for the sake of organic reach in search I suppose ) renouncing their own brand URLs in favour of Google’s ampproject.com subdomains. Why oh Why?

Even if the garden is bigger, the wall exists. I am going to list below all the things that come to mind why NOT TO USE AMP NOR FB Instant Articles:

  1. It locks you in to specific platforms ( AMP – even if open source, only works in mostly Google products )
  2. Your monetisation suffers given each only allow mostly their own inventories, locking you in
  3. They’re both unnecessary technologies given the current state of webdevelopment – think VueJS
  4. They bloat any application given you have to treat URLs differently depending on who’s crawling or what’s being sent to FB
  5. All pubs lack the beauty and functionality of well written Javascript Apps
  6. More power is transferred to the internet giants of today, leaving you the pub with the illusion of control ( until the day the FB Feed Algo changes or Google releases a new update )
  7. More resources have to be invested towards maintaining and testing these 2 new ( unnecessary ) worlds, with the hope that engagement, retention and monetisation will go up
  8. The instant experience was not invented by the 2 vendors. It exists outside their grasp and oh man, it’s beautiful ( will post more about this in a future post ) – think VueJS ( not React nor Angular )
  9. Both parties will argue that with their proposed tech, your metrics will improve ( including ads ). Please take this with a grain of salt… actually don’t believe a thing until you’ve tested your assumptions in a real live environment
  10. A lot of ad blockers and firewalls block Google content making your hard worked AMP pages hosted on Google’s servers, inaccessible

Now, as you may have noticed in the above list, VueJS tends to show up in a few places and for a good reason. It’s light, small in size and fast in execution. I am biased towards it but you don’t have to be. There are tones of new reactive JS frameworks popping up, each redefining how organisations think about their web presence.

One of the biggest opportunities that lie in the horizon are PWAs or Progressive Web Apps or in short: JS based websites that act like an app. There are many pros on why this is the next evolutionary step one of which is the ease of build and the crossplatform functionality – your PWA will run on any OS inside a browser window: how cool and useful is that?

Chrome has the biggest market share in terms of usage at the moment and low level APIs are being opened to the public so a PWA can communicate with the device it runs on ( talk about native payment on Chrome / Safari, both web and mobile ).

All the above are just scratching the surface on what a PWA can do but, let’s go the simple route: you want your web site to be a fast loading low resource consumption beast, without having to worry to much, right?

Here’s a setup that will surely achieve this:

  1. A basic shell for your website ( without the fancy wording: some initial code to be shown to the user like a header and a loading screen )
  2. Pre-gizipped CSS at the top of your HTML page
  3. VueJS + modules + your app compressed, minified and pre-gizipped at the bottom
  4. All your content served via your API ( html content, bits of info, json etc )

The pre-gizipped part if just a preference of mine to keep the server light when requests for static resources come. No need for on the fly gizipping so the files just get served.

On a recent PWA, the results were amazing and the whole website loads in under a second and leveraging browser caching you achieve even better results. You can even try using P2P CDN solutions and then you have an instant experience which I dare to argue is even faster than what native apps can do.

TL;DR

  1. Google AMP and FB Articles restrict your business
  2. There is no need for additional HTML tags to make your web apps blazing fast
  3. Upgrading your systems to 2018 web tech is your best investment
  4. Publishers control the user experience all the way
  5. VueJS is the right choice for the job + APIs

If you’ve read this far you’re either here to make a valid point against what I wrote which is something I encourage or, despite my low level writing skill, you like what was being argued. Either way, drop me a line at [email protected] and share your thoughts.

Daniel