I made an offhand remark at the Clearleft Christmas party and Trys ran with it…
This is the transcript of a brilliant presentation by Scott—read the whole thing! It starts with a much-needed history lesson that gets to where we are now with the dismal state of performance on the web, and then gives a whole truckload of handy tips and tricks for improving performance when it comes to styles, scripts, images, fonts, and just about everything on the front end.
Testing on a <$100 Android device on a 3G network should be an integral part of testing your website. Not everyone is on a brand-new device or upgrades often, especially with the price point of a high-end phones these days.
When we design and build our websites with the outliers in mind, whether it’s for performance or even user experience, we build an experience that can be easy for all to access and use — and that’s what the web is about, access and information for all.
That unusual behaviour I wrote about with the Web Share API in Safari on iOS is now officially a bug—thanks, Tess!
PWAs just work better than your typical mobile site. Period.
But bear in mind:
Maybe simply because the “A” in PWA stands for “app,” too much discussion around PWAs focuses on comparing and contrasting to native mobile applications. We believe this comparison (and the accompanying discussion) is misguided.
I don’t know about “perfect” but this pretty much matches how I go about implementing responsive navigation (but only if there are too many links to show—visible navigation is almost always preferable).
When your only tool seems like a smartphone, everything looks like an app.
Amber writes on Ev’s blog about products that deliberately choose to be dependent on smartphone connectivity:
We read service outage stories like these seemingly every week, and have become numb to the fundamental reality: The idea of placing the safety of yourself, your child, or another loved one in the hands of an app dependent on a server you cannot touch, control, or know the status of, is utterly unacceptable.
An interesting proposal to allow websites to detect certain SMS messages. The UX implications are fascinating.
Making the case for moving your navigation to the bottom of the screen on mobile:
Phones are getting bigger, and some parts of the screen are easier to interact with than others. Having the hamburger menu at the top provides too big of an interaction cost, and we have a large number of amazing mobile app designs that utilize the bottom part of the screen. Maybe it’s time for the web design world to start using these ideas on websites as well?
The ellipsis is the new hamburger.
It’s disappointing that Apple, supposedly a leader in interface design, has resorted to such uninspiring, and I’ll dare say, lazy design in its icons. I don’t claim to be a usability expert, but it seems to me that icons should represent a clear intention, followed by a consistent action.
The test results are in:
During our testing “Install App” banners were the direct and sole cause of several abandonments of some of the world’s largest e-commerce websites.
Read on for details…
Time to Interactive (TTI) is the most impactful metric to your performance score.
Therefore, to receive a high PageSpeed score, you will need a speedy TTI measurement.
At a high level, there are two significant factors that hugely influence TTI:
53% of mobile visits leave a page that takes longer than 3 seconds to load. That means that a large number of visitors probably abandoned these sites because they were staring at a blank screen for 3 seconds, said “fuck it,” and left approximately half way before the page showed up. The fact that the next page interaction would have been quicker—assuming all the JS files even downloaded correctly in the first attempt—doesn’t amount to much if they didn’t stick around for the first page to load. What was gained by putting the business logic in the front end in this scenario?
This article conflates progressive web apps with having an app shell architecture. That’s a real shame.
Damn, that’s a fine opening! And the rest of this post by Alex is pretty darn great too. He’s absolutely right in calling out the fetishisation of developer experience at the expense of user needs:
The swap is executed by implying that by making things better for developers, users will eventually benefit equivalently. The unstated agreement is that developers share all of the same goals with the same intensity as end users and even managers. This is not true.
I have a feeling that this will be a very bitter pill for many developers to swallow:
If one views the web as a way to address a fixed market of existing, wealthy web users, then it’s reasonable to bias towards richness and lower production costs. If, on the other hand, our primary challenge is in growing the web along with the growth of computing overall, the ability to reasonably access content bumps up in priority. If you believe the web’s future to be at risk due to the unusability of most web experiences for most users, then discussion of developer comfort that isn’t tied to demonstrable gains for marginalized users is at best misguided.
Oh,captain, my captain!
Tools that cost the poorest users to pay wealthy developers are bunk.
Testing time with Tim.
Long story short, the NOSCRIPT intervention looks like a really great feature for users. More often than not it provides significant reduction in data usage, not to mention the reduction in CPU time—no small thing for the many, many people running affordable, low-powered devices.
Power to the people!
Google hijacking and hosting your AMP pages (in order to pre-render them) is pretty terrible for user experience and security:
I’m trying to establish my company as a legitimate business that can be trusted by a stranger to build software for them. Having google.com reeks of a phishing scam or fly by night operation that couldn’t afford their own domain.
From Frederik Pohl’s 1966 novel:
The remote-access computer transponder called the “joymaker” is your most valuable single possession in your new life. If you can imagine a combination of telephone, credit card, alarm clock, pocket bar, reference library, and full-time secretary, you will have sketched some of the functions provided by your joymaker.
Essentially, it is a transponder connecting you with the central computing facilities of the city in which you reside on a shared-time, self-programming basis.
I love having discussions like this!