less aggressive upfront ads caching

Financial-Times / n-service-worker

❌ DECOMMISSIONED Global service worker component for next.ft.com

5 stars 2 forks source link

less aggressive upfront ads caching #145

Closed wheresrhys closed 6 years ago

wheresrhys commented 6 years ago

The sw ads test didn't result in an uplift, which was weird. So a few thinsg in this (and the previous) PR

Improve how flags and caches work, meaning there's less overhead in deciding whether to hit the network
Stop precaching ads calls for section pages - most users don't visit these pages, so we're clogging up the bandwidth for most people for no gain
stop being selective about which streams to cache using a huge regex - huge regexes can be very slow

Left some stuff commented out as we may want to try some of it again later

wheresrhys commented 6 years ago

In this particular case we saw a downturn in ad viewability and load times as measured in beacon. That seemed to match what Alex and I saw in our dev tools (i.e. calls for ad resources taking ages when going via sw, even though they were cached)

wheresrhys commented 6 years ago

But some advice on testing

Unregister sw and look at timings

Reload the page and look at timings

In the application tab of dev tools, right click and refresh IDB and Cache Storage, then delete a few caches, then reload again

I tend to do it on a throttled connection to get a real world picture (service worker does take some time to respond even fetching from cache, which can be slower than superfast local network, but probably faster than most users' networks... we should nevertheless play around with optimising the time in sw