Lazy Loading Images and Video | Web Fundamentals | Google Developers
Jeremy Wagner offers a deep dive into lazy loading images (and video) with some advice for considering the no-JavaScript situation too.
Jeremy Wagner offers a deep dive into lazy loading images (and video) with some advice for considering the no-JavaScript situation too.
Don’t let the title fool you—this isn’t just for parallax scrolling (thank goodness!)—it’s for triggering any CSS updates based on scroll position. Using CSS custom properties makes a lot of sense. The JavaScript/CSS bridge enabled by custom properties is kind of their superpower. (That’s one of the reasons why I don’t like calling them “CSS variables” which makes them sound like Sass variables—they’re so much more than that!)
Browsers have had consistent scrolling behavior for years, even across vendors and platforms. There’s an established set of physics, and if you muck with the physics, you can assume you’re making some people sick.
Guidelines to consider before adding swooshy parallax effects:
- Respect the Physics
- Remember that We Call Them “Readers”
- Ask for Consent
Given all the work that goes into a powerful piece of journalism—research, interviews, writing, fact-checking, editing, design, coding, testing—is it really in our best interests to end up with a finished product that some people literally can’t bear to scroll through?
This looks like a handy JavaScript library for scroll-based events. But “scrollytelling?” No. Just …no.
One more reason not to use sticky headers on mobile.
I’ve gotten a little tired of showing up to a Medium-powered site on a non-medium.com domain and getting badgered to Sign Up! or Get Updates! when I’m already a Medium user.
A Chrome extension to Make Medium Readable Again by:
- Keeping the top navigation bar from sticking around
- Hiding the bottom “Get Updates” bar completely
- (Optionally) hiding the clap / share bar
- (Optionally) loading all post images up front, instead of lazy loading as you scroll
Shame there isn’t a mobile version to get rid of the insulting install-our-app permabutton.
A three-part series by Remy looking at one interface pattern (a sticky header) and how his code evolved and changed:
A ludicrously deep dive by Nolan into how scrolling works in web browsers. No, wait, come back! It’s more interesting than it sounds …and it certainly isn’t as simple as you might think.
For instance, do you know the difference between the following scenarios?
- User scrolls with two fingers on a touch pad
- User scrolls with one finger on a touch screen
- User scrolls with a mouse wheel on a physical mouse
- User clicks the sidebar and drags it up and down
- User presses up, down, PageUp, PageDown, or spacebar keys on a keyboard
If you ask the average web user (or even the average web developer!) they might tell you that these interactions are all equivalent. The truth is far more interesting.
This comes complete with lovely animated illustrations by Rachel.
I made a little tweak to The Session today. The navigation bar across the top is “sticky” now—it doesn’t scroll with the rest of the content.
I made sure that the stickiness only kicks in if the screen is both wide and tall enough to warrant it. Vertical media queries are your friend!
But it’s not enough to just put some position: fixed
CSS inside a media query. There are some knock-on effects that I needed to mitigate.
I use the space bar to paginate through long pages. It drives me nuts when sites with sticky headers don’t accommodate this. I made use of Tim Murtaugh’s sticky pagination fixer. It makes sure that page-jumping with the keyboard (using the space bar or page down) still works. I remember when I linked to this script two years ago, thinking “I bet this will come in handy one day.” Past me was right!
The other “gotcha!” with having a sticky header is making sure that in-page anchors still work. Nicolas Gallagher covers the options for this in a post called Jump links and viewport positioning. Here’s the CSS I ended up using:
:target:before {
content: '';
display: block;
height: 3em;
margin: -3em 0 0;
}
I also needed to check any of my existing JavaScript to see if I was using scrollTo
anywhere, and adjust the calculations to account for the newly-sticky header.
Anyway, just a few things to consider if you’re going to make a navigational element “sticky”:
min-height
in your media query,Three very easy to implement additions to scrollable areas of your web pages: tabindex="0"
, role="region"
, and an aria-label
attribute.
A nice self-contained script for animating items into view as the document scrolls.
I’d like be interested to hear what Graham thinks of this code—he’s my go-to person for smooth scroll-based animations.
(I’m very confused by the tagline for ScrollReveal—”Easy scroll animations for web and mobile browsers”—eh? Mobile browsers are web browsers …”web” is not a synonym for “desktop”.)
I think this might be the most tasteful, least intrusive use of scroll events to enhance a Snowfallesque story. It’s executed superbly.
You can read all about the code. Interestingly, it’s using canvas to render the maps even though the maps themselves are being stored as SVG.
(There’s a caveat saying: “This is a highly experimental project and it might not work in all browsers. Currently there is no IE support.” I don’t think that’s true: the story works just in IE …that browser just doesn’t get the mapping enhancements.)
Harry packs a lot of great tips and tricks into one short video about performance troubleshooting. It’s also a great lesson in unlocking some handy features in Chrome’s developer tools.
Great stuff!
A look at detecting, pinpointing, measuring, and fixing rendering performance issues.
This gets nothing but agreement from me:
For altering the default scroll speed I honestly couldn’t come up with a valid use-case.
My theory is that site owners are trying to apply app-like whizz-banginess to the act of just trying to read some damn text, and so they end up screwing with the one interaction still left to the reader—scrolling.
This is clever: a way to achieve parallax scrolling without JavaScript—much more performant.
Of course, you might want to ask yourself why you want a parallax effect in the first place.
If you insist on having a fixed header on your site, please, please, please add this script to your site. I often use the spacebar to page down so this would be a life-saver.
This observation by Josh seems obvious in hindsight (all the best insights do), but there’s a powerful idea there:
So here is the real difference: scrolling is a continuation; clicking is a decision. Scrolling is simply continuing to do what you’re currently doing, which is typically reading. Clicking, however, is asking the user to consider something new…is this new thing the same as what I’m already doing, or something new?
I like this CSS solution to sideways-scrolling tables for small viewports. It’s not going to be right for every situation but it’s a handy trick to keep up your sleeve.
A few weeks ago, when I changed how the front page of this site works, I wrote about “streams”, infinite scrolling, and the back button:
Anyway, you’ll notice that the new home page of adactio.com is still using pagination. That’s related to another issue and I suspect that this is the same reason that we haven’t seen search engines like Google introduce stream-like behaviour instead of pagination for search results: what happens when you’ve left a stream but you use the browser’s back button to return to it?
In all likelihood you won’t be returned to the same spot in the stream that were in before. Instead you’re more likely to be dumped back at the default list view (the first ten or twenty items).
That’s exactly what Kyle Kneath is trying to solve with this nifty experiment with infinite scroll and the HTML5 History API. I should investigate this further. Although, like I said in my post, I would probably replace automatic infinite scrolling with an explicit user-initiated action:
Interpreting one action by a user—scrolling down the screen—as implicit permission to carry out another action—load more items—is a dangerous assumption.
Kyle’s code is available from GitHub (of course). As written, it relies on some library support—like jQuery—but with a little bit of tweaking, I’m sure it could be rewritten to remove any dependencies (hint, hint, lazy web).