 Hi, everybody, we're back. This is Dave Vellante, wikibon.org and this is theCUBE. We're live at Velocity here in Santa Clara, California, O'Reilly, Media's Web Performance Conference. Colt McCandless is here. He's the developer advocate at Google and an avid gamer. Colt, welcome to theCUBE. Hey, thanks for having me. I really appreciate it. And a hoop fan. We were talking about being a big college hoop fan and of course we love sports in theCUBE. We can talk about that all day but let's talk a little bit about what you do it. At Google, you guys obviously, big outreach to the developer community. You're always at these events and making a lot of contributions to the community. So talk a little bit about your role there and we'll get into it. Yeah, yeah, absolutely. So I'm the team lead for Chrome Games Developer Advocacy as well as performance in that avenue which basically means I sort of sit in the gap between external developers and our internal engineers. I mean the web is a very complex, a very technical stack and really it takes a lot to understand it especially when you've got hundreds and hundreds of engineers making code changes every day, right? So basically I act as a filter between the two. So I get a chance to work with a lot of external partners, find out a lot about your product, about how your company works, figure out what your needs are. Then I get a chance to go back to our engineers and make sure that the fixes you need happen, right? In the same regard, I get a chance to actually look at your stuff and figure out if you're doing things that may not be optimal or figure out how to fix your pipelines. So talk about those constituents and the Venn diagram. Where's the dissonance? Where are the similarities and where's the differences and the friction? Yeah, I tell you, that's the hardest part of my job, right? Really is translating where the internal engineers are pushing the web forward, right? And where we're seeing sort of the external developers try to push their version of the web forward, right? Because everyone's got a different vision. We'll get a lot of requests sometimes that ask for certain features that would definitely make a huge impact to this one developer but may make the rest of the tech stack completely unstable for the millions of users that use Chrome every day. And so we kind of have to work with each of these developers and figure out what the right median value is to figure out what we change, what we add, how we fix stuff, right? And that's kind of one of the reasons that we love velocity conferences. We come here every year, we talk to the best and the brightest about performance and we sort of set our course based upon a lot of the feedback we get from these conventions. Yeah, I mean the web's not that old but it's getting older. And so the point is there's a lot of code out there that people just don't want to rip and replace and your engineers could make it, you know, a perfect world. They could just start with a blank piece of paper. So that sounds like that's one of the big challenges you have is helping fuse those two different perspectives. Yeah, and I think the term perfect world, you said, was great because everyone's got their own perfect world. And you know, recently we just announced the movement from WebKit to Blink. And that was kind of one of our steps, that direction, right? We definitely saw that the web was working in one direction and there was a lot of technology and a lot of legacy decisions that were made with that. And we kind of looked at where we wanted Chrome to go and where we wanted the web to go. And in order to get there, we had to fork, you know? So when you guys see a fork in the road like that, how do you communicate to the developer community to sort of ease that landing, if you will? Yeah, really it's a multi-tier process. The first thing that usually starts with is this the right decision? I like to say this story to people. People come to me all the time at these conventions and they say, you know, hey, I've got this great idea. It'll change the world. Why don't you stupid people at Google just do X? And I have to assure them. I'm like, that's not the problem. The problem is we have thought of it. Hundreds of people inside of Google have thought of it. We're just still debating it, right? And that's sort of the thing is a lot of the times when we make these decisions, we've had hundreds of thousands of man-hours debating it, testing it, writing test cases, doing proofs and logics to figure out if it's really the right thing. Because when you make a change that's significant, it impacts hundreds of millions of users, right? And that rollout process definitely starts with guys like me and the developer advocacy group starting on the front lines with our Premier partners. So talk about that a little bit more because it's not just the technical decision points, right? There's a lot of other factors involved. What kind of things do you guys consider? Yeah, absolutely. So if we make small changes like that, that could affect how a product may work live, right? So let's say we just randomly make a change and all of a sudden a very popular shopping website has a weird CSS tag that manipulates itself differently and all of a sudden they're getting glitches on the screen, they'll see their user traffic drop, right? And then they may not get pings about the problem or understand what's going on, but effectively our small change could have big effects on their business, right? So we have to kind of be this not only gardener, but also groundskeeper to make sure that we're doing the right thing with these technologies. Yeah, it takes them time to figure it out. Yeah, yeah, exactly. At cost to them and cost to us. That's the last kind of ripple effect that you guys want to cause. All right, let's get into the gaming a little bit. All right. So talk about a game, you talk about the gaming division. What's that all about? What's kind of state of the art in games these days? Yeah, so I specifically work on the web gaming side of things, right? We definitely believe that there's this boom of technologies that have recently hit the web that allow you to get very interactive, very graphics quality, really amazing, fun games inside of your web browser, right? And of course this means this is no download, no install, right? This is one click, play the game, browse away, come back later. And the really cool thing about these games is that they're very social, they're very interactive, right? And they run on your mobile, they run on your desktop and they run everywhere, which is sort of the promise of the web, right? If you can get these technologies working in the right order, you can run it across all of your devices. You don't have to worry about uptime, downtime, installs, how much RAM you have left. You know, you click a link, you share it, it works. Yeah, so you're giving a talk at the show today, right? Yeah, absolutely. It's afternoon at 3.30 Pacific time, so check that out, you guys. I don't know, is O'Reilly live streaming the talk? So I'm not sure, I know the keynotes are, but you know, check out the O'Reilly velocity webpage for that, obviously check out the cube. But so, talk a little bit about what you're going to talk about. I read the description, but give us a little bumper sticker. Yeah, absolutely. So one of the largest changes that browsers have seen over the past year or so is the increasing usage of the GPU to handle rendering of your webpage, right? So a lot of developers focus a lot of their time with performance on just the network side of things, right? They figure out what their page weight is, how long it takes to get first paint to screen, and they really neglect this other side that is once you have the user, what's the experience like for them on these devices? And what the talk about today is going to focus on is how Chrome has implemented the GPU into the rendering of your page and the experience that your user gets, and some of the pros and cons of that trade off, and more importantly, how you can use the CSS tags the right way so that your site is always on the cutting edge and always front and fast and user responsive. So how does injecting a graphics processing unit into the whole equation affect how you design web apps? Oh yeah, so the main thing is that you have to understand very, very at a high level is that the way that Chrome and most web browsers render your page is with a CPU through a system called software rasterization. Basically this has been around since the late 80s to do all of our graphics, any UIs, operating system, it all used to software rasterization. Of course this is a little bit slow, right? I mean that's why we invented things called graphics processing unit, GPUs. GPUs were sort of invented the early to mid 90s to handle things like CAD operations and video games. They're built to handle hardware rasterization. So they do the same technique, but they have dedicated silicon to make it amazingly fast. So what we've done in Chrome is we've effectively injected the GPU into the way the rendering pipeline works so that you can actually use it to your advantage, which means that there's some things you have to change. Anytime you get items on your page which may be moving in relation to each other, so you have a static fix or an overflow scroll, things along those items, it's actually going to change your performance profile the way this is working. And so by adding a little different CSS tags to it and using some different properties, you can actually speed up your site two to four X by including the GPU in your rendering pipeline. Okay, so that's an example of some best practices. What other kind of common mistakes do you see out there that you try to advise developers to move forward on? Yeah, so this is a big thing, right? We've been talking about performance, especially here at the Velocity Conference, but over the past couple of months, we've really harped down on this, is that it's a three-pronged approach. You definitely have to worry about network performance, render performance, and compute performance. And each one of these three pillars kind of has their own unique taste on things. You have to solve a problem a different way. For example, rendering performance, you may know in many of the web development community have found this out. If you add a single CSS property known as Translate Z, it'll actually auto promote something to its own layer so the GPU can accelerate that. Well, unfortunately, if you use that on every single element on your page, you're actually going to slow down your performance because all of these layers are going to be fighting for residency on your GPU, and that's actually going to cause the CPU to do a lot more painting information. I'm going to dig deep into this today in my 330 talk, but that's just one of the examples, right? Another great thing that I like to tell developers to definitely watch out for is how you're using your memory with your JavaScript operations. A lot of developers like to do things like pass anonymous functions enclosures to their set interval timeouts. Well, what they don't know though is when they do that, they're actually leaking memory, right? So when Chrome's V8 comes through, it'll actually compile that operation, turn it into optimized code, and then the next time that set interval pulse occurs, it does it again, right? It doesn't have a resident handle to that sort of amorphous function. So effectively, every time that calls, you're leaking this big stack of data, and it's really easy to figure out that this is a problem. You open up DevTools, you look at your memory heap and you see it just keeps growing and growing and growing, and you know that something's going on there, so. Yeah, excellent, now, let's see. Let's talk about mobile a little bit. That's, you know, somebody, an earlier guest, that, you know, think about it, your smartphones weren't even around a couple of years ago, just two velocities ago. They really weren't programming to iPhones, but so overnight, you know, things have changed so dramatically, you know, Android has taken the world by storm. Talk about how mobile has affected, you know, your world. Yeah, I tell you, this is one of the big competing points we're finding with developers right now, is that mobile performance hasn't been where it's needed to be, and I think we can all agree on that, right? But it needs to get better. And what we find that because of this historical average, I mean, you saw about 2009, was really when the smartphone boom happened, and it took a couple years for us to really realize what that meant. And now, on the web, you start seeing tons of websites that you go to on your mobile devices, asking you to install their native applications. And the reason for that is because of performance, right, these web developers, traditional web developers, are finding that they can get better performance on native. But there's a reason for it. But there's a reason for it. And the truth is that now, you know, 2012 or 2013, even, sorry, I'm even a year behind on my own talks. In 2013, we have so many new technologies that have changed the landscape. I mean, Chrome coming to mobile was huge, right? We saw websites that were rendering at maybe five frames a second, 10 frames a second with the previous browsers, all of a sudden getting 30 and 45 frames a second just by using Chrome, right? So the truth is that these things are changing. Performance is getting better. And I wouldn't be surprised to see a lot of these web developers get rid of their native apps over time and come back to these web applications. Because of course, it reduces the amount of code that they have to maintain. It also reduces the surface area that the users have to worry about. Because a lot of time, these native applications just have completely different UIs and just work differently and oddly. So fixing that performance is the number one step to getting us back on the web. That's something you guys are really pushing for. Yeah, absolutely. Simplify people's worlds. Yeah. Okay, so let's talk a little bit more about the web performance. We heard a presentation this morning from Google. We're putting up some evidence that the web is getting faster. Networks are getting faster. Pages are rendering faster, et cetera. So talk about that a little bit and then talk about where we need to be. Yeah, I thought the talk today was great. I mean, we've got a lot of people at Google who are obsessed about performance of the web. One of the big things that we're still not focusing on as a web community is emerging markets, though. And I think there's a great book by Eric Schmidt out called The New Digital Age that talks about the next five billion people that are coming onto the internet. And these aren't people that are coming from where we already have connectivity. These are coming from low connectivity areas. So while that talk did show that the internet was getting faster, that's not worldwide. And it's not at the same curve worldwide either. What we're going to start seeing over the next few years is a lot of these developing countries are going to get more industrialized, more internet coming in. And performance for network is going to be huge factors there. I mean, imagine getting millions of people all of a sudden online at once that's a whole new demographic of people at a different connectivity rate than you've ever experienced before. And so developers now have to look at each of their regions and optimize differently because you may be able to actually send a five megabyte website to someone in the Americas, but you can only still send a 700K website to someone in India, right? It's all about connectivity. So if you don't think about that, the whole mix is going to change. Yeah, absolutely. And really dramatically impact performance in a negative way. Absolutely. Yeah, we heard the average page size is what, 1.5 megabytes today, is that right? Yeah, exactly. It's probably larger in your world. Yeah, for games, for games we're up in the 50 meg range, which definitely puts a hamper on HTML5 games in some of these emerging markets. But that's something we got to fix. I mean, really, the web is forcing us to think like a global developer in a global economy. And that's one of the great things about the web. It's everywhere, right? You got a plan for it, but it's everywhere. So tell me what else is exciting you sort of at this show and then we'll wrap with the last question. Yeah, absolutely. So one of the things I love seeing here is really how many people have started taking their own twist on cloud, right? I walk around the booths here and I'm actually seeing like, here's our cloud and here's our cloud and here's our management and here's our data. It's really interesting to see just so many different takes on the same architecture, right? Because, and I love that. And the reason I love that is that when you start getting this melting pot of ideas and enough startups start popping up, you know that we're not done yet, right? Like if you just have one monolithic system, you're done, right? And when we start seeing this competition and these different ideas, man, that's just fuel for awesome. And that's what I really love seeing here. Yeah, so I said one last question, with the cloud, the whole cloud discussion, I mean in a way the cloud sort of simplifies application development because you can just put everything in the cloud and you get world class resources in your fingertips and then all of a sudden there's hybrid clouds and security issues and everything else. But I think you're right. I mean just the diversity of what people are even calling cloud has changed quite dramatically. Okay, so what should we look for, you know? Let's say we're at a velocity, you know, year from now, maybe even two years from now. What's the world going to look like, you know? Put on your crystal ball and what do you see coming? Well, I definitely see over the next 12 months that there's going to be a lot more discussions about client side performance ramifications. If you look at the talk list for yesterday, today and tomorrow, you see a lot of it's still about network and about how to transition these things in security and cloud and there's really only one or two or three talks about client side performance, right? What we're going to start seeing is as those cloud issues start getting a little bit easier to deal with and a lot of these vendors here start getting their software out there that we're going to realize that getting 60 frames a second on mobile devices for client is actually the biggest problem we have now, right? Getting that scrolling speed working, having a user touch a button and feel interactive and bumpy. We really don't have a good representation of those performance issues at these conferences. That's what I think is going to be the next big challenge for web developers. Client side mobile web performance is going to be the big challenge. Yeah, so you guys are working hard on that problem. You're making the web faster, but as we talked about, it's not fast enough. Yeah, we got a lot of work to do. Excellent, Colt McKinnell, excellent guest. Really appreciate you coming on theCUBE. Thanks very much. It's a pleasure meeting you. Appreciate it, thank you so much. Keep it right there, everybody. We'll be right back live from Velocity. This is theCUBE. This is Dave Vellante. We'll be right back with our next guest.