DS Rebuild - Prototype

Performance Over Complexity

Agenda

  1. Why?
  2. Frontend
  3. API
  4. Advantages

  5. Stats
  6. Future

 

Why?

 

  • Page speed is becoming more of a concern across all Hearst sites, especially DS
  • We met to discuss potential for improving site/ad load times in general
  • The Xmas Gift Guide build showed potential for super performant API driven sites
  • We were encouraged to pick up Proof of Concept work
  • Why not try to replicate current DS with perfomance as the key goal

Stage 1

  • Initial prototype of homepage built. Thought process purely speed, without thinking about scalability etc.
  • Using a dummy API with a node front-end.
  • Only loading critical assets on page load, lazy loading the rest
  • Starting to develop modular components with discreet assets with help from Webpack
  • Issues with reusable server/client side rendering

 

 

 

Page load times were massively improved but it wasn’t scalable & rendering was tricky

Stage 2 - Front End

 

Salvador's skills

  • Adding new custom HTML template element called <app .../> which allows for insertion of custom components
  • It is a compiler for those elements, which turns them into raw mustache templates
  • It has an lazy loading library, for loading elements after the critical path and inserting into the page.
  • It has a request library, built on top of redis, that allows requests on both the server and client, using the same syntax and storing requests in a local redis instance for incredibly fast response times.

 

 

 

To solve issues with rendering on client and server using the same code, we needed an alternative templating system with a React-like infrastructure but without the overhead of the react library, and built on mustache for ease of understanding... solution? Salvador!

 

For mustache compilation and rendering it uses hogan.js by Twitter which allows for much faster rendering times at smaller file size than the default mustache library!

Stage 2 - API

  • Limitation by using existing MOS1 db structure and CMS to ensure compatibility
  • Priority was to build a performant API structure for accessing and returning data from existing structure.
  • Built on PHP7 and Laravel’s light weight framework, Lumen.
  • Everything sits behind Redis cache on API server too.
  • Vast majority of requests will never hit database and in addition to redis on front-end means low load and high performance

 

 

 

 

 

 

 

 

API - Request example

  • GET api.digitalspy.com/v1/content/latest/list?limit=10
  • Hit ContentController and 'latest' method
  • Check if cache has the data, if it does we quickly return the JSON object of data
  • Otherwise hit the db and store the JSON object for 60 seconds in memcache

Advantages

  • Much faster load times
  • Node can handle a lot more concurrent requests that Apache, which should lead to better site uptime and reliability.
  • Faster load times and better user experience as a result will lead to a lower bounce rate, increased ad viewability and more revenue!
  • Hardware costs should also be lower as less hardware needed for better performance.
  • Happier users! No more waiting 10s for page load!

 

 

 

 

 

 

 

Dev Advantages

  • Independent and simple front-end build makes updates and any future changes simple.
  • Front-end is data agnostic, so could easily consume data from MOS2 API or whatever data source we choose to use.
  • Modular structure, means components are reusable across site (or even multiple sites). Easy to unit test.
  • Division of responsibility between front-end and backend devs, means specialists can work on areas where they have expertise without affecting each other.
  • Happier Devs! No more sifting through 3 repos to find a variable

 

 

 

 

 

 

 

Stats

NOW:

FUTURE:

Future

  • Current focus is to build out an alternative homepage that could be A/B tested to measure performance.
  • Building out all endpoints.
  • Build out new page types
  • Ads!
    • We are in the process of building an optimized ad layer to work with this front-end stack.
  • New features like pub/sub requests to automatically serve new content without refresh. 
  • Super easy Native Apps.
  • The possibilities are endless!

 

 

 

 

 

 

 

 

Questions?

DS Frontend POC - Apr 7, 2016

By Hearst Magazines

DS Frontend POC - Apr 7, 2016

Run through of proof of concept work, rebuilding the front end of DS with performance as the primary goal

  • 1,030