2. Hello!
I AM JO FRANCHETTI
Web developer advocate @samsunginternet
@thisisjofrank
https://medium.com/@jofranchetti
3. SAMSUNG INTERNET
◦ Our team speaks at events and helps to
support communities
◦ We produce code demos and blog posts
◦ Our team is super friendly and love to
work on projects with users of our
browser, come speak to me after the talk.
4. SAMSUNG INTERNET
◦ Web browser for android phones
◦ Specific UX for our users (privacy, VR)
◦ 3rd most popular mobile browser
◦ Available on android 5.0+ devices
https://samsunginter.net/
6. WHAT’S THE PROBLEM?
Large number of images on the page
Infinite scrolling
3rd party page-impression scripts cause bloat
Difficult/process intensive to calculate
?
12. “
The Intersection Observer API provides
a way to asynchronously observe
changes in the intersection of a target
element with an ancestor element or
with a top-level document's viewport.
25. THIS IS A SLIDE TITLE
Here you have:
◦ A list of items
◦ And some text
◦ But remember not to overload
your slides with content
Your audience will listen to you or
read the content, but won’t do both.
26. DOWNSIDES?
Not Pixel perfect
Not low latency
Values will be ‘out of date’ by the time you get to use them
Spending too much time in the callback will cause lag
Differing levels of support across browsers
?
Hello everyone, and happy pie day! lovely to meet you all and thank you for inviting me to speak! I'm Jo, You can find me @thisisjofrank on Twitter.
I'm a web developer advocate at Samsung Internet.
If you don’t know what a developer advocate is, well ...
We speak at and run events to support web communities,
We made demos and blog posts to explain new APIs and techniques
We love it when people are excited about the samsung internet browser, I’ve got some stickers here if anyone wants them.
If you’ve /not/ heard of samsung internet well...
We’re a web browser for android phones anyone on 5+ can download it from the play store
We’re really keen on privacy and security. We have tracking and ad blockers built into the browser if you want to use them.
We’ve got a VR version of the browser for the Gear VR, if you’re interested in VR come talk to me after too!
We’re also the third most popular mobile browser, so if you’re not testing in Samsung Internet, then maybe you should consider it
Being a person with travel anxiety, I managed to forget to bring you any stickers today, but I'll happily send a pair of socks to anyone who comes up to me after and tells me that they do test in Samsung internet!
Anyway, what we’re here to talk about is Intersection observer
So, why do we need or want this new API?
So first of all let’s talk about some common problems that we face as web developers
Often we work on sites that have a large number of images, these can slow the loading time of the page right down, especially if they’ve not been optimised
You might want to use Infinite scrolling, you often see it in social media services, or e-commerce
If you’ve got ads on your page, the Interactive Advertising Bureau has a policy that ads must be 50% visible for more than a continuous second.
They use ‘page impression’ scripts to calculate this and these can often be very large and ruin your download size.
Maybe you’re triggering an animation or call to action at a particular point that the user has scrolled to.
Calculating the position of the scroll and whether or not an element is in view is very process intensive.
You can hook up to the scroll event, or use a periodic timer and call getBoundingClientRect() on that element.
This approach, however, is painfully slow as each call to getBoundingClientRect() forces the browser to re-layout the entire page and will introduce considerable jank to your website.
So
Consider a web page that uses infinite scrolling.
It uses a 3rd party library to manage the advertisements placed periodically throughout the page,
It has animated graphics here and there, and uses another library that draws notification boxes and the like.
Each of these has its own intersection detection routines, all running on the main thread.
The developer may not even realize this is happening, since they're using two libraries that they may know very little about the inner workings of.
As the user scrolls the page, these intersection detection routines are firing constantly, resulting in an experience that leaves the user frustrated with the web site, the browser, and their computer.
What do we end up with?
Horrible sluggish feeling user experience
And ...
Large downloads for our users, frustrating if they’re paying for data.
What do we want?
We don’t want to have to do too much work on the main thread, we don’t want to have to poll, and therefore use processor power to calculate when an element is in view or not
We want to be able to control our own code and its file size.
How many of you have used libraries or third party scripts that you have no idea what they’re doing, you just know they work?
You don’t know if they’re using optimal techniques, you don’t understand how to fix them if they stop working.
We want to understand and be able to manage all of the code on our site,
We want no more third party scripts than are absolutely necessary.
What can give us all of this?
The new api that lets developers check whether an element is visible within the viewport, or any other scrollable parent element
To quote the spec -
The Intersection Observer API allows you to configure a callback that is called whenever the target element ( which is the one we’re observing), intersects either the device viewport or a specified element;
for the purpose of this API, this is called the root element or root.
Typically, you'll want to watch for intersection changes with regard to the document's viewport.
Whether you're using the viewport or some other element as the root, the API works the same way.
It will execute the callback function that you provide, whenever the target element crosses a specified amount of intersection with the root.The degree of intersection between the target element and its root is the intersection ratio, which will be given as a value between 0 and 1.
I’ve got a visial representation of the intersection ratio here -> https://codepen.io/thisisjofrank/pen/pdQzMr
Here you can see the intersection ratio, that is how much of the element is viewable, as a percentage.
So, what might we want to use this for?
One use case would be Lazy loading images
I’m sure many of you have worked on websites that contain lots of images.
And maybe you didn’t manage the content yourself, it was managed by other people who were uploading those images?
And maybe those people didn’t know or care about image optimisation, or sensible sizes for web images
And maybe they uploaded over 50 images that were 3000 pixels wide?
And you had to wait literal seconds for your page to load?
Or the content would jump about as images loaded on the page?
I used to work on the Livenation website.
There are many /many/ of images on the Live Nation homepage, and sometimes these images are uploaded at such high quality, that we ended up delivering images with very large file sizes.
Which made the page incredibly slow to finish loading.
And most of the images that were slowing the page down weren’t even in view yet, especially for the mobile users
As far as your users are concerned, they don’t really care about whether the images below the fold are loaded, they might never actually scroll that far.
Users want the bits of the page that they can see to load quickly and the rest to load when/if they need it.
So, how do we use IntersectionObserver?
You create the intersection observer by calling its constructor and passing it a reference to a callback function to be run whenever a threshold is crossed in one direction or the other:A threshold of 1.0 means that when 100% of the target is visible within the element specified by the root option, the callback is invoked.
The options object passed into the IntersectionObserver() constructor let you control the circumstances under which the observer's callback is invoked. It has the following fields:rootThe element that is used as the viewport for checking visibility of the target.
Must be an ancestor of the target.
Defaults to the browser viewport if not specified or if null.
Illustrated ***
We’ve got our target, that we’re observing
And our root
Next up in our options object is the rootMargin
rootMargin Margin around the root.
It essentially allows you to either grow or shrink the area used for intersections.
Can have values similar to the CSS margin property, e.g. "10px 20px 30px 40px" (top, right, bottom, left). And that will define when the callback will be invoked.
These can be negative numbers too, if you want.
If the root element is specified, the values can be percentages.
Defaults to all zeros
To illustrate
This is our root margin
The callback would trigger here
If you set it to a negative number then it won’t trigger til you get to the intersection with the margin
Then the final piece of our options object is the threshold
thresholdIndicates at what percentage of the target's visibility the observer's callback should be executed.
If you want to detect when visibility passes the 50% mark, you can use a value of 0.5.
If you want the callback run every time visibility passes another 25%, you could specify an array [0, 0.25, 0.5, 0.75, 1]. The default is 0 (meaning as soon as even one pixel is visible, the callback will be run).
A value of 1.0 means that the threshold isn't considered passed until every pixel is visible.
Lets say you set it to 0.5, in this instance it would fire here and here
Then, once you’ve created the observer, you need to give it a target element to watch
Whenever the target meets a threshold specified for the IntersectionObserver, the callback is invoked. The callback receives a list of IntersectionObserverEntry objects.
Lets have a look at those.
boundingClientRect is the result of getBoundingClientRect() called on the observed element.
Which will give you the size of an element and its position relative to the viewport.
intersectionRatio tells you how much of the element is visible.
intersectionRect is the intersection of these two rectangles and effectively tells you which part of the observed element is visible.
If we were going to, for example check whether an image should be in view, and then load, it we could check the isIntersecting entry and then create the image.
rootBounds is the result of calling getBoundingClientRect() on the root element
It gives you the bounds of the containing element
You can see them here https://codepen.io/thisisjofrank/pen/aYdoxe
So, back to our lazy loading images example.
Because we want the images to load smoothly we can lay out each image on the page, but give them all the same very tiny source image.
We then start the loading of the correct images when they hit an intersection with the browser viewport.
Once the image is loaded then we can set the source of that image to be the correct url.
We used a blur animation to distract the user while the load is happening.
So, now you’re all ready to use intersection observer, we need to consider one more thing...
what’s the support like?
Dammit IE11. And safari!
https://caniuse.com/#feat=intersectionobserver
But never fear, there are polyfills for intersection observer
We can check the support for Intersection Observer by checking if it is on the window object.
If it is, then there is no need for the polyfill, if not, load our polyfill file into the page.
So that’s intersection observer, there are a few other things that should be mentioned though, for example, what shouldn’t intersection observer be used for?
Something to keep in mind is that IntersectionObservers are intentionally neither pixel perfect nor low latency.
Using them to implement things like scroll-dependent animations are gonna fail, as the data will be out of date by the time you’ll get to use it.
Doing lots of work in the callback will cause your site to lag
You may find yourself having to check different entries for different browsers, so maybe check isIntersecting along with checking whether the intersectionRatio is greater than 0.
If you are interested in performance, or want tips on how to improve your site’s performance, or even just want to know why people are talking about performance all the time.
I’m running a conference in may, 10 & 11 in LONDON.
Your very own seren will be speaking there about accessibility and how it relates to performance.
Tickets are on sale now! Go check it out.