{"id":363564,"date":"2022-02-21T08:19:44","date_gmt":"2022-02-21T16:19:44","guid":{"rendered":"https:\/\/css-tricks.com\/?post_type=newsletters&p=363564"},"modified":"2022-02-21T10:28:25","modified_gmt":"2022-02-21T18:28:25","slug":"291-the-ghostly-tale-of-the-phantom-bounces","status":"publish","type":"newsletters","link":"https:\/\/css-tricks.com\/newsletter\/291-the-ghostly-tale-of-the-phantom-bounces\/","title":{"rendered":"291: The Ghostly Tale of the Phantom Bounces"},"content":{"rendered":"\n

👻 👻 👻<\/p>\n\n\n\n

[Robin]:<\/strong> This week Simon Hearne wrote this mighty fine piece about web performance and survivorship bias<\/a>. His argument is this: we have a bunch of data about how our website is doing (and how poor the user experience is when it comes to performance) but often the data that\u2019s missing is the data we need the most. For example:<\/p>\n\n\n\n

The users who have the worst experiences are likely to be phantom bounces<\/a>: they don\u2019t appear in your analytics or intelligence tools because they don\u2019t hang around long enough for the app to load and analytics to fire.<\/p><\/blockquote>\n\n\n\n

I must\u2019ve been a phantom bouncer at least a dozen times myself just this week alone; tried to load a website, it was blank for too long, so I just quit my browser and went back to doing something else.<\/p>\n\n\n\n

The problem here is that dev teams will often look at these stats and say, \u201cAh, we don\u2019t need to worry about performance on platform X because we don\u2019t get much traffic there,\u201d without them realizing that they might not be seeing all the data clearly (phantom bounces). But also, the traffic problems could be caused<\/em> by those performance problems. Simon writes:<\/p>\n\n\n\n

It is clear that poor performance will impact your traffic numbers, and means that thousands of potential visitors are leaving your site without a trace. It is also clear that mobile visitors are less tolerant of slow sites.<\/p><\/blockquote>\n\n\n\n

Scary! But reading this makes me want to be ruthless<\/em> when it comes to performance. No fonts! No colors! No text! I\u2019m kidding here of course but this is an extremely good reminder that web performance is not a feature you can tack-on<\/a>.<\/p>\n\n\n\n

Ya know what this reminds me of though? Responsive design! Back in the day (and dear lord still too often today) I hear folks say stuff like, \u201cAh, we don\u2019t get much mobile traffic so we shouldn\u2019t make our big web app responsive.\u201d This is the same kind of logic with the same flaw in its thinking. We don\u2019t have much mobile traffic because<\/em> our website isn\u2019t responsive.<\/p>\n\n\n\n

\n\n\n\n

📈 📈 📈<\/p>\n\n\n\n

The Netlify Graph<\/a> was announced earlier this week and it looks extremely exciting. I need to set aside some time to play around with it but here\u2019s a quick video<\/a> that explains it all:<\/p>\n\n\n\n

After adding APIs, you can use the new Graph Explorer to build queries and generate serverless function code. As you iterate, you can seamlessly sync changes to your local repository, where you can test them in the local Netlify environment before deploying.<\/p><\/blockquote>\n\n\n\n

So: take an API, select the bits of code that you want, throw that into a serverless function, and then test locally on your website? That sounds neat as heck! I don\u2019t want to have to trawl through a bunch of docs when I\u2019m playing with an API \u2014 I sort of want to learn by doing. And this looks like that.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

On this note, I saw that Raymond Camden also used the Netlify Graph<\/a> to hit the Spotify API and return the latest tracks he\u2019s played. He seems pretty dang impressed:<\/p>\n\n\n\n

It’s all kinda\u2026 magical honestly. As I said, I definitely hit a few rough spots and I’d probably wait before using this in production for a “real” site, but even right now it’s pretty freaking cool.<\/p><\/blockquote>\n\n\n\n

All of this reminds me of Chris\u2019s talk back at Jamstack Conf in 2018 where he talked about how powerful front-end developers are becoming<\/a> because this Netlify Graph stuff seems like it opens up a ton of extra<\/em> super powers like that in the near future.<\/p>\n\n\n\n

\n\n\n\n

🔗 🔗 🔗<\/p>\n\n\n\n

Harshil Patel wrote this swell post about hover effects on hyperlinks<\/a>:<\/p>\n\n\n\n

Creating CSS link hover effects can add a bit of flair to an otherwise bland webpage. If you\u2019ve ever found yourself stumped trying to make a slick hover effect, then I have six CSS effects for you to take and use for your next project.<\/p><\/blockquote>\n\n\n\n

Lots of neat stuff in here, but perhaps my favorite is the rainbow underline effect Harshil shows that uses a linear-gradient and a tiny transition to push a blue underline away and replace it with a bright and vibrant one. But this reminds me that not so long ago, Geoff Graham wrote about how to replicate Adam Argyle\u2019s punk rock CSS hover effect<\/a> where the background of a link looks like an annotation:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Also, sidenote: do you know why hyperlinks were blue<\/a>? Elise Blanchard wrote a great piece about them a while back:<\/p>\n\n\n\n

As a user experience designer who has created websites since 2001, I\u2019ve always made my links blue. I have advocated for the specific shade of blue, and for the consistent application of blue, yes, but I\u2019ve never stopped and wondered, why are links blue? It was just a fact of life. Grass is green and hyperlinks are blue. Culturally, we associate links with the color blue so much that in 2016, when Google changed its links to black, it created quite a disruption<\/a>.<\/p><\/blockquote>\n\n\n\n

\n\n\n\n

🔻 🔻 🔻<\/p>\n\n\n\n

Mike Skowronek upset me this week when he tweeted this<\/a>:<\/p>\n\n\n\n

In @ChromeDevTools holding SHIFT while moving mouse over resources in network panel shows you which asset caused to load another asset.<\/p><\/blockquote>\n\n\n\n

What! That\u2019s so neat. You can directly see when one resource is the child of another like this:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

That will most certainly come in handy at one point or another.<\/p>\n\n\n\n

\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n

Sponsor<\/p>\n\n\n

Astra DB<\/a><\/h2>\n\n\n

Do more with Astra DB<\/a>, the only DBaaS that helps developers build Apache Cassandra™ apps faster.<\/p>\n\n\n\n

\n
Get Started<\/a><\/div>\n<\/div>\n\n\n\n
\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n

Sponsor<\/p>\n\n\n

WordPress.com Has a New Home on YouTube<\/a><\/h2>\n\n\n

The WordPress.com team set up<\/a> a brand spankin\u2019 new YouTube channel<\/a> full of fresh videos that walk you through everything you could ever want to know about using WordPress, including how the new Site Editor works, how to set up a homepage, and much more.<\/p>\n\n\n\n

Anyone running a WordPress site, self-hosted or not, will benefit from these step-by-step tutorials.<\/p>\n\n\n\n

\n
Subscribe on YouTube<\/a><\/div>\n<\/div>\n\n\n\n
\n\n\n\n

[Chris]<\/strong>: Have y’all seen :focus-visible<\/code><\/a> in CSS? Pawel Grzybek just blogged The difference between CSS focus and :focus-visible<\/code> pseudo-class<\/a>. I’ll try to summarize in one sentence:<\/p>\n\n\n\n

The :focus-visible<\/code> pseudo selector in CSS only applies when an interactive element becomes in focus via keyboard navigation, while the :focus<\/code> pseudo selector applies when an interactive element becomes in focus for any reason.<\/strong><\/p>\n\n\n\n

What’s the point? Mostly one thing: :focus<\/code> styles are super very important for people navigating with a keyboard and probably should have pretty big bold styles. But if you’re navigating with a mouse, those big bold styles can be visually annoying, because you’ll see them whenever you click onto any interactive element. Because of that visual annoyance, it’s driven people to have minimal focus styles that may not be enough for keyboard navigators, or worse, none at all. <\/p>\n\n\n\n

It’s actually a bit more complicated than keyboard-or-not. The Chromium blog gets into<\/a> the heuristics for how it’s all determined. <\/p>\n\n\n\n

If you were sure that 100% of the users of your website are using a browser the supports :focus-visible<\/code>, or were polyfilling it<\/a>, I could see being tempted to only<\/em> use it for focus styles. That way you don’t have to worry about styles being applied from clicks but key the nice keyboard focus styles. I dunno though, I think that might be swinging the pendulum too far back the other way. It’s probably more likely we start using The :focus-visible<\/code> Trick<\/a> where we have an opportunity for different styles either way. <\/p>\n\n\n\n

\/* Focusing the button with a keyboard will show a dashed black line. *\/\nbutton:focus-visible {\n  outline: 4px dashed black;\n}\n  \n\/* Focusing the button with a mouse, touch, or stylus will show a subtle drop shadow. *\/\nbutton:focus:not(:focus-visible) {\n  outline: none;\n  box-shadow: 1px 1px 5px rgba(1, 1, 0, .7);\n}<\/code><\/pre>\n\n\n\n
Why is this all being talked about recently again? Because a new Safari Technology Preview version was released<\/a> with support for it, bringing support across all The Big Three. Who did that work? Igalia<\/a> did. They had this grand idea called Open Prioritization<\/a> to see if web developers themselves could fund particular things to make browsers better. The winner<\/a> of that was :focus-visible<\/code> in WebKit\/Safari. Then they did exactly what they said they were going to do and did the work. <\/p>\n\n\n\n
Yet, it caused 🔥 controversy 🔥, mostly in the form of: “The richest company in the world needs to do crowdfunding to implement standardized web features?!”<\/strong><\/em> Which, like all the hottest controversy, has a certain understandability to it. It’s easy to fantasize about the web getting better because Apple taking, I dunno, a few billion and slapping it into making WebKit\/Safari the most rootin’ tootin’ browser around (and conversely, opening up iOS to browser engine competition). <\/p>\n\n\n\n
The thing is, Apple doesn’t “own” WebKit, as it’s an open-source project. Apple can’t control who contributes to that, nor do they want to. You can criticize them for being slow on feature support, but you can’t blame them for what outside contributors do. Eric Meyer does a good job at pouring water on all that fire<\/a>. <\/p>\n\n\n\n
Nobody at Apple asked the crowd to fund anything. Nobody at Apple asked Igalia to crowdfund anything. They didn\u2019t even ask Igalia to implement :focus-visible<\/code>, and then Igalia decided to crowdfund the work. In fact, all of those assumptions get things almost exactly backwards\u202f\u2014\u2009which is understandable! It\u2019s what we expect from our experience of how the web has developed since at least the late 1990s<\/p><\/blockquote>\n\n\n\n
Anyway, it’s nice to see the web improving. Should be a banner year for CSS. And Safari is really accelerating in support for all sorts of things. Looks like it’s a first mover on the inert<\/code> attributes, which will be amazing<\/a>. <\/p>\n","protected":false},"excerpt":{"rendered":"
👻 👻 👻 [Robin]: This week Simon Hearne wrote this mighty fine piece about web performance and survivorship bias. His […]<\/p>\n","protected":false},"template":"","acf":[],"share_on_mastodon":{"url":"","error":""},"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/newsletters\/363564"}],"collection":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/newsletters"}],"about":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/types\/newsletters"}],"version-history":[{"count":6,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/newsletters\/363564\/revisions"}],"predecessor-version":[{"id":364102,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/newsletters\/363564\/revisions\/364102"}],"wp:attachment":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/media?parent=363564"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}