 All right, so I'm going to be talking on building high performance with applications. So I was talking to people before lunch and in the morning sessions and this one question that came up all along was, is performance really that important? I mean, how does a one second delay really change the world and the world is not going to come to an end? But if it's kind of contextual right, so it's not that every night a one second delay is actually causing a lot of problems, but in situations where your e-commerce website a one second delay would probably set you back 10% of check-outs would drop off, right? That impacts your revenues. So there's been a lot of research, Amazon, eBay, Google and all these guys have done the research and said performance is your advantage, right? So this is what I'm going to be talking about. So I'm Karthik, I work at PayPal India, I'm a performance engineer, but those of you who don't know what PayPal is all about, they're part of eBay, I hope you guys know what eBay is all about. So anyway, there's a little bio there, you can read that, I'm Karthik dot on Twitter, so please feel free to reach out to me. Like so I was talking about PayPal. PayPal happens to be one of the best places to work in India and it's also ranked number six in technology companies, which is just me writing about my company, sorry. And also we ranked as the most innovative company in finance industry. Anyways, so keep going. Right, so building five companies without the insurance. So there's been a lot of, performance is not a branding topic, it's been there for a long time now, there have been some best practices, the industry said this is how you do things. And everyone who's new to this industry would say, hey, go look up Yahoo's performance guidelines. This is the first thing that people do, and they need a bunch of things, you know, and it all boils down to something like this. It's a reduced HTTP request, do not request. It says, don't have extra minutes if you want, if you have images, use price. If you have a lot of sales after that, really like I'm guiding you. At the end of it, all they say is reduce the number of HTTP requests, right? And there's a lot of variations, you have image price, your CSS, JavaScript, and all those kinds of things. And the other magic bullet or the simple bullet is use CDN, use Akamai, and it's on cloud and you know, things will just be different. You know, this is like this huge misconception that the moment you start using a CDN, your site is fast, right? That's what the assumption is. And it's not really so. There are, again, common cases to this, but performance really is not, you need a bunch of articles and say, this is how I'm going to make my web application. It is actually implementing these trial and error, taking on what works for you, what doesn't, and that's how you do it. So I'm not going to be talking about all these things. You can as well go and read Yahoo's performance guidelines. They've done a good job with this. So, seriously, that is not enough. You cannot do the same thing with the previous years, 15 years, Yahoo said it, Google said it, Amazon has said it. That is not enough. We need to do something more to actually improve the performance. So these traditional ways of doing things are not going to work. It will work. I'm not saying it's not a solution. I'm saying that this is not the only solution. They are better based on the rules. Why? So web view is getting more complex. This is like our, you know, Bollywood movies, more or less. You know, 1960s you had black and white things with no magic mystery happening on the screen. Everything was pretty static. And then came Amitabh Bachchan in the 90s and there was some magic and the discos and all that shit. Something, something. And now you see you have, God knows what's happening in the movie. There's one guy who dies in the middle of nowhere and then somebody else is caught. Random things, right? Essentially, the five things are web pages on the internet today getting more and more complex, right? This is how it was in 1995. And it's pretty obvious. Everything getting a lot more complex. And we cannot do the same thing that we've been doing all along to make this work. So I'm going to be talking a little more on a little bit advanced, not really advanced. Pretty simple things to do on how you can actually make an impact to the user experience that you're going to see when they access your website. So I'm going to be talking about lately loading. Okay. Don't load until you need to. So prevent front-end spot essentially being a single point of failure. You have something on your website that dies and you have side events. You know, blast. It's just gone. It's not there. Ernie Flush. Charm of responses. This is one of my favorites. Async in script loading. This is again kind of hot in the industry. Like my viewer talks about async and all that. And Google's feeding up and coming. It's not there yet. But I'll bring me touch upon this and see how you can actually make that. Right. So I was talking about front-end spot. I'm just going to work trying to get on this. So how many of you guys actually run a website? You have a blog or you have something? You have Twitter buttons, Facebook buttons. You have to meet this blog post of mine like this. I'm sure if you guys don't have it, you're not running a blog. Trust me. A blog is not without social network. Okay. So if you have a blog and you don't have these icons, Google put it and then continue it. So I'm sure you guys have this Twitter buttons on the website. Right. I'm just going to pick on Twitter because it has the habit of going down. Almost every other time. Right. It goes down. So what happens to your website? If it goes down, then you have a simple tweet button. I'm just going to play a video. I don't want to do a live demo because things can go badly wrong. So this is how it would be. So this is the normal that's Twitter being down in 20 seconds. Now it starts going. Basically, what happens here is, you know, you have a Twitter button, you have embedded your HTML code in it. Now you browse it, try to contact the servers. They're dumb. It retries. Okay. There's a timeout. They keep retrying until the timeout happens. And because of that fact, it stops everything else on that page. And then finally when they realize this Twitter is no longer alive, they start showing the page. Now this is what I call frontend's pop. Single point failure. This is happening today in more so ways because of the fact that in 1995, we had website which was completely managed by us. But today if you look at, we have a lot of third party agents, third party JavaScripting tools, right? You have all kinds of buttons and all kinds of things. One of them can actually bring your side. So you guys can actually go to this link on this slide. I'll be sharing the slides later on. This is the way how you can test your website to see how this failure works outside or not. Go home, check this. And if you're doing well, if Twitter goes down your slides, that's really good. And that's what we're trying to do here. So how do we get this is by doing lazy-loaded Twitter buttons. Show your main content first and then show your Twitter button. Twitter button is not your content. Your content is your article, your blog post or whatever. So show that. So that's lazy-loaded. And there are multiple ways of doing it. So lazy-loading is what I was talking about. Load steps and demand, progressive rendering. Show what's needed. Show your blog post. Show your fancy header typing and all that. Don't show your ads. Ads come later. Don't show your Twitter button. Now these are the steps. Progressive rendering. So first show your content. Once that's there, the user is seeing this, interacting with your content. Then start loading ads, which is whatever. So you load that in a lazy-loaded fashion. And the next thing is render content about the port. About the port is essentially what is visible without having to scroll vertically. So if you can show this much, the user sees, okay, I have half a page to read right now. I'll start looking at this. And by the time he actually decides to scroll, the rest of the content is there. Don't load the entire thing. And then user, there's a long process for him to start interacting with you. So show about the port content and then jump to how you can do below the port. So internet users have this insanely quality perception of time. Let's say this is the actual load time. When I'm actually browsing this website, I feel that this is 15% slower. Say for instance, it takes 10 seconds. I feel it's taking like 11 and a half seconds. That's my perception. And now if I go home and tell my mom or dad, it's completely different. Okay, I'm telling this is like 35% slower than what it actually was. So I'm telling this site took 13 seconds, not 10. 10 was the actual. When I first thought about it, I said 11. I went home, I tell the other people it's 13. Right? So this is the perception of this. The reason why I'm telling you this is if your site is not fast and your users go and tell their friends, they never want to come to your site. Right? And this is again how important this performance because it spreads word of mouth. You all know what is slowest sites on planter. IRCTC performance. You know this. Everyone knows IRCTC will never load when you want to take it. People give up on it and that's loss of business. Right? If you are running IRCTC, I hope you would go and fix it. I hope there's someone from IRCTC here. I'm not sure. So this is the problem, right? The perception. You go home, you convey a completely different image of what actually happened. Okay. So this comes to... Yeah. I do that. So if your site loads really fast I'm sure you wouldn't tell your friends that this site is so fast. It's always so bad. You would compare the peers in that industry. So let's say I'm picking on Clearboard. I'll go home and say, Clearboard is much faster than IRCTC. Right? That's my comparison point. But when you talk about IRCTC alone in the slow side, you would say this site is so bad. Right? So having a really good fast website is pretty good. So coming back to my perception point. So how do you make sure that the users feel that something is happening to perceive performance, right? Your site might actually take five seconds. But if you start showing things at one second, two seconds, three seconds, the user will actually feel something is happening on the screen. I can go and do something, right? Don't wait for five seconds and then dump it on the user's face. Do it in progressive manner. If you're a PHP guy, all you have to do is this one line of quotes, PHP flush. Okay? I'll tell you how that actually works. And I'm sure all of your websites have CSS, JavaScript, images and all these kind of things, right? Now load these things. If you look at the typical ways of doing things, the JavaScript performance guidelines would say, CSS at the top, JavaScript at the bottom of the page, okay? Everything else in between. KV load, images and all that. What I'm trying to do here is if your website is a backend intensive system, start dumping the static assets first. Okay, don't wait for your backend to actually generate the complete response. If your website takes like two seconds, there's a lot of TV intensive stuff happening in the backend, skip all that. Your CSS and JavaScript is not dependent on what happens in the TV, right? It essentially uses specific. So if you can push out the CSS and JavaScript the earlier, the better. The browser will start downloading it. It won't do anything. It'll at least start downloading. So this is early flush chunk responses. So I'm going to show a demo how this could actually look in the real life. Okay, so this is how Yahoo does it. So they have this Yahoo homepage, right? So they actually flush after the top navigation on the site. So if you actually hit Yahoo.com on a slow connection, the first thing you would see is a search box, which is again the most important thing for Yahoo, right? And then they flush this entire thing one shot. This is more or less about the fold to an extent. They might be a little bit that scrolls downwards. Never mind. And then at the end is when they actually think about doing the putter, right? So they flush at regular intervals. And the user will see this thing first, then this, then this. It's never everything in one shot. It's always at regular intervals. So I'm making an example on, okay, one of my, we recently launched a product, PayPal Gear. So I've just taken that website as an example and to show you how it could look on a comparative basis. If you do a flush and if you don't do a flush. I hope you saw the difference. So this is the early flush, normal way of doing things. It's almost like a two second improvement. This works for us because the reason I'm telling you this is all these solutions are not silver bullets. It's not something you go home and implemented your sideline 50% faster. These are very dependent on the kind of website you run. This works in a situation where you're a back end intensive system. So we are one. So I actually flush the navigation at first. It has the JavaScript and CSS. The browser actually downloads it. The moment it gets the HTML, it's there. Right? Over yours is more of a gradual process. The normal way of doing things. CSS top, JavaScript and bottom. So if you can do an early flush, if it works for your system, you're a back end intensive system. Do this. Yeah. I have a question. In jQuery, there are elements being done. But if it's like a live source, then there's a way to do this. So, okay. This question was, when you're using jQuery for instance, you have just different browser elements on loan and all these different elements, which you depend on to do certain things on the website. There are many elements in the page. Exactly. So say for instance, you want to change the color of a link item. List item, whatever. Something. So you're actually, you fire this at onload and this is when you go and change it. Right? Now, this again brings me back to whatever saying. Show the things that really matter to the user first. Okay? You would normally do this jQuery thing for kind of animations for a much better experience. But if you can actually show it in one shot and then decorate it later, go ahead and do it. And there's no difference to the actual browser performance. Over here, when you do an early flush, the only thing here is it starts downloading early. It's not executing. Now JavaScript is two things. Download, execute. So when you do an early flush, it will start downloading. And it will not execute until you actually call for it. At some point. Right? Exactly. So your jQuery is there. Your lightbox. Exactly. So suppose you have a lightbox and the moment you actually sleep, it will be there. Right? Okay. It's not changing that behavior. What's this changing is downloading of the jQuery itself. Okay. Yeah? So that's where your early flush is. CSS goes out first, JavaScript goes out first. So this works on IE 6 and it works. So IE 6 works for you. It will work anywhere. Yeah. Now, again, this does not mean that you want to implement. So chunk responses have an issue with the fact that if you're a PHP guy or you're a Ruby guy or whatever, and there's some error that happens on your pool. Right? Normally you would do a redirect to error page somewhere in the bottom. Right? See for instance, you have a header photo and in the photo something goes wrong. You do a redirect to error.html or whatever. It will not work. Simply because the HTML output is already being sent. If you look at the way HTTP works, the moment your headers are sent, nothing else can change the response. So you cannot do a redirect after sending the output. And that won't work when you do a chunk response. So what you actually need to do is redirect by a chunk response. So there are all these things that you need to weigh down and think if it works or not. It depends on how your backing system is actually architected. It has to go into design. Exactly. So, exactly. So this is not something that you can go and implement straight away. It needs a lot of research and analysis to how you structure your page, how your backing system generates the response. But if you can implement it, you can see substantial gains. That's what I'm trying to say. So I move on. So the next thing that I want to talk about is asynchronous JavaScript loading and polyfills. So all of you guys wanted to HTML5 stuff. You wanted to have geolocation on the page. You wanted to do all kinds of stuff. Now, IE6 does not support geolocation. IE7 does not support geolocation. Firefox 3 does not support geolocation. So how do you actually give a consistent experience to your users while loading things on demand? So, my favorite library is yepnope.js. You can go Google this up. Essentially, what it says is it tests if your browser supports geolocation. Okay? If it says, you load the normal way of doing things. You call your normal JavaScript. If it doesn't, you actually call a polyfill. Now, polyfill is essentially a raffle for a feature that the browser does not support. So it is kind of like another bunch of code that runs. So you can actually do this. For IE, you can give a different experience. And for Firefox, you can give a different experience. The benefit here is you have no normal stuff to the lowest common denominator. Just because your users are IE6 does not mean you don't give your Chrome users a good experience. So this is what you can actually do with async and polyfills. Now, another step here is I'm sure if you read a bunch of things they say load jQuery from Google CDN right? Or it may say load the Twitter widget from Twitter CDN or whatever, something like that. Now, what happens if Google goes down? Hypothetical situation. You would see the same contradiction that you saw earlier. The page will not load because Google itself is down. I know it's a big ask, but it can happen. Right? So in this situation, what's actually happening is it will try to load from the Google CDN if it does not yet load it. It times out. You actually load from your local copy of jQuery. It's a fallback. Right? So you can do this. All this is supported by the app. So go home, check it out. There's a lot of things that you can do with this to give your users a much better experience. Resource preloading. Now, when you launch a new website you have a completely new redesigned website and today is this dull looking website and tomorrow is all flashy, lots of images of JavaScript stuff. And the moment you launch it tomorrow your users are going to come and say, hey, your site is really slow. Simply because the cache is not filled. It's fresh content. You have to pre-launch, so you have fresh content then. What you can actually do with this is aim for your launch day or meet before your launch day. Start filling the user's cache with your new images, your new CSS, your new JavaScript. So on the launch day you actually have a really fast response. So this is cool. Because today you can actually launch your website and then everyone is calling on you and say your site takes like 5 seconds to load. But you can actually preload all this the week before your launch. The user gets a really good experience. So again, how do they get that into the cache app a week before? So this question of how do these preloaded resources get into the cache is simple. The browser starts downloading an asset will get cached. So in this situation in this situation all it's doing is actually downloading jQuery and keeping in the cache. Sometime later you actually reference this file is there in the cache. That's all it's doing. So the key idea of all these things that I talked about is download all the scripts in panel as soon as possible and execute them in the order that you want. So I am saying week after download execution. They are two different things. Don't do at the same time. Okay? So I took the async javascript loading. Yep, no supports it. And I took it on the same sample that I showed you, my 85k website and see how it looks on that. And here there's not much of a difference. Like a second difference still pretty good performance improvement. If you have a website that is intensive on javascript and CSS this will help you. Now this is a very simple website. It's the landing page. There's not much happening here. But if you are this huge portal this will help you a lot. So you can try and do this. Again, I am not actually going to the code and see how this works. I am just giving you some kind of reference so that you can go back and play around with all these things. Right? So the next thing that I want to talk about is Google Speedy which I know most of people here are there for the same reason. And nobody wanted to need to talk about all this bullshit that I talked about till now. Half the people in this room are probably there for Google Speedy. So I am just going to straight jump to that. So Google Speedy is a fancy little thing from Google. They call it HTTP 2.0 stepped up from HTTP 1.1. So what it actually allows you to do is all jargon here. Multiplex streams essentially using one TCP connection. So if you actually look at the classical way of performance, they say have a CDN and then call it cvn1.xyz.com and cvn2.xyz.com you shard your resources. You load cfs from one domain, you load cfs from one module. The reason being the browser can download them in family. Okay, this is a hack. It was there because at that point in time we didn't have all these cool little things and now it's there. So everything can happen on one single TCP connection. The advantage being you no longer have to have this issue of TCP or TCP slow start. Essentially TCP when it starts off, it takes lower bandwidth and progressively increases the bandwidth capacity. So you actually have a much higher chance of getting a full use of the bandwidth available than just throwing out multiple TCP connections. So Google Speedy actually does that. Then it does request prior derivation. Simply meaning css is more important than javascript. You need css to show what's on the page. Javascript is for the behavior. It's okay if a lightbox doesn't load but it's not okay if the colors and the layout is all messed up. So priority. css gets more priority than javascript and you can actually define it yourself. You can say jQuery is more important than some of the lightbox code or whatever. You can actually define it. So the browser will prioritize your request depending on its bandwidth, network resources or whatever. Today you have no control over this. It's just random. This will be allowed again. Now better competition may not make much difference. Every time you hit a request to the server, there's a request header and there's a response header. Now this is like a whole lot of text which goes in the browser and all those kind of things. A lot of text is almost like 10kB up and down. So it actually compresses that to almost 85% of the text. So it's like 15kB or something. It does that. And server push. The server can actually push things on demand. This again goes like to me saying if you have a new website launching, the server has a control now. It's no longer your asynchronous fnote.js preloading things. The server can say next week I'm going to launch a new cool website. Put all this on the client side. Put it there. That's what I was talking about. When I was talking previously, I was talking about it being on the client side. Client essentially knows that you're launching a new website. It does not make sense in the real world but you as a web developer knows that new launch is coming up. You push things ahead. But over here you're the server. Then you can actually push things to all your users without them having to ask for it. It's a difference right. So Google's media allows you to do that. So Google did some tests and even we did it. So and we actually found that Google's PD on a very intensive resource intensive website can actually show you somewhere between 45% to 55% improvement. Essentially halving your load times 5 seconds is 2.5 seconds. 2 seconds is a second. You can do that. Now this will not again work for all the websites out there. It will work on websites which are resource intensive. Meaning websites which are more like Amazon and eBay and you know which have a lot of images and all these kind of things. It will work there. It will give them a substantial gain 50% or whatever. But if you're a small website you can still see 10 to 20% improvement. Again my point being just because of the fact that you're using speedy does not mean you see a 50% improvement. Again it's not a silo bullet but it will definitely improve things. And today there's not much of a browser support to it. It's just Chrome and Firefox 11 plus bit supports. But this is under review by IEDF. So they're actually looking at making this the draft HTTP tool or no. So things will definitely improve. Maybe by the end of this year or next year things might be completely different. Okay. So this was about speedy. Now how many of you guys have actually used Firefox or Chrome developer tools and run by slow and speed speed and all those kind of things. It gives you a nice score. It says your by slow score is 80 or 85 and then you go hell breaks lose. You go on optimizing if you get a 95 by slow score and you're happy. Right. You say I've done my optimizations done. But in the real world it's not the same. Right. Again this may not apply to everyone over here. If you're a big company if you have a lot of traffic on your website start monitoring how it is for the user. That's real user monitoring. Okay. So monitor and production. Don't run your by slow scores and be satisfied there. Actually go into production and capture metrics from there and then see how it works. Reason being this okay. Now this is what happens when you hit yahoo.com to what in the end. There's so many steps involved. Most people don't even realize so there's DNS issues cache issues, proxy issues your JavaScript execution issues and browser issues and all those kind of things that come up between your and to the on-load event. Right. There's a lot of things that happen. Now your by slow score is on your local machine it gives you what it is from you as a user. What's the perceived performance. Right. But in the real world you have a lot of things that come up in between. Somebody might be on BSN broadband and somebody might be on some weird internet connection. Right. So things are different today. Now how do you optimize somebody might be on a really good fancy browser like Chrome and somebody might be using an old browser. Now the fact is you as a website owner you cannot say that I'm going to ignore IE6 guys or IE7 okay ignore IE6 but at least don't ignore IE7 and IE8 because there's still real world users. Right. So you cannot just so you need to understand how is your application behaving for all these guys in the real world. How are they impacting people in India and how is it in China or how is it in US right. So you need to capture all these techniques and that is how you go to the next level of optimization. You will automatically figure out what works in the US, what works in India and you can optimize your application on a geo-specific way of doing it. So to this I would actually recommend a tool called Boomerang by Yahoo. It's a simple JavaScript code and when you do that it has like a beacon. It sends by radar through some server and it sends you all this. It tells you when your document complete happened, your response times, your time to cause bite, your DNS issues, whatever. It tells you all these things. Sends it back to your server. You can do the crunching you can do the analysis. Now if you're not someone who has the capacity to run this kind of system I'll talk about that. So why get real world data? You need to get across geographies, browser types that I talked about and you can actually roll out and optimize this specific to a region. So we do that a lot. At eBay, in the US you have you're actually near to the eBay servers so things are much better if you're in the US. But the moment you step out and you're actually hitting eBay India your server response is coming all the way from the US under the oceans. It comes finally to India. There's a lot of latency there. So that happens right? So you can actually optimize. So we have local CDNs in India which kind of delay this I mean improve the performance. How do we know on this? Simply because we actually measured in the real world we found that Indians have lower I mean much worse performance than the US users can be optimized for them. Right? This is not your Weisler score. This is actually real world data. So if you do this kind of monitoring what kind of things can you actually be tracking? Get the geographic information. Very important. Get the performance in India, get the performance in the US, get the performance in Europe, Japan, whatever and then get 95% 90, 75 and 50% load times, percentile essentially meaning 95% of my users see the website in 5 seconds. And 90% see it in 4 seconds. Point here is 95% is supposed to be your highest load time, your threshold. If you have a business which says my deadline is 5 seconds 95% of your users should be able to see within 5 seconds. And as you go lower, 50% is probably your Chrome and Firefox users who have much better browsers target a much lower load time. So maybe 2 seconds 3 seconds. So capture all these metrics from your real world data and see it should be decreasing down as you go down 95% users should see 5 seconds 50% should see 2 seconds right? So capture this data get the browser info, what version of browser what, blah blah blah whatever okay? And the DNS Now if you cannot use Uber IIM or you cannot use a bunch of other open source tools in this case. You can actually use Google Analytics it has a paid speed tracking tool you just enable it, it actually captures speed metrics for you. It's a simple JavaScript snippet again or you can check out New Relic which is another commercial solution it's pretty good, you can even try that out right? I'm just wrapping up. So how do you actually improve the performance? Play around with all these things emphasis on play around and not implement all this okay? Play around, figure out what works for you, change things and go down to production measure it there and see if it works if it works, good, otherwise don't look at your vice-versa course and be happy, okay? Again basically tell you the pain of your users don't make them wait 5 seconds to see your website, make it as fast as you can possibly make it and give them an insanely awesome super experience so there's a lot of stuff happening in this industry performance even though it sounds like a really small thing to do, there's a lot of research going on, Google's PD is probably the biggest well-known solution here but there's a lot of things happening in this space, great Twitter great blogs, you have a lot of stuff you can find a lot more on this you can reach out to me, again, by your information I'll share this slide later so, questions you first want to relate to the monitor so as I've written to you, my question is the part, whatever kind of device you want to resume what else can help with this deal with the monitor? right, so this question is apart from the data that Vice-Log gives you and the optimization, it suggests what extra benefit do you get out of the real user model now, this is actually I'll try and give you a good use case here, so at eBay, we actually had this issue where in Israel there was this proxy server sitting there so when a request comes from the US, it takes that request it passes through that proxy and comes to India or wherever, APEC, right and there was something wrong with the proxy we never knew, right, because of the fact that it was entering this network there was a lot of latency and simply because we did real user monitoring we actually found out people the users who crossed that proxy and beyond get this low performance, we actually figured out that issue is the proxy itself and we changed our networking to the fact that it does not go that good right, so all these things are only possible when you do a real user monitoring this may not as a front-end developer it may not make much sense to be very honest to do real user monitoring but you still want to know what kind of browsers your user use what optimizations you can apply on them and change things again, do not have a least common denominator we are doing things, if you have 20% of your users on i7 give them a slightly lower experience and give the Chrome users a really good experience so that is what you can do as a front-end developer measuring the trade-off between the browser usage and the regional usage whatever and then deciding what needs to be done so real user monitoring so this question is again how do you actually identify the root cause if I just summarize so again now in the internet in the real world there is lots of things that happen between the initial request from the server i.e. the response, i.e. kind of reaches you if you are in China for instance you have great firewall, actually strip out the main and remote weather and you get this early strip talk version and if you do not do real user monitoring you have no clue what Chinese you will see unless you are in China and you probably are not so again these use cases are probably not coming and applies to each one of those years it probably applies to big dogs which have a global presence but keep this in mind because when the fact is there are business scales and when you move out you need to have this data to figure out what the users actually experience and that will help you in all kinds of courses a root cause analysis will only be possible when you have real data yeah this will be about 25 days so again coming back to CDN and NetConnect so when you do a local machine testing on your browser or your dev box what happens is you probably are your DNS system so you have a DNS cache on your OS it is only cache to be in the same place ok and for instance your browser will have cache but you probably control it by but the fact is this is a start issue to the network the biggest latency on the internet is not your content on your package it is the network so and that will not be shown by netx photo your pi or whatever because you don't have any actual data points so you can use the latency from the server to you but it will not tell you what would a user in India what would a user try next year again this latency really will make sense when you are a global company and also makes sense when you are trying to give different experience and give different outcomes that's all ok it may not apply anywhere we use it a lot so you can start logging from the server to the website and it will see whether you have a question or not so he basically said the same thing if you actually capture your latency from the server you can actually see the conversion from home page to checkout to complete the transaction so all this is again here monitoring is 24-7 that's it when it comes to mobile there is a completely different way of optimizing things it is mobile Safari on the iPhone if the file size is beyond 25k the Safari is now going to be the same so that has a completely different solution you cannot generalize desktop for this mobile I haven't done much research on this but the fact I know is when you give me a mobile browser there is a lot more networking if you value a piece for instance so network plays a much bigger role there and the source size the captioning of the source is also very very important desktop almost pretty much captures everything that's 200 but a mobile browser does one so you need to again architect with application in a way that works I don't really have any insights on this ok, practical implementations it's lying on Google and Twitter today we did a pilot at eBay it was there for like 2-3 days switched on speedy for a while to see how it was working at eBay we actually saw on the home page, the listing home page we actually see an improvement in response time 40-50% on eBay home page which is a huge thing for us today it's just on Chrome and Firefox not a big deal but we are actually thinking of going live with this because even in these 25% of users which are Chrome and Firefox today if that results in a higher conversion for us it essentially impact the bottom line so a lot of companies are rolling out by the end of this year we are looking at supports from a lot of browsers so this is essentially a chicken and egg problem CDNs and all the other network players supporting it but a near also things will fall in place and you will see a lot of production use but you can still go ahead and deploy if your browser does not support speedy it will fall back so which is cool you are going to have to worry about it what do you guys see the difference so this question was different between so Google is the ancient proposal of speedy but Microsoft came up and said let's have some good fixes to this and they said this is my implementation I haven't again gone back and studied all this but the fact that from our analysis we feel that speedy understands today Google's implementation is really good because of implementation will add a lot of value they talk to mobile much space on that and much research simply because on mobile you don't do a web presence we actually have native apps so we are not really concerned with that hardware in business so that's something else for the community to go and figure out how speedy works in the required space and how do I get to comment there the way it is right now it will include things by a bit on speedy network bandwidth things will automatically improve today you have to look at the final request all of them are easy to slow start and the network itself will be very slow which is much higher speedy will obviously include things to what extent