Svelte 5 And The Future Of Frameworks: A Chat With Rich Harris - Related to performance, time, 5, harris, chat

How To Find and Fix What’s Trashing Your App Performance

Troubleshooting slow app or website performance is one of the more frustrating tasks developers face. Reliability is a key performance indicator and user experience metric, so when something goes wrong, it rises immediately to the top of your priority list. Unless you can find and fix the problem fast, everything else you’d planned to do today is getting pushed into the future.

Picture this: You’re busy at your keyboard, trying to hit a milestone on an key yet incremental upgrade to your corporation’s key user-facing app. Suddenly, your ticketing system goes berserk — dozens of customers are reporting that they can’t access an essential feature in your app. More patient customers study they can access it … eventually. It’s taking minutes to load, not seconds, as they’re used to.

You check your app’s performance in your monitoring tool, and everything looks fine — all the indicators are showing green. But your people are saying the app is slow — which, as far as they’re concerned, means it’s down.

Uncover What’s Degrading Digital Performance.

The evolution to internet-centric application delivery has made it increasingly challenging for IT orgs to identify the root cause of app or website slowness due to visibility gaps into what impacts an end user’s experience.

The solution is true end-to-end monitoring, from the first to the last mile. You need to have persistent visibility beyond the cloud, including the backbone ISPs and wireless networks, and across your entire internet stack. In a Forrester Consulting study, 75% of respondents mentioned that being able to quickly and efficiently identify and fix the source of digital disruptions — by monitoring everything affecting individuals across the internet — would have a large or significant positive impact on their business.

If you’re not sure how to get there, join us on March 25 at 1 [website] ET | 10 [website] PT for a special online event: Performance Under Pressure: Why Internet Performance Monitoring is Non-Negotiable for Today’s Websites and Apps. During this free webinar, Gerardo Dada, Field CTO at Catchpoint, and TNS Host Chris Pirillo dig into how leading digital organizations are developing robust visibility strategies for critical apps, and how Internet Performance Monitoring (IPM) holds the key to ensuring your ITOps success.

By attending the live webinar, you’ll have the opportunity to ask and get practical answers to your questions. And you’ll leave with best practices, real-world examples and actionable tips to help you develop a digital experience monitoring strategy that [website] you can’t join us live, register anyway and we’ll send you a recording following the webinar.

Register for This Free Observability Webinar Today!

What You’ll Learn About Internet Performance Monitoring.

By attending this special event, you’ll:

Understand the differences between Application Performance Monitoring (APM), Digital Experience Monitoring (DEM) and Internet Performance Monitoring (IPM) and why each is critical in today’s IT landscape.

Learn how IPM provides the visibility necessary to monitor the full Internet Stack, from DNS to BGP and beyond.

Discover how to integrate IPM into your monitoring strategy to proactively prevent outages and enhance user experience.

So far, 2025 has been the year of AI agents — where generative AI technology is used to automate actions. We’ve seen OpenAI’s Operator debut, demonstr......

Concurrency has always been a cornerstone of modern software development, enabling applications to handle multiple tasks simultaneously. In Java, trad......

Ken Stott, Field CTO of API platform Hasura, tells Ryan about the data doom loop: the concept that organizations are spending lots of money on data sy......

Time To First Byte: Beyond Server Response Time

Time To First Byte: Beyond Server Response Time.

Optimizing web performance means looking beyond surface-level metrics. Time to First Byte (TTFB) is crucial, but improving it requires more than tweaking server response time. Matt Zeunert breaks down what TTFB is, what causes its poor score, and why reducing server response time alone isn’t enough for optimization and often won’t be the most impactful change you can make to your website. Optimizing web performance means looking beyond surface-level metrics. Time to First Byte (TTFB) is crucial, but improving it requires more than tweaking server response time. Matt Zeunert breaks down what TTFB is, what causes its poor score, and why reducing server response time alone isn’t enough for optimization and often won’t be the most impactful change you can make to your website.

Loading your website HTML quickly has a big impact on visitor experience. After all, no page content can be displayed until after the first chunk of the HTML has been loaded. That’s why the Time to First Byte (TTFB) metric is key: it measures how soon after navigation the browser starts receiving the HTML response.

Generating the HTML document quickly plays a big part in minimizing TTFB delays. But actually, there’s a lot more to optimizing this metric. In this article, we’ll take a look at what else can cause poor TTFB and what you can do to fix it.

What Components Make Up The Time To First Byte Metric?

TTFB stands for Time to First Byte. But where does it measure from?

Different tools handle this differently. Some only count the time spent sending the HTTP request and getting a response, ignoring everything else that needs to happen first before the resource can be loaded. However, when looking at Google’s Core Web Vitals, TTFB starts from the time when the customers start navigating to a new page. That means TTFB includes:

The actual request for the HTML document.

We can see an example of this in this request waterfall visualization.

