UID Cookie

Background

While setting the performance goal for any particular page on our site, and starting discussions around the performance budget...

• Desktop / 1.5Mbps DSL
• Visually loaded < 4 seconds
• Fully functional < 5 seconds

... we examined the cookies being loaded to make our site functional. The list was enormous, over 30 cookies were being passed back and forth for almost every call to the site, including for assets like js/css/images. Many of these cookies contained legacy data that was rarely, if ever, used after it was set. Many others contained personal information that should never have been saved into cookies in the first place:

• Customer ID
• Cart ID
• Brand Affinity
• Mailing Address!
• Email Address!
• Last visited page
• Last viewed product id
• Affiliate tracking ids
• Subscription preferences
• Last access device type
• oh my...

As an online customer, I want my personal information to be served securely, but quickly, because both my time and privacy are important to me

Assumptions

• Fewer/smaller cookies = a faster site
• No personal information in cookies = less risk of compromising customer privacy
• Consolidated cookie = smoother cross-device experience

The Process

In discovery: Set up a mini test site to determine how much speed we could gain by severely cutting our cookie overhead. This would include a test db to store a customer cache based on the levels of security needed, a happy-path service to parrot back the customer data requested and page-level security to mimic real-world conditions.

1. Build a three-tiered db to store/retrieve customer data in place of cookie storage.
2. Build a service to be able to serve customer data based on the UID and level of data required.
3. Adjust the site code to set and maintain only a single site cookie containing the unique UID.

Next...​

• Move js/css/images to a separate domain. This domain should be as short as possible. With a different domain, no cookie overhead bleeds over with calls for these assets.