Periodic Background Sync

[00:00:00]
>> What's next after background sync that it's actually pretty simple. The next one sounds good at least by name it's periodic background sync. This one is a little bit more complex not in the API, but in how we set up this. In fact, 5% of the websites are using background sync and periodic background sync, it's 002 or something like that.

[00:00:29]
So it's still an API that a lot of developers are not using yet. In this case, the PWA will ask the user or the browser for permission to periodically execute go in the background, every hour, every day, every week, that's the theory, okay? So our code is asking the browser, hey, browser, I wanna execute code every day, can we do that?

[00:01:01]
The spec doesn't say anything about how the browser should respond in terms of if it should ask the user or not, today this is Chrome only right now, and Chrome is not asking the user. I will explain how that works in a minute. And then a periodic sync event will be firing the Service Worker similar to the one that we saw before.

[00:01:26]
So every day, if it's granted, the browser will wake you up your Service Worker, and he will fire you that event, okay? It's your turn, the wherever you need. The user is not using your app, it doesn't matter the next day, it will wake you up again. Okay, your time, that's how it works.

[00:01:49]
So you need to set up the synchronization time interval, and also the browser will say, okay, I will wake you up only if some battery and network conditions are met. If you're in roaming with 5% of battery, I'm not gonna do that, okay? So it's not guaranteed. It's based on a best effort scenario.

[00:02:13]
And typically, we access the network, but yeah, we don't need to, but this is for example the idea the use case is like a newspaper app and media app. So every time every morning you wake up you open your app and the database the index CV database already filled with recent apps cached with recent images.

[00:02:32]
So it's really fast, and it feels like it's already in your phone because it's already in your phone. Okay, so that's the use case. Right now, chrome is fighting this with a maximum of once every 12 hours. It's kind of an experiment trying to see, okay, let's see how we are using this to avoid abuse and so on.

[00:02:58]
Execution frequency, and also granting you permission, will be based honored on a site engagement score defined by the browser. I say what? For every user on every device, Chrome is actually creating a score for every website, okay? It's called the engagement score. So if this is the first time you access the website, the engagement score is low.

[00:03:29]
And when you ask for periodic think, it will say, no, you don't have permission yet. But if the user is using your app every day for a week, then the engagement score is higher. Then, you ask again, and the browser will say, okay, now I will grant you periodic background sync right.

[00:03:55]
You don't have control, we don't have control we as users and we as developers, no one has control, only the browser about what's going on, okay? Makes sense? I'm not sure if it makes sense, but is it clear at least? So, this is a little bit more complicated in terms of how we use this, because we actually need to request permission.

[00:04:17]
But for that, we use this permission API. I'm not sure if you have used that one. It's like a modern permission API that is multi-permission, so you can request geolocation plus camera plus periodic sync all at once in one dialogue, okay? That's kind of the idea. You request periodic background sync, but remember, this is actually requesting permission to the browser, not really to the user.

[00:04:48]
The user will never see a dialog, and the permission can be granted or not, as simple as this. Then, if it's granted, then what you're going to do is to register a periodic thing similar to how we register a sync and normal sync. The only difference that we have a tag, and we have them in interval in milliseconds, that's all.

[00:05:21]
So then because you were granted right for this every 12 hours. Your service worker will wake up, and he will execute the background sync event with that tag name. That's why Dev Tools will let you start recording the event for three days because it actually, it's very difficult to debug this.

[00:05:48]
So you need to wait three days to see if it worked or not. Make sense? And typically here you check first if the API is there, that's all. And finally, you handle this on the service worker. There is actually the same thing as think, follow that with a different event name, that's all.

[00:06:10]
>> So you might even just use the same functions for sync as a periodic sync and.
>> Just Periodic sync was definitely.
>> From period sync and sync and messaging, you can call the right functions at any time. So, in our code, then I have another event handler for background periodic sync.

[00:06:31]
So the only difference that we need, we also need the service worker registration. So we could even create a function for this. So when the service worker registration is ready, we are gonna ask for permission or check if we have permission or not. It's actually the same if we request permission, and we already have it, grant, nothing will happen.

[00:06:59]
So what I need is to then create a permission status, for example, and we're going to say, we're going to wait for navigator.permissions.query. And the objects, it's an object with the name, periodic-background-sink. Okay, so if it's, Date. If it's granted, Then we can register now the sync. In this case, we talk to periodicSync.

[00:07:50]
That's the manager, and we register like for example daily news wherever, that's the tile that you define and there is an option registration options with a mean interval. I mean, you can request every second, but we know it's not gonna happen, okay? So yeah, it happens, at least, by 12 hours.

[00:08:21]
We should make the mask, before that's simpler. And, that's all, so you cross your fingers, and you try because you don't know what happened. I mean, you could know based on the status, or you can know if it was granted or not. But if it wasn't granted, try again tomorrow.

