Introduction: Exploring Web Experiences Beyond Pages

Mark Zeman begins his talk by expressing his fascination with AI and its implications for digital security. He introduces the main theme of his presentation: examining the concept of a 'page' in web experiences and exploring how we can evolve beyond this traditional idea.

Rethinking the Web Page Concept

Zeman discusses the limitations of the 'page' metaphor in web design, arguing that it restricts our thinking and creativity in designing web experiences. He proposes moving towards a more dynamic and fluid approach.

User Experience and Design Focus

Highlighting his background in design and code, Zeman emphasizes the importance of user experience in web design, and the idea that not all pixels have the same value in a design.

Island Architecture in Web Design

He introduces the concept of 'island architecture' for web design, discussing how to approach design systems, build functional islands of content, and measure their effectiveness.

Breaking Silos: Interdisciplinary Team Collaboration

Zeman talks about breaking down silos between disciplines by forming small, interdisciplinary teams for more effective design and development processes.

Time-Based Approach to Web Experiences

He advocates for a time-based approach to designing web experiences, arguing that the internet is a dynamic, evolving medium that should reflect temporal changes and user interactions over time.

Functional Characteristics of Web Content Islands

Zeman discusses the functional aspects of content islands in web design, considering their static or dynamic nature and who controls them, whether first or third party.

Client-Side Challenges and Server-Side Rendering

He addresses the challenges of client-side rendering, advocating for server-side rendering where possible to optimize performance and user experience.

Exploring Islands Architecture with Astro

Zeman discusses the islands architecture using the Astro framework, explaining how it balances static and dynamic content for optimal performance.

Using React in Islands Architecture

He explains how React can be used in an islands architecture to create static HTML outputs, enhancing web performance.

Performance Measurement in Islands Architecture

Zeman discusses performance measurement in islands architecture, emphasizing the need for simple, easy-to-understand metrics that reflect user experience.

Key Takeaways: Content-Focused Approach and Performance

He summarizes his talk by encouraging a shift in mentality from code-focused to content-focused web design, prioritizing user experience and efficient performance measurement.

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?


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?


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.


AI generated image of a smiling yellow 3D cartoon figure waving


The image depicts a stylized, animated scene of an individual sitting at a simple desk and chair setup, working on a laptop on a beach. This person is facing the sea, with their back toward the viewer. The setting is at sunset or sunrise with the sun low on the horizon, casting an orange glow over the sky and reflecting on the water's surface. The sea is rendered in hues of blue and turquoise, and there are rocks jutting out of it. Waves are seen crashing onto the shore. The beach is lined with a steep cliff on one side, covered in greenery, suggesting a remote and tranquil work environment. The overall feel of the image is serene and picturesque, suggesting a remote work scenario in a beautiful, natural setting.


An imaginative scene depicting an explosion of books and pages flying out from a brick building into a snowy environment, creating a chaotic yet artistic representation of scattered literature.

"buttery smooth"

The image shows an open book with slices of bread on its pages. Liquid cheese is being poured over the bread slices, creating a visual metaphor for the text "buttery smooth" indicating something very smooth and appealing, akin to melted cheese or butter spread on toast.

Thinking in “pages” has fostered a monolithic approach to the web experience

Let's bust up those monoliths

The image depicts an intense battle scene with giant apes involved in a struggle against a backdrop of massive structures being destroyed. The structures appear to be monoliths breaking apart among explosions and falling debris.

Not every pixel has the same value

The image features a colorful array of 3D cubes resembling pixels floating against a backdrop that resembles a starry night sky. The cubes vary in color and seem to be suspended in space, some closer to the viewer and others further away.
The image shows a webpage from a website specializing in bikes
The image displays a simplified layout of a webpage or a mockup for a website design. It has six labelled sections including 'Nav' for the navigation bar, 'Hero' for the large banner area, 'Content' for the main content section, 'Cart' for the shopping cart section and 'Ad' for an advertisement placeholder.
Aerial view of two lush, green tropical islands surrounded by vibrant turquoise waters. The islands are densely forested, with a small visible building on one. White sand beaches and coral reefs are noticeable around the perimeter of the islands where the color of the water changes from deep blue to light turquoise due to the changing depth.

Design an island

The image shows a digitally created tropical island with lush greenery, palm trees, and several small huts spread across it. Azure blue water surrounds the island which has white sandy beaches and rocky outcrops. A few boats are visible near the shore, suggesting the island is inhabited or visited by people.

Don't throw pages over the wall from design to development

A person is seen reaching upwards, as if trying to catch or interact with numerous books and pages flying chaotically in the air around them. The background features a brick wall.

Collaborate and prototype early in small interdisciplinary teams

here's a description of the visual elements in the image for alt text purposes:
The image shows a group of people in an office environment evidently collaborating. In the forefront, there's a person standing in profile looking at a large monitor, which displays some kind of user interface design. Another person is standing with arms crossed, watching, and others are sitting at desks with computers, likely contributing to the collaborative effort.

Approach the UX as time based

