 Good morning, everyone. How are you guys doing? We're waking up after a long weekend, right? So my name is Ilegre Gorek. I work on the make the world fast team at Google. I'm also developer advocate for Google Chrome. So I focus on all things performance at Google, which is to say we work on of course making Google products faster, but we also try to live up to the goal of making the web faster as a whole, which is to say we work a lot and contribute a lot to a variety of different projects like improving the TCP stack, contributing to the Linux kernel, building Chrome and everything in between. So today what I figured what we're gonna do is we have a lot of time, right? Or relatively a lot of time. Three hours and unlike maybe a regular session where we usually have to be constrained to a specific narrow topic of performance, whether that's CPU or GPU or network, we can actually take kind of a broader view as to how does this stuff actually work, right? Because I think it's very important to understand the why before we talk about the how because sometimes you you know you read the latest blog post with like here's the coolest thing that you can do to make your TCP go faster and then you hurt yourself in the process because you're optimizing the wrong thing or It wasn't the problem to begin with. So with that I spent a lot of time over the weekend trying to think as to how to structure this such that it actually makes sense And I'm glad to say that I've actually managed to boil it down to all into one slide So everything you need to know about performance is just right here. So if you understand how this entire diagram works then we're good. We're done and with that we can take some questions and You know plenty of time. All right Not really. So we're gonna split this into three parts. We're gonna talk about the network because that's Basically, that's the foundation of our performance strategy. We need to of course deliver the actual web app To your mobile device or to a desktop device Then we're going to talk about this concept of critical rendering path Which I think is a kind of a foreign concept to a lot of people but incredibly important and something that we focus quite a bit at google And then last but not least is in-app performance. So once the page is loaded once the application is loaded You know, it may be there for a while think of gmail, right? It sits there in the tab for sometimes days And there's just different constraints there that we need to optimize for like javascript performance garbage collection Rendering and in the rest So with that, let's get right in First of all, of course, it's important to motivate this use case, right? Like performance matters. Performance is fun I love to optimize my code such that it runs faster. But what's the point, right? Is it the kind of thing that you just do for fun? Because it makes you feel good or does it actually affect the bottom line? And I have a couple of case studies that I'll just share with you guys First one is this was actually a joint study done between Bing and google. So this was a study that ran I think maybe three or four years back Now and it was shared at velocity conference and what happened was both bing and google deliberately slowed down Their search pages, right? So we created a test group of users and we delayed the actual results by As you can see here 200 milliseconds 500 milliseconds in a second And then we basically just tracked like what happened, right? Do the users click more? Do they click less? What about the revenue per user? And what you can see here is that after When we added two seconds of delay on the Bing search pages the revenue per user dropped by 4.3 percent Which is of course a huge number if you think about it, right? When revenue per user drops by even 0.1 or percent, there's alarm bells going off everywhere Organization like Bing or Google so 4.3 percent is absolutely massive Another case study that was done. This was actually a Aberdeen group also a few years back They looked at a number of e-commerce sites on the web large e-commerce sites and they discovered that Adding one second of delay Would drop the conversion rate on your cards by seven percent People viewed fewer pages and of course the customer satisfaction also went down So this is not just dollars and cents. This is literally millions of dollars for many applications, right? So every millisecond counts Another data point a more recent one. So this is a great case study Done by one of the rom analytics vendors So I will talk about what rom means It's a sense for a real user measurement where they're gathering beacons performance beacons from hundreds of different sites of their customers and what they're showing here is that Basically the bounce rate or the visitors are clicking back More frequently as the page load time increases. So, you know as you would expect, but this is a good data Proving it and last but not least of course at google we pay attention to speed as well So site speed is of course a signal It is a good signal for a well well performing site So also important to keep in mind So at the end of the day basically what i'm saying here is speed is a future It's a future just like any other future in your application, right? And it should be treated as such it speed is not something that you add at the end of your Great products prints like great, you know, we've built a product and now on the last day. We're going to fix performance It's like no, that's that's not how you do it speed is a future and it's a critical future And it should be prioritized just as you do any other future on your backlog So with that, you know, how are we doing today? All right, we want site to be fast. Where are we? First some constants. So there's been a number of great User case studies and research done that basically shows that despite the fact that, you know, our World seems to be getting faster and faster and faster Nonetheless, there are some pretty good constants that have remained over the last, you know, decades and will remain constant And basically what it says is as long as you react or you respond to the user within a couple of hundred milliseconds Let's say within 300 milliseconds. It feels instant, right? So you click on the button. It immediately gives you feedback That's the that's what you want. Once you approach the one second barrier the user basically Loses track of the task or There's a context switch that may happen, right? So you're you're very busy You're focused on something you're trying to send an email you click the send button And then it's just kind of sitting there and you're like, oh, yeah I also got an email bob and I got to do this other thing and you lost the user Right before you know it. So really what you want to do is you want you want to keep the user engaged And you want to have that fluid experience. You really need to deliver the whole experience in less than one second Ideally, in fact, you want to keep it within 300 milliseconds, which is kind of This is the reason why a lot of the big organizations like google amazon being and others have this unofficial rule of 250 milliseconds we want to render all pages in 250 milliseconds or less, of course Because we want the whole experience to be instant right as you type your search query. We want the feedback to be right there So that's that's good Another constant and an interesting one is that our pages are getting ever more complex and more ambitious, right? So this is some data from the hsp archive project hsp archive.org and what it tracks is currently tracks over 300 000 of the most popular sites on the web and twice every month we basically just crawl the sites And find out how are they built? So we're not really concerned about what's on the pages as much as like how many images do you have? How many javascript files are using web fonts and other things and what this data shows here is that from From january 2011 till about today. We've nearly doubled the size of our pages So an average page on the web today desktop page is about 1.2 megabytes In size, which is of course very large and it's composed of over 80 resources and this is very important We'll come back to why? So there's a lot of small resources here. The goodness of mobile is a little bit better, right? So we are optimizing for mobile or so it seems There the pages are lighter, which is good But nonetheless 57 resources, right? That's a lot of It's not just a page. It's an application at this point So finally we do Once every year we run some analysis at google using google analytics we gather a lot of performance data from all the sites that have it installed and enabled and Last year we did a study and we discovered that an average page on mobile took over five seconds to load Which of course is very long think back to our one second barrier and we're saying five seconds, right? The goodness is this year we ran this is data from about a month back We ran the same analysis and we discovered that desktop basically did not change So the the median page load time for desktop has effectively remained the same Which I guess is not surprising but for mobile we actually made a pretty nice improvement So the pages are loading 30 faster And of course we don't have the exact reason for why that is true because it could be you know It could be anything But our our theory is that well, you know 4g is rolling out across north america very aggressively and more users are migrating towards 4g networks or getting upgraded to even Faster 3g networks and that's great, right? So Mobile got 30 faster in last year, which is awesome At this point, you know, we can just stop this entire show and say that's that's great, right? I'll just sit back and next year my site will be 30 faster. Everything will be cool. We're done Well, not quite right because our pages are getting bigger as well So we're putting as the more resources we give you guys the more you use it up So that's kind of that cancels out that ingates it and Not only that but there are some fundamental limitations there as well. First of all, let's talk about bandwidth, right? It's certainly true that our network speeds are actually increasing And and growing across across the world. So this is data from akamai They have this great free report that you can check out you can type in any country And what you see here is that over the last five years on this horizon The average bandwidth has been increasing quite constantly, right? In fact, japan is kind of way ahead of the pack for Of everybody else But nonetheless if you look at most of the countries we're above five megabits per second And the five megabits number is actually very important and we'll come back to why So that's bandwidth latency is much harder, right? So latency is the time that it takes for a packet of data to travel from your computer to the destination to the server and back Right, that's the roundtrip. So this data is very hard to come by and FCC actually has started running this yearly study, which is really great This is this is data specifically for the united states, but what they're looking at here is they basically installed A measuring node in your home network, right? So they actually send you a device you install it in your home network And then they have a measuring node at the isp So what they're measuring is the last mile latency This is not the total end-to-end latency between your computer, let's say at your house and The actual server and internet but just you know getting from your house to your isp And what they discovered was that for something like fiber to the home It's 18 milliseconds for cables 26 and for dsl's 43 So just to put this into perspective 43 milliseconds is about the time it takes For a packet to travel from the west coast to the east coast All right, so we're talking about the same amount of time just to get from Your computer to your local isp, which is hopefully somewhere not very far, right? I guess which is why which is why we're calling it last mile. So there's some There's definitely some bottlenecks here And at google we of course track The average round trip time to our servers quite closely And we know that in the us the average round trip time to google So this is end-to-end is about 50 to 60 milliseconds and worldwide it's about 100 milliseconds So why is this all important? Well About two years back or three years back at this point. We ran this Study at google Very simple study, but I think it illustrates the point. Well, what's going to happen if we vary latency and bandwidth? Or let's take those independently and just vary bandwidth and keep latency constant and then Do the opposite so what you see here at the top is we start with one megabit per second So we're just varying bandwidth, right? We picked a sample of pages And we've allocated one megabit of bandwidth and the average page load time is about three seconds Okay, we go to about two megabits per second and the average page load time Well, it basically halves right it's cut in half, which is great. It means we were a bandwidth constraint We couldn't download all the resources But then something funny happens as we continue to increase our bandwidth We started getting diminishing returns on our page load times And in fact once you cross that five megabit threshold, right? We started seeing Single digit performance improvements in terms of the actual page load time. So what does this tell us? Well, it tells us that you saw the numbers previously, right? Most of the households an average household today is already over five megabits per second Which is to say I'm guessing most of you guys also have five megabits per second at home You know, you want to make your internet faster So you go out and say, you know what? I'm gonna get the new super plan with 15 megabits per second Because that's gonna make everything go three times faster. You upgrade and you get like a 3% improvement You can't even perceive it. It's like what happened, right? This thing sucks Service is terrible. Well, actually The service could be terrible, of course But independent of that bandwidth is actually not the constraint for web pages and we'll see why in a second Latency on the other hand Shows you a very different picture. It basically shows you that as we decrease latency We get this nice linear progression of pages getting faster Which is exactly what we wanted, of course And by the way, this this case study is actually or the study Is exactly what kicked off our work on speedy at google, which of course now is being standard as And extended as each speed 2.0 So the basic Observation here is that bandwidth, of course matters and I'm not saying bandwidth doesn't matter But after a certain point for web pages, it doesn't give you as much improvement as we would like Right, so upgrading your 5 megabit connection is not going to give you much improvement At least for browsing pages So bandwidth doesn't matter much, right and This is of course, you know, there's caveats here If you're talking about downloading youtube videos or watching nut flex, of course bandwidth matters But for pages specifically That's not our constraint and further Improving bandwidth is you know, I put it in quotes, but it's it's relatively easy. Like how do we improve bandwidth? Right. Well, I can get a second line Right, I can just put another fiber cable beside it and double my throughput for bandwidth. I mean, it's very expensive But nonetheless, it is doable sorry Latency on the other on the other hand is actually very hard because we have this annoying thing called the speed of light And we have not yet figured out how to go faster. I guess a few years back, you know, a few researchers and Thought they had it figured out, but turned out it was a faulty cable. So there you have it So literally the only thing we can do to improve Latency Is lay shorter cables, right? And this is kind of a fun example that I like to share In the last decade, we haven't actually Uh put any more new fiber between Europe and North America because we had enough capacity, right? We just kept upgrading the existing capacity We made the signaling better and basically just improved throughput that way Except just recently there was a new project And I think it's finished by now called hibernate express So what these guys have figured out was that hey New york and london are two very important financial Points around the world and people would pay money to have lower latency for their trading algorithms So what we're going to do is we're going to literally just lay a shorter cable than all the other cables, right? In fact, it's going to be 300 miles shorter And that is going to give us five millisecond advantage over everybody else And this whole project costs about or in the projected cost for about 400 million dollars, which is to say, you know 80 million dollars per unit of millisecond latency, right? That's not a that's not a valid unit, but it kind of gives you a feel for like, you know, every millisecond counts So in this situation, this is uh, this is not a public link. This is only for financial Applications, but that's one way we can improve latency And then we come back to mobile, right? So of course, uh, mobile is top of mind for everybody It's exploding and the problem with mobile or the challenge with mobile I should say for what performance is that latencies are so much higher and uh, we'll actually talk about why that is For example, if you look at sprint and AT&T, I just pulled out these numbers from their technical FAQs If you dig deep enough, you'll find them there. Uh, they basically say that hey for about, you know, for a 3g network expect 150 millisecond to 400 millisecond round trip through our network, right? That's that's just the nature of the beast and for 4g Somewhere in the neighborhood of 100 to 200 milliseconds. So, you know, we're getting at maybe a 2x improvement actually on on the newer networks You can get sub 100 millisecond latency, which is great But nonetheless effectively just think of mobile as you know, three to four times the latency of your desktop connection So why is it that mobile takes so much more Time right or why are the latencies so much higher? Well The first thing that you need to know about mobile specifically is that, you know, the network is designed to meet certain design criteria design constraints, right? So in your house, you have a wireless router and the wireless router follows a very simple strategy. It just says There's one access point. There's a bunch of people that want to talk to me So if you want to talk to me, just talk to me, right? There's no coordination involved whatsoever, right? And this works great. You can actually prove it mathematically prove it that this will deliver pretty good performance As long as the network is not loaded as long as there's not many devices in the room Then you get into a room like this one And you have one why one wi-fi access point and every but everybody here tries to send data or receive data In all of a sudden the network collapses, right? And wi-fi has no No way to control for this, right? It Once the network is is in this congestion collapse There is no way out. So when mobile networks are designed They basically said look we need to be able to control how the network behaves, right? If there is a stadium of people and they all want to talk Perhaps we'll drop everybody's throughput and latency goes really high But nonetheless, I want to be able to service that important phone call or that important message or something else, right? So that's one control over the network and The second one, of course, is just a much larger network A wi-fi access point is designed to operate on a range of tens of meters, maybe hundreds This this is of course much much larger and the second one is battery. So Today nearly every wireless device has a wi-fi built-in But let's recall that wi-fi was not designed for mobile devices specifically The first wi-fi standards came out in the late 90s. Think back to the kind of phone that you had in the late 90s right Wi-fi was not designed for memory or for battery constrained devices So the second constraint for mobile networks is we need to optimize for Battery life because your radio is the second most expensive component in your phone in terms of battery consumption And the reason one of the reasons for that is for example, you go to 4g and we say great with 4g you can achieve One gigabit data rates, right? It's like well. Wow. How do you do that? Well, we just have eight radios transmitting all at once at full power Right. So your phone literally has eight radios transmitting in parallel, right? Just draining your battery like there's no tomorrow you can get one gigabit And you have to be a better meter away from the station, but you can get one gigabit At which point he could just run the cable. I guess so all of that to say mobile networks have this concept or this this controller called the radio resource controller and the the basic way to think about it is The radio resource controller controls when and who Is able to talk, right? So it's a moderator effectively, right? I say Hey, I would like to ask a question or like to send some data the moderator gets my message It says okay. I have the schedule all of these people want to talk I'm going to give you the slot you're going to transmit with this amount of power And that's the resource assignment that you have, right? He sends me back that assignment I wait for my turn and then I speak All right, so that's how mobile networks work And by the way, the radio resource controller will also tell you when to go to sleep, right? So you'll be listening for incoming packets and it'll it'll just send a message to you and say hey, there's like no traffic here You're occupying Airspace just go to sleep. I'll notify you when there is new messages for you So why is this important? Well, because it creates extra latency, right? Like there's all this overhead now compared to wi-fi You just woke up. You start started transmitting data with the radio controller. You basically need to talk to him first Get this assignment and all the rest so When you dig in into the standards, you'll often find dimensions of the of these concepts called the control and user plane latency So the control latency is effectively what we just described Which is us talking to the moderator and asking for permission for when we can when we can talk So what happens is the phone wakes up, right? We want we want to we type in google.com We hit enter Or the gokey and the the phone sends a message to the radio controller saying hey, I would like to start transmitting data The rsc which in the 4g networks actually lives at the actual radio tower does the assignment and sends you back Basically your your information On 3g networks the radio resource controller actually leaves The deep in the core of the network which is part of the reason why there's so much more latency Involved in 3g Geez sorry So if you look at the actual timing for the 3g spec and 4g spec this First step this control plane latency here can take up to two and a half seconds I mean that is written in the spec and in fact it can often take Just as long so this is before your phone can even send a single packet of user data or application data, right? Two and a half seconds passes And then we can start talking which of course is Terrible has terrible implications for performance, right? We want to deliver pages in 200 milliseconds Well, we got a problem here, right? So that's step one This is this of course only happens once when you wake up to your phone, right? So every time we need to transmit data But nonetheless this is very very important a lot of people think of wireless networks or mobile networks specifically as highly unpredictable The latency is so variable Actually, once you factor this in You'll discover that a lot of this variability can be modeled fairly well, right the first time you send the packet There's going to be this long pause after that It's pretty good And once you have this assignment you basically just start sending data directly to the tower And you know depending on the standard that you look at for example Most of the 3g networks or 3.9g networks in the united states are hspa plus at this point And what this tells you here is that Transmitting data from your phone to the radio tower takes an average about 10 milliseconds, which is still a lot of time for sorry Yes, and for LTE or the the 4g networks it takes five milliseconds, but nonetheless, right these are Hi, there's higher overhead here now This looks very complicated, but I just want to illustrate the point of this is how 4g network works And this is why it takes hundreds of milliseconds. So just stay with me here, right? What we're trying to do here is we want to send a packet of data From let's say your service to the phone. So the phone is currently idle, right? You've been moving around I need to send you a notification saying that hey, you've got a new message from your favorite social network so Here we go We start with one right so we our service sends a packet of data The packet of data comes to the packet gateway, which is basically like a router, right? Just like a router at your house it terminates the tcp connection This router doesn't actually know where you are on the physical network So it sends it to another component called the serving gateway The serving gateway kind of knows where you are in the geographical sense of like you're somewhere in san francisco, right? So it gets the the packet of data, but that doesn't actually know which tower you're associated with at this point. Great and We also don't know if we should be forwarding this packet to begin with so there's another component called the multimedia management entity I think And what it What it does and what its role is it's basically a user database, right? It knows who you are. What's your billing status? Should I be forwarding packets or you overdo on your bill and should I just drop the packet on the floor, right? So we query the user database and say hey, I've got a packet for this ID user blah blah blah. Where do I send it? Well, the user database doesn't actually know either So it's like, you know what I'll just send I'll just flood the network. I'll just tell all the radio towers to flood the network and Send a beacon saying hey user x you have a message for you, right? Tell me where you are So all the radio towers send this beacon your device periodically wakes up listens to and says hey, there's a message for me. Great I'll talk back to the tower and say hey, I'm here. I'm you know Register me at this point the tower then registers you sends the information back to this entity here Which goes back to the serving gateway and then the serving gateway can funnel the data back to your phone Right. It's like oh my god. All right. What happened here? This is just for one tcp packet, right? Like this is this is nuts But if you go back, right this this explains why there's so much overhead, right? So on 4g we can do this entire flow in 40 to 50 milliseconds And what's interesting is that the 3g and 4g specs actually specify hard limits on the latency Right. So these are upper bounds. These are not averages. We're basically saying for 4g network The worst case scenario is 40 to 50 milliseconds Right. Well in this case, this is AT&T, but for There's an actual hard limit on LT that says 50 mils and we have to meet this goal And Basically, we're looking at the worst case scenario here So it doesn't mean that every single packet will incur this cost And of course once we know where you are and we can catch that data and we don't have to kind of Flood the network every single time that'd be silly But nonetheless, if you ever wonder like why does it take 300 milliseconds for a mobile network to route my packet? This is why right? It's complicated The problem here is that with wi-fi you're associated with one access point But with mobile networks, you know, you're mobile you jump into a car and start moving and and everything goes out the door But let's come back A few steps. We've actually skipped. We said that latency matters for Web performance, but why right? Why is so there's this relation between bad and with the latency? What's the problem to begin with? And that's where we need to go kind of one level deeper and look at tcp and how tcp works so In a nutshell when you start a new connection to a server Let's say you have a five megabit connection right because uh, Or a 10 megabit connection on even on your mobile phone At the beginning of the connection, we can't actually use the full bandwidth of that connection And the reason this works, uh, this is known as tcp slow start The reason we have this behavior. This is built in into tcp Is because we don't want to flood the network, right? Maybe the network is congested So what we're going to do is we're literally going to start slow, you know We're going to start by sending a little bit of data see if you receive it once you acknowledge it I'm going to start continuing sending you more and more data, right? So what this graph is showing you here This is known as this is the tcp slow start phase here. So we start by sending you just a couple of packets You acknowledge those packets. I double the number of packets. I send you you acknowledge those packets I double the number of packets again, right? So what this immediately tells you is that it takes a certain amount of time For the bandwidth to ramp up to full Full capacity of the link so we can't even saturate the link immediately And then after a certain point a packet loss event occurs. So maybe we've sent too much data. We've saturated the network The packet has dropped and we back off and we restart the process with a slightly different algorithm, right? And this is how tcp works under the hood So despite its name, it's a future not a bug And this is how tcp works. We don't This is inherent in the protocol itself so Let's now look at the actual hspe request like what does it actually take to deliver a page, right? So we want to serve the google home page really really fast. That's great First we need to do a dns lookup, right? So you type in a domain name We need to figure out what does the ap address associated with that on a mobile network that can take a couple hundred milliseconds as you saw, right? Plus the control plane latency on top after that We need to do the tcp handshake and we'll see an example in a second The tcp handshake is just us opening the socket. That also takes a round trip of latency there and back, right? After that we can actually finally send the hspe request saying hey I would like to get the index page of your service. That'd be great, please And then the server of course generates the response So that's the time on your on your server or your server response time And after that we also have the content download time and the download time depends on how much bandwidth we have And how far along we are in a connection because you know depending on if it's us If it's a new connection then we are still subject to a slow start and we can only deliver data bit by bit So here's an example Kind of a very hands-on look we skipped the dns part. So this is just us trying to establish a tcp connection So What i'm showing you here is let's fetch a 20 kilobyte file right a very small file 20 kilobyte file over a new tcp connection and this is all i'm calling this a low latency link So this is kind of like a typical desktop connection, right 56 millisecond round trip Between let's say new york and london. It's kind of a good theoretical number right now So first we start with a sin packet We get a sin act. So this is our tcp handshake at the top right here Then we send the actual get request for the file The server starts processing the request it generates the output of the html etc Let's say that takes 40 milliseconds or so and then it starts sending data But because it's a new connection it can only send you About four kilobytes of data Right, so it sends you four kilobytes of data you get this data You're saying great. I got it. You send an act back. You acknowledge all those packets Now we double the window and we send Approximately eight kilobytes of data and then you act that and then we send you the remainder So just to transfer 20 kilobytes of data We've had four round trips here and if you add up the numbers here, right? This is 260 milliseconds This is just for 20 kilobytes of data And of course, you know, we skipped dns So add a couple hundred hundred milliseconds top of that and if we're talking over a secure connection with tls Then there's another up to two round trips just to establish the secure connection So, you know, if if this is a cold start, which is to say, I don't know what your ip address is associated with the host name And I need to do a secure connection Then we're looking at somewhere in the neighborhood just in this example of over 500 milliseconds right, so that's That's kind of the bottom layer of this. This is what's achievable with the current network Infrastructure and by the way in this specific example, you know, why are we sending four kilobytes of data here? This is actually Part of the rfc if or was part of the tcp rfc Which said you should start with a specific number of three or four network segments just recently. This was actually updated to Start with 10 segments, which if you do the math if you follow the same workflow will actually eliminate an extra round trip here so I'll talk about this later But you probably want to update your linux kernels to the latest version to get that because that will immediately Improve the latency on all of your servers Or for all of your users, they say Okay, so let's try the same example with with a 3g or a 4g network, right? So there's a couple of new things that we talked about first. There is the control plane latency This is this is incurred if we have to wake up the radio. This is the first transmission that happens So depending on which network type we're looking at this could be 100 milliseconds or up to two and a half seconds on 3g then we do the dns look up the tsp connection tls hsp request followed by A couple of round trips to fetch the same 20 kilobytes and you add up the numbers and you're looking at You know on a 3g network somewhere in the neighborhood of between of one and four seconds All right So now think back to that number that I was saying earlier last year when we said an average page load time for mobile Was over five seconds. Well, this is in large part. Why right? This is it's not just a simple matter of like Oh, we build terrible mobile pages like well, that's how the network works And we're working actually working on making it better But these are the constraints that we have to work with when we design our pages Like we need to understand as web developers that it's going to take One to four seconds for the page to render right because if I'm building if I'm trying to build a responsive application I can't I can't design something where you click on a button and then we just kind of sit there for five seconds With the button stuck right? I need to acknowledge the input immediately and then say like look I'm working on it Right. This is a 3g network. I've got your data plan here Not my fault But you know, there's certain things you can do in the ui design of your application to work around this So some good news and some not so good news First of all, you know, if you look around Or just turn on your tv You'll find a lot of 4g ads everywhere, right? Like 4g will save all things the latest 4g network is here Faster than ever before which is cool. And I think a lot of us here would are probably already Lucky enough to be in a 4g connection But in reality, if you look at the industry projections, you'll find that the 3g networks Will be the dominant network types of the next decade not just like this year or the next year of this entire decade Right. So what's happening is the current carriers have invested a lot of Time money and infrastructure into building out the existing network infrastructure And they're just upgrading it. Um, the good news is with the latest networks like hspa plus They're actually back porting a lot of the great performance improvements from the latest 4g lte networks into hspa plus So performance wise, they're actually getting better much better Um, and funny enough, you know, technically The hspa plus networks shouldn't be called 4g except they are because they're almost quite like, you know Fast enough. So it's it's kind of a it's 4g is a marketing term Not really a technical term in that sense so takeaways here We can't count on users having 4g In fact, even if you have a 4g data plan your phone is switching between 4g and 3g Throughout the day, you know based on congestion based on where you are based on signal strength, etc So you can't just count on this, you know, great 50 millisecond latency of 4g connection The good news is uh, is that the lte adoption or the 4g adoption is actually way ahead of the curve across north america So if you're specifically targeting, you know north america with your applications, uh, that's good news Right, so you can actually count on faster connections, uh from your users, which is good But really, uh, if you look at the longer term projections 4g networks all the lte networks will start to surpass existing infrastructure only after 2012 Sorry 2020 not 12. I wish it was 12 So, you know, all of this is a very long way of saying latency is a bottleneck for web performance today And it is a bottleneck because we download a lot of very small files and we require a lot of connections And as you saw there's tcp slow start There is latency problems like our last mile latency even on you know within rsp is very high But it's much much higher in in a mobile context And uh, the network won't really save us. We can't just sit back and say like great You know, we're gonna get a 30 improvement every year in latency. That is simply not the case Even in our wired networks. We're actually within a very small constant factor of the maximum theoretical speed All right, like maybe we can squeeze out another 20 improvement and get a little bit closer to the speed of light But we're ready within like 1.3 Of the actual maximum. So, uh, you know if They discover how to make packets travel faster than the speed of light Then none of this is a problem and everything's great. But until then we've got a problem