Pushing Pixels

Good morning and welcome, and thank you for choosing this room.

We will also be having AI in this room, so I need to start with a confession.

And that confession is that two weeks ago when I sat down to create this talk, it was really hard because at the same time I also discovered Midjourney.

And so for those of you that don't know, midjourney is a generative image AI that they have trained on millions and millions of images across the internet.

And you can put in a simple prompt and then it'll generate images.

Magical images.

And when I first sat down to create this talk, it's been a battle between me and the AI.

And you might be interested to know that the very first prompt that I came up with, that I put into this AI, was actually my master password that I used to unlock my entire digital life.

And at this point you're probably going, who is this for?

I should be in the other room.

I'm missing out.

This is crazy.

But I have a theory.

And so I am a believer that we're a long way away from the singularity, that we're a long way away from general AI.

So this is my little sniff test, that if I can put my master password into the AI, and it doesn't immediately turn around and hack my life, But it is not general AI.

I might be the fool.

You might find me in a meme in a couple of years going, Oh yeah, there was that guy who put his master password into the general AI.

And then it turned around and it drained his bank accounts.

And then it took his, full self driving car.

And actually drove off into the sunset with his Roomba.

That might be me.

So this is it.

This is what the AI gave me back when I put my master password in.

And I like to have a big long sentence to unlock my digital life, and it's an aspiration of like how I see myself.

And so this is it.

So I invite you this afternoon when you see me wandering around, give it a guess if you can see what my master password is.

And so as I looked at this, I thought, today I want to talk about what am I actually doing on that laptop.

What is that thing that's on screen in front of me?

And it's this thing we call a page.

And I wanted to really examine this idea of a page today and see if we can pull it apart and move ourselves along in terms of what the internet experience is.

Because I think the page has been a really useful metaphor when you think about the web first coming along 30 years ago.

We didn't know what this thing was.

We came up with this sort of metaphor of the page, of websites, surfing the internet.

Do you guys remember that one?

Is that what we're still doing?

Surfing?

But anyway, so we have these pages.

We also struggle to think about, interactions and what we do on these pages.

There's this thing where we talk about buttery smooth, I don't know, I don't know what that is.

So if I add buttery smooth to my page, it's is this the internet?

It's am I doing this right?

So anyway, my, my proposition today, my hypothesis is that this thinking in pages has been quite monolithic, and it it creates a, it's quite a structured way of thinking about our web experiences that locks us down in quite a static way.

What I want to do is bring in the space apes, I want to bust apart those monoliths, I've been having nightmares about that guy top I don't know what that is, but it's something, and I want to, burn these pages.

How are we going to approach this?

My background is in design.

I trained as a designer and then I moved into code, spent 30 years on the internet.

The thing that's always struck me is that it's about user experience.

And when you're thinking about user experience and what's on this page, not all pixels have the same value.

And for me, that's a really important starting point in terms of breaking apart this experience.

And what do I mean by, not all pixels have the same value?

If we look at a simple marketing site here for, mountain bikes, how might we break this apart?

This will be familiar in terms of how you might structure the elements on a page, how you might divide up your divs, or when you're designing things, if you're thinking about components, how do I break things down?

And we might have a structure like this.

And that is really the theme of today, is that it's all about islands.

So I'm going to be talking about island architecture, I'm going to be talking about, these islands of content and how we might design them and approach our design systems, how we might then build those functional islands, and then we'll wrap up with actually looking at how we measure individual islands of content in our web experiences and put those together.

Designing an island.

So as I said, I'm an old guy like John, been doing it for 30 years, and I too am going to reminisce and pontificate about some of the trends that I've seen over those 30 years.

And this has been a really big one.

When we first started, there was no such thing between front end and back end, it was just the same person doing it all.

And then we've seen this move into what are effectively silos of specialization and expertise between front end, back end, ops, all these different things.

And something that has happened as we've moved into these silos, and I saw this in particular when I worked as a creative director in an agency, is that it really hampered the user experience.

When the marketing team went away and decided in isolation, this is our vision for the page, and then moved that to, our design team, and that design team created a full blown Photoshop mock up of what the final rendered experience should look like, and then threw that over the wall to the dev team, and just hoped that it was going to be fast, that, having this very kind of linear model just didn't work in terms of creating really delightful user experiences and especially performant user experiences.

So taking the island kind of idea here and talking about silos.

Something that has worked incredibly effectively in my career is to actually create small interdisciplinary teams.

And I know this is not a new idea, but it's amazing how effective this can be.

And here when I say prototype early, like really early.

So this is an example of a major new site in New Zealand that we redeveloped.

And this is literally the product owner, a developer, a designer.

They're in the room from day one and they're doing weekly iterations.

And most importantly, the actual canvas, the expression of what they're working on, is actually in the browser.

So it's not static in Photoshop.