The server response time here is only 183 milliseconds, or about 12% of the overall TTFB metric. Half of the time is instead spent on a cross-origin redirect — a separate HTTP request that returns a redirect response before we can even make the request that returns the website’s HTML code. And when we make that request, most of the time is spent on establishing the server connection.

Connecting to a server on the web typically takes three round trips on the network:

DNS: Looking up the server IP address. TCP: Establishing a reliable connection to the server. TLS: Creating a secure encrypted connection.

What Network Latency Means For Time To First Byte.

Let’s add up all the network round trips in the example above:

That means that before we even get the first response byte for our page we actually have to send data back and forth between the browser and a server eight times!

That’s where network latency comes in, or network round trip time (RTT) if we look at the time it takes to send data to a server and receive a response in the browser. On a high-latency connection with a 150 millisecond RTT, making those eight round trips will take [website] seconds. So, even if the server always responds instantly, we can’t get a TTFB lower than that number.

Network latency depends a lot on the geographic distances between the visitor’s device and the server the browser is connecting to. You can see the impact of that in practice by running a global TTFB test on a website. Here, I’ve tested a website that’s hosted in Brazil. We get good TTFB scores when testing from Brazil and the US East Coast. However, visitors from Europe, Asia, or Australia wait a while for the website to load.

What Content Delivery Networks Mean for Time to First Byte.

One way to speed up your website is by using a Content Delivery Network (CDN). These services provide a network of globally distributed server locations. Instead of each round trip going all the way to where your web application is hosted, browsers instead connect to a nearby CDN server (called an edge node). That greatly reduces the time spent on establishing the server connection, improving your overall TTFB metric.

By default, the actual HTML request still has to be sent to your web app. However, if your content isn’t dynamic, you can also cache responses at the CDN edge node. That way, the request can be served entirely through the CDN instead of data traveling all across the world.

If we run a TTFB test on a website that uses a CDN, we can see that each server response comes from a regional data center close to where the request was made. In many cases, we get a TTFB of under 200 milliseconds, thanks to the response already being cached at the edge node.

What you need to do to improve your website’s TTFB score depends on what its biggest contributing component is.

A lot of time is spent establishing the connection: Use a global CDN.

The server response is slow: Optimize your application code or cache the response.

or Redirects delay TTFB: Avoid chaining redirects and optimize the server returning the redirect response.

If you want to get a breakdown of what TTFB looks like for different visitors on your website, you need real user monitoring. That way, you can break down how visitor location, login status, or the referrer domain impact real user experience.

DebugBear can help you collect real user metrics for Time to First Byte, Google Core Web Vitals, and other page speed metrics. You can track individual TTFB components like TCP duration or redirect time and break down website performance by country, ad campaign, and more.

By looking at everything that’s involved in serving the first byte of a website to a visitor, we’ve seen that just reducing server response time isn’t enough and often won’t even be the most impactful change you can make on your website.

Just because your website is fast in one location doesn’t mean it’s fast for everyone, as website speed varies based on where the visitor is accessing your site from.

Content Delivery Networks are an incredibly powerful way to improve TTFB. Even if you don’t use any of their advanced aspects, just using their global server network saves a lot of time when establishing a server connection.

Makulu Linux is a Linux distribution you’ve probably never heard of, which is a shame because it’s pretty cool. This flavor of Linux is based on Debia......

As the size and responsibilities of device fleets explode, the development of scalable processes to manage them is more crucial than ever. With our ti......

Svelte 5 And The Future Of Frameworks: A Chat With Rich Harris.

After months of anticipation, debate, and even......

Svelte 5 And The Future Of Frameworks: A Chat With Rich Harris

Svelte 5 And The Future Of Frameworks: A Chat With Rich Harris.

After months of anticipation, debate, and even a bit of apprehension, Svelte 5 arrived earlier this year. Frederick O’Brien caught up with its creator, Rich Harris, to talk about the path that brought him and his team here and what lies ahead. After months of anticipation, debate, and even a bit of apprehension, Svelte 5 arrived earlier this year. Frederick O’Brien caught up with its creator, Rich Harris, to talk about the path that brought him and his team here and what lies ahead.

Svelte occupies a curious space within the web development world. It’s been around in one form or another for eight years now, and despite being used by the likes of Apple, Spotify, IKEA, and the New York Times, it still feels like something of an upstart, maybe even a black sheep. As creator Rich Harris lately put it,.

“If React is Taylor Swift, we’re more of a Phoebe Bridges. She’s critically acclaimed, and you’ve heard of her, but you probably can’t name that many of her songs.”.

This may be why the release of Svelte 5 in October this year felt like such a big deal. It tries to square the circle of convention and innovation. Can it remain one of the best-loved frameworks on the web while shaking off suspicions that it can’t quite rub shoulders with React, Vue, and others when it comes to scalability? Whisper it, but they might just have pulled it off. The post-launch reaction has been largely glowing, with weekly npm downloads doubling compared to six months ago.

