[docs] Reduce by /50 the website traffic #14122
Conversation
|
If this guarantees that every visit will display the most recent version then I have no objections against a service worker. But if the page is only up-to-date on the "N+1" visit then I would like to hear the argument for a service worker since I don't see the benefits right now following the argumentation below.
Why is this something we should be concerned about? We're delivering a static documentation with some demos. I don't understand why this should meet the same standards as a progressive web app? There are certainly some requirements that any website should meet (e.g. https, responsive) but some of them I don't see as as useful requirements (e.g. first fast load on 3G or fast page transitions when 97% of our traffic is from desktop). Maybe I'm being too pedantic about the word "web app" but I don't understand the argument why a good PWA score is a requirement for docs. Why build a Progressive Web App? lists some features that don't seem to apply to docs. E.g. do you think that we will improve our conversion rates because an online shop made the observation that a PWA increased theirs? I don't think these usage patterns are comparable. Some benchmarks:
I'm not making the argument that we should reject a requirement because nobody has it either but rather that other popular packages don't see an argument for a high PWA score either. |
@eps1lon Yes, it does. At the cost of an unexpected browser reload when the user come back. It should be harmless. At onepixel.com, we do that too as soon as we deploy a new version. PWA score doesn't really matter for a documentation website. What's interesting here is that we can skip the most important network request: the index.html for consecutive visits. |
|
haha, im just glad olivier figured out what was going on. to be honest i was pretty surprised by the numbers too but couldnt explain it |
|
@sw-yx Let's try it out. We will release it this weekend. Could you keep us updated with the network request & bandwidth implication? :) |
|
On which note @sw-yx, any plans to introduce some traffic stats in the Netlify dasboard? It would be very helpful. Thanks for the amazing service in any case! |
|
hi folks! request - yes, i'll get a monthly report so early Feb. traffic stats - yes but i dont have a timeline from the product team on that so not sure when :( but i'm pretty excited, CDN level stats should be >> google analytics stats we're also adding bandwidth usage to the dashboard, that will be up first before the rest of the analytics stuff thank you guys for moving so fast. saved us some money there for sure. |
This change is a follow-up on @sw-yx from Netlify with its concern regarding the traffic generated by Material-UI. Our users have made ~160 million requests in December, x4-5 away from the top website on Netlify. It's insane. This change explores another tradeoff. We cache the visited page for future offline usage. The Chrome audit PWA scores don't change.
I would expect less traffic with the new service worker than without any service worker logic as we skip the network requests for repetitive navigation on the same URL (index.html have no-cache HTTP headers).