Everyone's working in the final medium.

And at the end of each of that week, we had a UX researcher as well that was taking whatever we had come up with in the preceding two or three days and put it in front of actual users and got, real feedback and fed that into the next week.

So to develop this website, we actually spent, six or seven weeks just doing these really tight iterations with this really core interdisciplinary team working with actual content that was streaming in every day over news feeds.

And it really transformed the way that we actually approached the design process and it was fundamental in actually leading to a good result.

And so our islands need to be different.

Rather than these silos of specialization, we need a little island in the middle with castaways from each of those silos.

We need that UX researcher, we need a designer, we need a developer, collaborating really tightly, in small teams.

And that is the way that you create really good, experiences.

The other issue I have with the page is that it's, very static.

It links to this idea of I've published something, it's in a book, it's just sitting there, it's not time based.

Whereas I truly believe that the internet, our web experiences that we're creating are actually time based experiences, and the more we approach it as something that evolves and streams into our browser over time, the more effectively we can design for that medium.

And yes, I'm an old school Flash guy as well.

I actually miss Flash.

I really do.

It had some great kind of moments.

But anyway, so what I mean by time based, so here's an example of a film strip where across the top, every hundredth of a second we've got a frame coming in.

Here are some key events, there's a waterfall behind there, some CPU activity.

But the main thing I wanted to focus on here is, look at what's happening at the user experience at the top here.

Like this mountain bike that I would say is the, the main bit of content, the hero content.

It's actually not starting till, nine seconds into this experience.

And why is that?

If we jump into the waterfall and look at all the resources that are being loaded here, it's actually not till kind of seven or eight seconds in into this experience that we're actually loading the very first, that hero image, and that is just unbelievable.

And so this is a terrible performant experience, and it's because they've picked the wrong technology for what this page or this experience actually needs to be.

And we'll dig into those choices a little bit later on, but it's a really classic problem of not choosing the right tool for the right job.

And this is something that we've seen a lot in the industry recently over the last 10 years with this massive shift from server side into client side JavaScript, and primarily for developer convenience, which I love, but we've done that at the sacrifice of user experience, and we've actually lost sight of what our users are actually interacting with.

And so SPAs are great.

I love a good single page application, but to me, the hint is actually in the name, application.

Are you actually building an application?

Are you building Gmail?

Are you building something that complex?

If you're not, it probably shouldn't be a SPA.

So React and those tools are not always the right tool for the job.

And thinking back on our design process, this is one way of looking at those islands.

We can think about what type of content they are.

We can also think functionally about our different islands and where those islands might be coming from and their characteristics.

So are they, static, do, how often do they change?

Which parts are app, like we've got the little cart over the side.

And also, who's in control of them.

Are we, are they, is it first party content or is it third party content that is just, coming into my experience and how I manage that.

And we can also use this as a bit of a model for, who's responsible in an organization as well.

Where is this content coming from?

If I have issues with my third party ad that's being delivered in the corner there, who do I talk to about improving that part of an experience?

So it's acknowledging that, these things that we are building these days they are multi faceted and there's a whole lot of different islands that come from different parts of the organization.

And we can use that to our advantage rather than just pretending it's this monolith.

So we've designed an island, how do we now go and build it?

So you'll be familiar with these sorts of techniques.

So this is the client side hell that we find ourselves in now, where for the last ten years we thought it was a really great idea to push everything into the client.

I think we've forgotten really simple things, like the next billion people coming onto the internet are not in the first world, they're not on fiber optic connections, they're more like people in Australia, they have pretty shitty connections.

They're in the developing world, they're on mobile, and we really need to care about how much we ship to their device.

Because we can heat up their CPUs, we can drain their battery, and we can give them some terrible experiences.

And so in the last couple of years, we've seen frameworks start to acknowledge this problem and go, okay, actually, we need to now render things back on the server side as much as we can, using server side rendering.

And then we're hydrating it.

That leads to problems where it looks like it's ready but I can't actually interact with it because it's still downloading a shit ton of JavaScript in the background.

You have hydration issues.

Then we have partial hydration where we're trying to prioritize how we, bring those components in, and that's great.

And then we've got the new kid on the block, the new kind of hype train, islands architecture, which, to me, sounds pretty much like what we used to do 15, 20 years ago.

And I really like this, because it brings back a really nice mixture.

And so when we look at our islands, we're basically deciding: what's static content?

What can be rendered on a CDN, in the cloud, really close to my customers?

How can I leverage all the amazing stuff that's in the browser?

The browser does so much for us.

And when we move into a SPA we end up recreating a lot of functionality that already exists natively in the browser.

And so this gives us the best of both worlds, where we can still use SPA like functionality, but we put it in an island, and we have control over that island and how it loads.

So it's quite a simple approach.

The framework that's really championing this at the moment is Astro.