Still, I’m not in the predictions game. The coming months and years will be the ultimate measure of Svelte 5. And why speculate on the most pressing questions when I can just ask Rich Harris myself? He kindly took some time to chat with me about Svelte and the future of web development.

Svelte 5 is a ground-up rewrite. I don’t want to get into the weeds here — key changes are covered nicely in the migration guide — but suffice it to say the big one where day-to-day individuals are concerned is runes. At times, magic feeling $ has given way to the more explicit $state , $derived , and $effect .

A lot of the talk around Svelte 5 included the sentiment that it marks the ‘maturation’ of the framework. To Harris and the Svelte team, it feels like a culmination, with lessons learned combined with aspirations to form something fresh yet familiar.

“This does sort of feel like a new chapter. I’m trying to build something that you don’t feel like you need to get a degree in it before you can be productive in it. And that seems to have been carried through with Svelte 5.”.

Although raw usage numbers aren’t everything, seeing the uptick in installations has been a welcome signal for Harris and the Svelte team.

“For us, success is definitely not based around adoption, though seeing the number go up and to the right gives us reassurance that we’re doing the right thing and we’re on the right track. Even if it’s not the goal, it is a useful indication. But success is really people building their apps with this framework and building higher quality, more resilient, more accessible apps.”.

The tenets of a Svelte philosophy outlined by Harris earlier this year reinforce the point:

The web matters. Optimise for vibes. Don’t optimise for adoption. HTML, The Mother Language. Embrace progress. Numbers lie. Magical, not magic. Dream big. No one cares. Design by consensus.

Rich Harris – North Star, JSNation US 2024.

Frameworks are a means to that end, and Harris sees plenty of work to be done there.

Every milestone is a cause for celebration. It’s also a natural pause in which to ask, “Now what?” For the Svelte team, the sights seem firmly set on shoring up the quality of the web.

“A conclusion that we reached over the course of a recent discussion is that most software in the world is kind of terrible. Things are not good. Half the stuff on my phone just doesn’t work. It fails at basic tasks. And the same is true for a lot of websites. The number of times I’ve had to open DevTools to remove the disabled attribute from a button so that I can submit a form, or been unclear on whether a payment went through or not.”.

This certainly meshes with my experience and, doubtless, countless others. Between enshittification, manipulative algorithms, and the seemingly endless influx of AI-generated slop, it’s hard to shake the feeling that the web is becoming increasingly decadent and depraved.

“So many pieces of software that we use are just terrible. They’re just bad software. And it’s not because software engineers are idiots. Our main priority as toolmakers should be to enable people to build software that isn’t broken. As a baseline, people should be able to build software that works.”.

This sense of responsibility for the creation and maintenance of good software speaks to the Svelte team’s holistic outlook and also looks to influence priorities going forward.

Part of Svelte 5 feels like a new chapter in the sense of fresh foundations. Anyone who’s worked in software development or web design will tell you how much of a headache ground-up rewrites are. Rebuilding the foundations is something to celebrate when you pull it off, but it also begs the question: What are the foundations for?

Harris has his eyes on the wider ecosystem around frameworks.

“I don’t think there’s a lot more to do to solve the problem of taking some changing application state and turning it into DOM, but I think there’s a huge amount to be done around the ancillary problems. How do we load the data that we put in those components? Where does that data live? How do we deploy our applications?”.

In the short to medium term, this will likely translate into some love for SvelteKit, the web application framework built around Svelte. The framework might start having opinions about authentication and databases, an official component library perhaps, and dev tools in the spirit of the Astro dev toolbar. And all these could be precursors to even bigger explorations.

“I want there to be a Rails or a Laravel for JavaScript. In fact, I want there to be multiple such things. And I think that at least part of Svelte’s long-term goal is to be part of that. There are too many things that you need to learn in order to build a full stack application today using JavaScript.”.

Although Svelte has been ticking along happily for years, the release of version 5 has felt like a new lease of life for the ecosystem around it. Every day brings new and exciting projects to the front page of the /r/sveltejs subreddit, while this year’s Advent of Svelte has kept up a sense of momentum following the stable release.

Below are just a handful of the Svelte-based projects that have caught my eye:

Despite the turbulence and inescapable sense of existential dread surrounding much tech, this feels like an exciting time for web development. The conditions are ripe for lovely new things to emerge.

And as for Svelte 5 itself, what does Rich Harris say to those who might be on the fence?

“I would say you have nothing to lose but an afternoon if you try it. We have a tutorial that will take you from knowing nothing about Svelte or even existing frameworks. You can go from that to being able to build applications using Svelte in three or four hours. If you just want to learn Svelte basics, then that’s an hour. Try it.”.

Adam’s such a mad scientist with CSS. He’s been putting together a series of “notebooks” that make it easy for him to demo code. He’s got one for grad......

In 2025, forward-thinking engineering teams are reshaping their approach to work, combining emerging technologies with new approaches to collaboration......