Vistaprint

Versioning

Performance first

A customer should only need to download some given CSS one time during their Vistaprint visit.

Makes sense, right? We certainly wouldn't want our customers to download the same CSS over and over again every time they navigate to a new page. So how can we make sure that the CSS is downloaded once and then shared between pages?

As it turns out, that's not very hard to do! Rather than embedding the CSS directly into each page, we host the CSS in a common location and have each page link to it. Once the customer downloads the CSS for the first time, their browser will cache the styles for other pages to use.

Versions

Style-sharing seems straightforward, but it gets tricky when you add versions into the mix. We publish new versions of the CSS (in the visage-core repo) whenever we make an update. Teams can upgrade to a new version and test it out before it goes to production. This gives us confidence that we're not introducing visual bugs.

But visual consistency and caching performance both suffer.

Teams are not always able to upgrade at the same time. One team may be using version 8 of the CSS while another team is still back on version 6 because they haven't had time to upgrade. This creates visual inconsistency as the user moves from page to page and sees slightly different styles. And it also creates a performance issue because the customer needs to download both version 8 and version 6 of the CSS during their journey through the site.

Version synergy

In order to get the benefits of versioning while maintaining visual consistency and caching performance, the Visage team takes the following approach:

  • We'll define and communicate a specific CSS version that is "recommended" for all pages

  • We'll send an email (to #help-visage, and to the "UI Library Announcements" distro) whenever that recommendation changes

  • If you're not using one of those visage versions, you should upgrade ASAP in order to synchronize your CSS version with everyone else

Ideally (for visual consistency and caching performance), every page on the site would upgrade to the recommended version immediately, but we realize that it may not always be feasible to update right away. So after a new recommended version is announced, we request that folks update their pages within 2 weeks. This 2-week runway should allow for teams to schedule the upgrade without interrupting ongoing work.

There may be exceptions to the above -- for instance, if there's a significant brand change going on, and we don't want the user experience to differ greatly as the user moves from page to page. In these cases, we will announce explicitly that there's a pressing need for teams to all update more quickly.