It’s common to use screen width or display density to decide which assets to serve a user. But sometimes a user with a larger screen or higher-res device has a poor network connection, and sending them larger images only makes things that much slower for them in loading the site. It would be great if we could account for the network conditions of a specific user in determining what we should send them.
Earlier this week, Google posted a reminder that they are starting to switch over to mobile-first indexing for their search results and rankings. Over a year ago, they had announced that they were experimenting with it, and now they’re ready to start rolling it out.
How often have you had a web site appear to load quickly, only to find that you couldn’t actually click or scroll for a while? Sometimes a site can have a fast first paint, but if the page isn’t also interactive quickly, users can quickly grow frustrated, and even leave the page.
When executing scripts on a page, one thing we want to avoid is creating unnecessary jank for the user. This particularly true when we’re doing a lower priority task that doesn’t have to be called that exact moment. In those cases, it would be helpful to be able to delay those calls until we’re sure the browser isn’t working on something more important.
Each webpage is composed of various elements. And knowing where these elements are in relation to the viewport can be extremely helpful. For instance, this knowledge allows us to lazy load images, or to load additional content at the bottom of the page (e.g. infinite scroll). This knowledge can also helpful in determining when to trigger animations, or in reporting certain analytic information (e.g. which advertisements have been viewed, or how far down the page a user travels).