[00:08:51]
So you don't know why, you don't know what else that you need to do to get the permission granted. You just try again next time. If the site engagement score gets good enough, at some point the browser will tell you, okay, yeah, you can do that. And by the way, that's how iOS native app background execution works right now, if you have an app.

[00:09:19]
That is not part of one of the list of background exceptions like if you have navigation, or background audio, background video. If you have Facebook or Instagram and you are requesting background just because you want background without explaining why, the OS will grant you background rights based on an app engagement score.

[00:09:44]
Based on stats based on stats and says okay, the user seems to like your app is using your app every day. Okay, I will grant you five minutes per day, that's how iOS works. So this comes from that side. Okay, so in terms of something to see, there isn't anything to see here.

[00:10:08]
It's just requesting that and then periodically, you will be able to execute some code in the background. Even if the user is not using your app anymore. And if you wanna notify the user, if the user granted you permission for web notification, you can notify the user in the service worker.

[00:10:29]
So from the service worker, it's actually pretty similar to this. But it's periodic sync, and here, I should use. That's all. It's the same, what you can do there, anything that can be done in the Service Worker. Index tv, fetch requests, you can update your assets' cache. For example, for the use case of an app, that it's updating the resources.

[00:11:08]
[COUGH] You can go every day and see if they're updated CSS files for a PWA. So then the PWA every day can update the assets, even if the user is not using the app. But we can increase the opportunity for the user to always get the fresh app when the user is opening the app, because every day we are updating the assets.

[00:11:38]
Okay, make sense? And as we for Chrome is offering us the tools within application to debug this from periodic sync, the tester here, and also periodic background sync recording for three days. So for example in our case we're using localhost, is there any sort of like permissions to automatically grant like local?

[00:12:07]
>> Yeah, in fact, let's look at this.
>> So I'm assuming our engagement score might be really low for localhost 8080 or whatever.
>> So-
>> Maybe really high.
>> Permission denied right now.
>> You look at this, we can try to request our app table, by the way, navigator there.

[00:12:26]
So I can try this in the console, right? We can see it was denied. So say but it's localhost. Yep, but this port, at least it's new for these because I'm using Chrome Canary. So I'm using this one. Do you have a clean chrome without extensions? So it's saying, no, you know what?

[00:12:55]
No, I'm not granting you permission. So if I come back tomorrow, maybe it will work. If I try the other Chrome, and it's a port that I typically use, it will grant me permission. Can you see what's the site engagement score? Well, if engagement score chrome, if you Google that, it's a double from zero to 100, and here it explains, okay?

[00:13:27]
How it's been declared, how that works and there is a very low level page where you can actually see what's going on. I think also there is a common line command that you can, where you can actually force an engagement score. But yeah, it's actually had hard to test it.

[00:13:49]
Give me a yes or no. Let's for example, let's see. Let's open the other Chrome. Not the Canary, this is the other one. And let's take Twitter. So if I use Twitter. Come on, Elon, what are you doing? Elon, Elon. So if I request, it's denying. Okay, it's denying me also, why?

[00:14:23]
If you're done no. Can you do something about that, nope that's how that works and what about google.com? Try one more.
>> Stack Overflow will be high enough.
>> Deny.
>> If you open the thing is the discards, you can see your engagement score for the different tabs.

[00:14:49]
>> On the top. Site engagement score, it's zero job 100. Twitter is almost 60, Google is 74, but it also gave me, no. Can you do something? No, that's all you can do. You can try and try again and try again until you will get a yes at one point.

[00:15:15]
Okay? By the way, if you have an installed PWA, that's a different story. The site engagement score goes up immediately because the user has made like action, the user has installed an app. So if you haven't installed PWA, the engagement score should go up. I'm not sure I think I do have this squoosh.

[00:15:43]
Sorry with that one, and then we can move on to the next one. So if I try perodic_background_sync, granted. Why? Because this is a PWA that I have already installed. Because I have the app installed, the site engagement score is higher. So now it's granted for this website.

[00:16:08]
So now I'm ready to register periodic background sync operations. Okay?
>> Was there a specific threshold like ad that you parsed? That I parsed? So we can try to see. Squoosh. [COUGH] No, in fact i it's here in 12. So it's even worse, but I think in this case, it's granting you because it's installed, it's an installed PWA.

[00:16:49]
So this is actually changing on every Chrome version. But if you're 90, if you have 90, it should be, you should be good if you're using, install the PWA. You should be good if the user has granted you notification permission you should be good. So in that case the browser says okay, if the user has granted notification permission the user wants to know about this website, so I think it's a sign that, yeah, we should grant periodic backgrounds in.

[00:17:20]
But again, these algorithm heuristics here, are completely unknown and private to the browser.