Closed Bug 1040933 Opened 5 years ago Closed 5 years ago
Increase the snippet deployment frequency
Current state: The Firefox browser checks for new snippets if 24 hours has passed since the last time it has checked for snippets. If the user is online daily (or more), this happens once every 24 hours. If the user hasn't been online for more than 24 hours, the frequency will be the rate at which they go online. Read more: https://wiki.mozilla.org/Websites/Snippets/about:home_101 Problem: If a new opportunity presents itself and an update or new snippet needs to be deployed, Engagement needs to wait 24 hours to ensure that the snippet has reached the available target audience. This 24 hour interval is not frequent enough to capture opportunities or to resolve problems. Imagine the scenario of having a snippet deployed that has some problem. If we fix the snippet on the server quickly and people have received the faulty snippet, they will continuously see the faulty snippet for the next 24 hours until their browser checks the server. Goal: Increase the frequency at which the browser checks for snippets to something less than 24 hours. The ideal goal is hourly, but we understand this may be have some negative consequences and could be expensive thus we would entertain other larger intervals. We would like to see the cost/benefit analysis of different intervals to determine, which would be best to resolve the problem above.
CCing gavin, as this will both eventually require a desktop Firefox change, and will also require their input on how much of our users' bandwidth we're willing to sacrifice to the eldritch spirits of timely user engagement.
What's the typical size of the snippets request/response? Unless we're downloading a lot of snippets I doubt this will matter from the user's bandwidth usage perspective; I think the only real constraint is server-side impact.
It's probably best to file a separate Firefox::General bug for the in-product change, which should be trivial.
(In reply to :Gavin Sharp [email: email@example.com] from comment #2) > What's the typical size of the snippets request/response? Unless we're > downloading a lot of snippets I doubt this will matter from the user's > bandwidth usage perspective; I think the only real constraint is server-side > impact. Right now, up to 300kb, but let's say a max of a megabyte or so. I figured it wasn't an issue but I also have no experience with how much we care about stuff like this so I wanted to double check. Yay!
(In reply to :Gavin Sharp [email: firstname.lastname@example.org] from comment #2) > What's the typical size of the snippets request/response? Unless we're > downloading a lot of snippets I doubt this will matter from the user's > bandwidth usage perspective; I think the only real constraint is server-side > impact. Also, Mike has defined a more efficient delivery of snippets that is better than we have now. Currently, users download snippets regardless if they have them already. The future state that Mike has proposed will only deliver snippets to a user if they don't already have them locally cached. So, if we increase the frequency of snippet delivery and a user already has the snippets, the only data transmitted a a ping and a hash compare. We wouldn't want to increase the frequency of snippet delivery until the more efficient method of implemented that is easier on the end-user and servers.
Gavin: I filed bug 1046297 in Firefox:General about the code change to about:home.
Snippets on desktop update every 4 hours now. Marking this Resolved/Fixed. Thanks everyone!
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.