I know Dave yesterday really encouraged us not to get into the hype train, onto the latest thing, but after a few beers last night, he did confess that actually this is the thing that he's on now.

And this is the thing that he's really into, so it gets the Dave seal of approval, you can get on this hype train, it's okay.

And it's interesting, so it's a multi page app, as I said, so all the routing is now happening back on the server.

It is more content focused, so as I said, if you're building Gmail, great, build it in a SPA, use React, use Svelte, use all that great stuff.

But if you're finding your problem is actually content, if it's, marketing, if it's blog, if it's, primarily static, then the server is a great place to create that content and deliver it.

So this is more of a content focused framework.

And one thing I also really like about it is that you're bringing your own componentry.

I almost think of it more as a build process than another framework, because you're bringing your React components, you're bringing Svelte, you're bringing whatever it is that you already, code in, and then this is just giving you a way to manage how those components are rendered, either into static HTML or rendered into interactive islands and our Web experience.

And as you can see, there's some great stats, that's just, don't use a SPA and it's going to be faster, like it's obvious.

And so what does this look like?

I'm using React.

I get to use all the same developer convenience, my same design systems, I can do everything like I do now, but then my final output is 100 percent static HTML, and so this really is the best of both worlds, and it's magic.

And then when I do need a bit of interactivity, in one of my islands, it's as simple as adding this client load attribute to my component, and now Astro will deliver everything statically.

And then it'll load in just that one island of functionality, and it'll just bring that in, and it'll load it when needed.

And there's some really nice different attributes here, so you can decide, that island, should it load straight away, or should it load lazily.

So if I'm scrolling down the page, and I've got a whole lot of awesome functionality down the bottom, that's out of the viewport, it won't actually load any of that componentry in JavaScript until that island comes into the viewport.

So really what Astro is doing is it's giving me a whole lot of management around my components and how those are delivered onto the page.

And I can choose, should it be static?

Should it be dynamic?

And how should that load, which is awesome.

And it also reminds me of techniques that we've talked a lot about in the world of web performance, so Critical Rendering Path is one of those, where it's really just, again, think with your time based medium hat on.

When you just try and race and load everything all at once, you get these horrible experiences where users are just staring at a blank browser for sometimes tens of seconds or one of those kind of loaders, and then bang, it's all there.

Whereas if you manage over time how you stream into the browser, you can do things like, have a logo, have the right color, have a bit of a skeleton, like you can give a lot of clues to a user that they're in the right place early on, and then fill that content in over the time.

And we saw Mike give us some great techniques around progressive, sorry, perceived performance yesterday.

And this is really about that critical rendering path.

And coming back to this example, like, why was it so bad?

And, I don't really blame the developers.

I can see how they got there.

On the right hand side, there's this little widget which tells you whether this bike is in stock, and like, where your local dealer is, and, I don't know for sure, but I can project that the development team probably sat down and went, Ooh, cool, we're going to have this great functionality, we should probably build that, in React, or like a SPA, or something like that, and then they went, Okay, if we're building that in React, we might as well build the whole page in React.

And then suddenly, all this static content, that never changes, has all been sucked into this app.

And then they went, since we're already building a SPA and we've got this one bike model in there, let's put all our other models into the same app space so that we can manage it using our great development tools.

But what that ends up doing is delivering this horrible experience where, and this is just a, this is about a 5 megabit kind of desktop connection, so not even mobile.

And so this bar down the bottom here, you can see how terribly this loads.

There's all sorts of jank where the footer's coming into the page first, we've got spinners, and then finally we get our hero content of our bike.

And so all I did here was reconstruct the page in a very simple fashion, and I put the same image in, and I just delivered it on a, crappy kind of instance somewhere, not even optimized on the cloud, and you can see how dramatically different that experience is.

And the reason I did that is that this should give us a bit of a simple baseline as to if it was just static HTML, how much faster would that be?

Yeah.

So just again, right tool for the problem that you've actually got.

It's that simple.

Okay, how do we measure these islands?

So I'm really lucky.

I get to spend a lot of time on islands.

I live on an island, I've been really lucky for the last 10 years to run SpeedCurve, which is a great little performance monitoring tool.

We're small, we're just a team of 7, and we're spread all around the world.

And Hawaii happens to be in the middle, which is great.

So we get to spend a lot of time in Hawaii, and we do this, we sit around, we drink Mai Tais, and we talk about the internet.

And the reason I bring this up is that I wanted to share a bit of a journey that we've had with some of our metrics, and just how small our communities can be, and so something that I've always felt coming from New Zealand is, woe is me, I'm on the edge of the culture, I'm on the edge of the planet, like, how, can I interact with the, centre, with Silicon Valley, like, how can we influence, the world around us?

And I think too often, here in the Antipodes, we go, oh, there's no way we can influence.

And so when I first came into the world of web performance about 10 years ago, it shocked me that a lot of the tooling and tool sets, were all very engineering focused.

