Univision and ReactJs — The Beginning of a Love Affair
At Univision, improving and maintaining great web performance is one of our biggest goals. This wasn’t always the case, and the path to get us there is paved with sweat, tears, blood — ok, maybe not blood — and a lot of hard work from our product, design, and engineering teams. In this article, I will share our experience as a team of migrating from an old monolithic architecture to a more modular and micro-services inspired setup.
Univision? Who Dat?
For those who don’t know who/what Univision is, we’re the top American media company serving the Hispanic and Latino populations in the United States and abroad. Engineering teams at Univision are in charge of building and maintaining the user experience found at univision.com. This entails work around things like enhancing our video experience, ads integrations for monetization, analytics integrations, and presenting our original content in cool ways 😎!
In October of 2015, I was asked to join their team to help improve web performance on their sites. Slow loading pages meant higher bounce rates and lower ad viewability. Anything prefixed or suffixed with -ads- means money 💰 and let’s face it, that’s a big part of why we do what we do. After many months of work, we were able to improve web perf metrics by upwards of 50%–60%, but due to the frontend code being tightly coupled to the rest of the CMS, of which we didn’t have full control, the ROI for performance work started to dwindle. Fun stuff happens when engineers are backed into a corner and more often than not, that means we’re re-architecting/re-designing/re-platforming … re-doing something!
But wait! We’re getting ahead of ourselves. Let’s take a step back review why would we even do this, to begin with.
Why spend months fixing what isn’t broken?
Our team was bored to death (not to mentioned frustrated) with the old stack we were stuck with.
George Bernard Shaw couldn’t have said it better. “Progress is impossible without change…” To me, that means “forget about the old don’t fix what isn’t broken adage and always keep an improvement-conscious attitude”. Here are some reasons why change made sense to us.
- Our bounce rates and ads viewability metric weren’t quite there yet.
- The cost of doing more performance work on the old setup far outweighed the benefits we were going to get.
- Pushing new code to production was a mission that required 20+ people on the phone to make sure everything was ok after (guess what, more often than we liked, everything was not ok after).
- Innovating on UI/UX was hard on a semi-closed codebase.
- Our team was bored to death — not to mentioned frustrated — with the old stack we were stuck with.
Where are we going?
Once you know you need to change, the next big question is, to what? In order to address our whys, we followed two main streams of work. We upgraded our tech stack and changed the architecture of our application layers, specifically surrounding the frontend.
- Web application re-architecture.
We knew we had to split things up in order to meet our goals, so we went with a Headless CMS architecture where our frontend layer lives outside of the CMS codebase. This allowed us to make and deploy frontend changes independently of the backend, thus speeding our release rates. We took this opportunity and invested in containerization so we could deploy our frontend code as docker images in AWS ECS. I’ll talk more about that setup on a future article though, let’s stay on topic.
2. Frontend stack upgrade.
“There’s no such thing as greatest and latest of all frontend frameworks/libraries; just a bunch of tradeoffs and compromises and you ultimately have to make a call based on what you need.”
Now to the fun part (if you’re a front end dev 😉). Moving away from the monolith is cool, but somewhat worthless (performance wise) if we just copy the old front end code to the new layer. We decided to upgrade our stack to the latest and greatest of all frontend frameworks/libraries. We just didn’t know what that was. Spoiler alert, there’s no such thing as “greatest and latest of all frontend frameworks/libraries” — just a bunch of tradeoffs and compromises and you ultimately have to make a call based on what you need.
We did some research and concluded we wanted to use one of Vue.js, Angular, or React. We deemed Vue.js too new at the time for us to get the courage to use it (did we mess up?) so the decision came down to the timeless debate of Angular vs. React. To help us decide, we created this Google sheet where we listed what mattered to us and rated each candidate.
In the end, we concluded both solutions would give us the features we were looking for. The decision came down to other teams in some of our sister companies already using React and the promise of being able to share code with them. Oh yeah, forgot to mention that, we went with React! It’s a party!
We were worried about Javascript fatigue when it came to setting up a react based stack. We love challenges though so that didn’t stop us. We took some time in setting up the foundation for the application before writing a single line of production UI code and this paid up very nicely. Our stack ended up being a combination of many things, most notably including React, Redux, Webpack, NodeJs, and ExpressJs deployed as a docker image on AWS ECS.
So…where’s that love affair you speak of?
In the months following the decision to move to React, development satisfaction went through the roof. We were free to engineer our frontend however we saw fit without the constraints imposed on us by the previous CMS architecture. Even more impressive than that, we were able to meet all of our initial goals. We’re totally in love with React. Here’s what we accomplished:
- Metrics around bounce rate and ads viewability greatly improved.
- Web performance was approached as a feature of the new frontend which made the new site many orders of magnitude faster than the old one.
- We are now free to do frontend deployments any day, as many times as we want.
- We are free to experiment and innovate in UI/UX in order to bring quality experiences to our audience, backed by the power of open source software and the Javascript and React communities.
- No one is bored anymore. No one!
What’s next?
There’s so much I didn’t tell you about, so I plan on writing more articles to give you some insights into the things we’re doing at Univision and how cool and awesome our engineering teams are. We’ll talk about things like
- Webpack features we love,
- react native,
- code splitting,
- handling of CSS (to styled-components or not to styled-components?)
- progressive web apps,
- google amp,
- video integrations with the JWPlayer
- engineering culture,
- and those party parrots; they’re everywhere.
Thanks for reading! Until the next time!