Screencast of performance waterfall chart, which is a visualization of the different phases of a web page load. Key milestones in the page load process are annotated with their timings, such as "First Contentful Paint", "DOM Content Loaded", and "Fully Loaded". The chart is presented as a horizontal timeline with color-coded bars representing
Repeat of the slide depicting a basic layout structure of a webpage template.
A similar diagram but the parts are differently labelled. The largest area is labeled "Static" and takes up most of the left-hand side. In the upper-right corner, there is a smaller rectangle labeled "App". Just below it is another rectangle of the same width, labeled "Third Party". Additionally, both the top and bottom borders of the largest area also have the label "Static".

Build an island

A conceptual image of an imaginary island with cliffside structures and greenery atop an elevated rock formation in the sea. The sky is partly cloudy, and there's a sense of tranquility and isolation.

The image illustrates three different web development architectures for rendering web pages and components: Server-Side Rendering (SSR), Progressive Hydration, and Islands Architecture.


This box shows that in SSR, all components such as the header, static menu, image carousel, filters, product details, and additional recommendations are rendered together on the server and then sent to the client as a fully hydrated page.

Progressive Hydration:

In this architecture, components are rendered on the server, but key components are hydrated progressively on the client. This means that the page becomes interactive in stages, rather than all at once.

Islands Architecture:

This approach shows static components like the header, menu, and product recommendations as server-rendered HTML. Interactive components like the filters, image carousel, and configuration/add-to-cart features are rendered as separate apps, indicating they are likely client-side rendered or hydrated independently.

Each architecture is color-coded to differentiate between static and dynamic content, with a note at the bottom explaining the rendering strategy. The source of the illustration is mentioned as

Wifreframe of a layout with labeled sections. The top section is labeled "Header (interactive island)". Below the header to the left is "Sidebar (static HTML)", and to the right is a larger section labeled "Static content like text, images, etc." Below these, at the bottom left is "Image carousel (interactive island)" and across the bottom spanning the entire width is the "Footer (static HTML)". Each section is indicated with a different border color. The branding "" is positioned at the bottom center outside of the page layout.


Homepage for Astro


    // Example: Use a static React component on the page, without JavaScript.
    import MyReactComponent from '../components/MyReactComponent.jsx';

    <!-- 100% HTML, Zero JavaScript loaded on the page! -->

    <MyReactComponent />


// Example: Use a dynamic React component on the page.
import MyReactComponent from '../components/MyReactComponent.jsx';
<!-- This component is now interactive on the page!
     The rest of your website remains static and zero JS. -->
<MyReactComponent client:load />

Critical Rendering Path

Stylized representation of a film strip that illustrates the concept of the critical rendering path in web performance analysis. It compares "Optimized (progressive) rendering" against "Unoptimized rendering" over a series of time intervals (0.0s, 0.3s, 0.8s, 1.2s, and 1.5s).

For optimized rendering, the content is shown loading progressively over time. At 0.3 seconds, some basic structural elements are displayed. As time progresses, more content is rendered, and by 1.5 seconds, the page appears to be fully rendered with text and images.

In contrast, unoptimized rendering shows an empty frame until 1.5 seconds, when the entire content appears to load all at once.
A repeat of the bike ecommerce page.

Static vs SPA

Filmstrip shows time to full rendering of a static site (1.7s) compared with SPA (10.5s)

Measure an island

A tiny, realistic model of an island with trees, animals, and people is balanced on an old-style, wooden ruler. A human finger appears to be pressing down onto the highest point of the island, topped by a skyscraper-like monument or needle.
A scenic photograph capturing a vibrant sunset at a beach.
The image shows a poolside setting where several individuals are seated on chairs and loungers, each with a laptop. There is a man giving a thumbs-up gesture to the camera, a woman focused on her laptop screen, another person lounging in the background, and a man on the right side of the image sitting comfortably with a laptop on his lap. They all appear to be engaged in casual work or leisure activities in a relaxed outdoor environment surrounded by greenery and poolside amenities.

Hero Times

The hero image on a web page is identified with shading.



The image contains graphical content with the text "LAST Painted HERO" overlaid on top, featuring a stylized design that makes the word "Painted" stand out in red.

Largest Contentful Paint

A screenshot of a webpage with a large image of a red bicycle highlighted to represent the concept of Largest Contentful Paint (LCP).
Screenshot of two pages displayed on moile devices. Shows the hero part could be text not images.

Time to first tweet

Twitter home page is shown, with a tweet highlighted

Element Timing

<img src="/images/logo.png" elementtiming="logo-shown" />
  • Chromium only
  • img and text nodes
  • RUM & Synthetic
Webpage with a logo, title and an image in a carousel highlighted.
The image features a fantastical landscape of a densely packed, hillside village with a whimsical architecture style. The village consists of multiple houses stacked and clustered on top of each other, creating a vertical maze of buildings. Each house has its own unique shape, size, and color palette, with many featuring terraces, stairs, and bridges that connect them.

Think in smaller chunks of content and stream them into the browser (islands architecture

Don't prioritise developer experience over user experience (everything has a cost, especially SPAs)

Keep measurement simple and easy for everyone to understand and improve (build a performance culture)

Pushing Code

Pushing Pixels

Pushing Islands

Speedcurve home page

AI generated images of John Allsopp based on a 1990s white rapper and Steve Jobs

AI generated image combining all these elements. A bearded middle aged white man in a black tshirt wearing a gold chain and glasses.