And again, they were very page focused.

It was all about when does the page finally finish rendering.

And coming from a user experience perspective, I was just like, actually, I care more about the content.

I care about those pixels.

When do those end up on screen?

And so we came up with a very simple technique, which was just let's look at the largest element on the page.

We know what the bounding box of that element is.

Let's just look at one of those film strips and figure out when all those pixels stop moving.

And we call that hero times.

And then Paul Irish, who's a developer advocate at Google, picked up on that.

He called it, Last Painted Hero.

And then that became Largest Contentful Paint.

I'm quite proud of the fact that our little team, sitting on an island in Hawaii drinking Mai Tais, came up with Largest Contentful Paint, which I assume most of you here in the room now use because it's one of the key Core Web Vitals, and it was just a good simple idea.

And so I really encourage you to interact with the communities around you through things like these conferences because a good simple idea can travel.

And if you get it out there and you talk to people, you can actually have considerable influence.

The world's actually a lot smaller than you think.

And LCP is great.

It's probably the most important Core Web Vital when it comes to user experience.

That most important content on the page.

Like, when does that get rendered?

But, it has some challenges.

And this is a good example of where Largest Contentful Paint goes wrong.

Because we're letting the browser Choose what it thinks is the most important content, and it's just looking for the largest element.

And so here is an example on the What Hi Fi website, where when the cookie consent banner pops up on this side, actually the largest contentful paint is this paragraph of text, whereas I don't really care about that, like I wouldn't think that is my most important content on the page.

Over here, it's this kind of H1 kind of list, and so there are lots of problems like this with, Largest Contentful Paint.

We're finding when we look in the wild viewport changes, all sorts of things can lead to a real variety of large contentful paint elements.

And so it's not always the element that you think it is.

And what can we do about that?

And there is a technique, unfortunately no one really knows about it, which, I'd like to try and change today.

And, it comes from this sort of thinking, which is actually the most important metric that you should be measuring is the one that you decide yourself.

And Twitter came up with this one quite a while ago, which is Time to First Tweet.

And it's obvious, right?

They care about when does that first tweet appear for users.

And we're going to put a metric around that, and then we don't even have to explain it to anyone in the organization.

I don't know about you, but trying to explain Cumulative Layout Shift and Largest Contentful Paint and First Input Delay, and now Next Paint, Next Interaction Paint, INP, it's those are challenging concepts to try and get an organization to care about.

Whereas if you had a metric like Time to First Tweet, bang.

The whole organization knows what, who that is, whether it's the development team, marketing, CEOs, everybody's going to understand it.

How do we do that?

There is this awesome spec called element timing, and all you do is you add this attribute to either an image or a text node on your page, and then Chrome will report in the performance observer When that got painted to screen.

And by taking, either your tweet, TimeToFirstTweet, I wonder if they still use that metric?

Maybe it's more TimeToFirstElon these days.

Something dodgy like that.

But anyway, so you can take this attribute.

It's available in RUM and Synthetic, and then what that does is it gives you control over exactly which elements you want to track, and then you can share this across your organization, and it relates back to these island ideas.

So if there's one technique you take away today, 100 percent I would put that attribute on a few of your important, content moments and islands, start up a free SpeedCurve trial.

Give it a go.

Those are our islands.

And so to quickly summarize, this is the, these are takeaways.

Think in those smaller chunks of content.

Think about how you stream them into the browser.

Have an explore of islands architecture.

See if that works for you as a different methodology.

When we're thinking about how we build something, don't prioritise the developer experience over user experience, really think through is this the right tool for the problem that I actually have in front of me.

Everything has a cost, especially those SPAs.

And then when it comes to measurement, keep it really simple, keep it easy for people to understand.

That'll help you build a performance culture across your organisation where everyone wants to improve the user experience.

And so really what I want you to do is I want you to shift your mentality away from, I'm pushing code out there into the world, to actually, I'm pushing pixels, I'm pushing these user experiences, how are my pixels being pushed out there?

And it shifts your thinking away from the toolset into the user experience, which ultimately we're all here in aid of, right?

We want our users to be happy, we want them to have really joyful user experiences.

And, maybe we're pushing islands.

So yeah, if you want to learn more about this stuff, we've been blogging about web performance and things like that on our website for the last 10 years.

There's a whole lot of great stuff in there about performance budgets and the latest metrics, are they good or not, we do a lot of research before we deploy things, so give those things a go.

And then finally, I just, when I was listening to John yesterday and he was talking about old school hip hop, I was like, I don't know, is John more like 90s kind of hip hop blinged up artist, or is he more Jobs like?

I don't know, I wasn't really sure.

And then I thought, oh, maybe it's just the blend of those two personas.

And he looks a bit young here.

Maybe that was John back in the 90s.

Thanks.