字幕列表 影片播放 列印英文字幕 PAUL: Welcome to this session on Performance Culture. I am Paul, on the left there. I work on Google's Developer Relations team where I spend my time looking at performance, design, and UX and normally where the three of those meet. LARA: And I am Lara Swanson. I work at Etsy and I'm the Engineering Manager for the Performance team. We help all of the feature teams who are building products or features or experiments, make sure that whatever they're shipping is as fast as humanly possible. PAUL: Alright so, I guess the opening question is, why are we even talking about performance cultures? Why does this session even exist? And I think to answer that we need to understand a little bit about where our industry is and what we are seeing and where we think it's going to go. And it's really about this. The multi-device web. We've seen more devices than ever before come online and I think really the one that stands out for me the most is this one. It's the smartphone. It represents the most performance constrained device that we have. Whether that is in terms of the screen size, or the GPU, the CPU, or its connection to the network. And the thing is more and more people are using smartphones. In fact, one study suggests that just over a third of American adults use their smartphone as the primary means of accessing the internet. Which means for those people their first experience of you, your site, your brand is going to be through their smartphone. And that is something that we need to be thinking through. In fact, it's not just in the States it's also globally. So, here we have the percentage of total global internet traffic according to Stat Counter and you can see that the trend is pretty clear upwards. And it looks I think sort of the middle of next year, if the trend line is correct, that well cross that 50% marker. So the thing about this is-- LARA: Mobile networks can add a tremendous amount of latency. So, before a mobile device can transmit or receive data it has to establish a radio channel with the network. And this can take several seconds over a 3G connection. After the device talks to a radio tower to negotiate when it can transmit data, the network carrier then must transmit that data to its internal network, and then to the public internet. So, the combination of these steps can add up to tens of thousands of milliseconds of extra latency. So, the most important question I hear when I say this is, well what about 4G? 4G is awesome right? Our networks are improving. But you have to remember the new device and fast network with an excellent connection that you have in your pocket right now is not a good representation of what your end users are really experiencing. So, while it's true that networks are getting better you need to remember that your users are on a variety of connections, with various levels of connectivity, and latency. It's also important to remember that if you're a site is slow people will go elsewhere. In fact, one study suggests that as many as 40% of people will leave a site when it takes longer than three seconds to load. So, we have some options. In the face of the stuff that's a little bit scary what can we do about it? The first option is to ignore it. You can certainly say, you know what we just saw those awesome stats. We say that we're actually-- we're trying, but we don't think it's that important. Maybe mobile isn't the future, maybe that trend line is going to lie to us, maybe networks will be better immediately, I don't think that this is true. PAUL: No, I tend to think-- no. LARA: I think that we can't just ignore it. PAUL: I'd like to. LARA: Yeah, it'd be really cool, but I think the other option is to assign performance cops. Right? Who in here would identified as a performance cop or janitor within their organization? PAUL: Anybody ever been one of those? LARA: Yeah, somebody who comes in afterwards cleans up. PAUL: Look at these hands. Look at this. [DEEP VOICE] Yes that's me, I don't know. LARA: So, performance cops, right? We come in and we say, hey designer, hey developer here's some better ways you can do this. You come in cleaning up after people, you try to make your site better, but the responsibility solely rests on you. And this can often lead to a tremendous amount of burnout and frankly, it's not sustainable. There's always going to be new people joining your organization, your site will continue to get slower, it'll continue to be iterated upon, the hardware age, being a performance cop is not a sustainable thing, so that's why we're here to talk about building performance cultures. PAUL: Wow, I wonder which one we'll choose from that list? [LAUGH] PAUL: So, we're all set to build a performance culture, super. But we have to ask the question what do we even mean by a culture. Well I guess you could come up with your own definitions goodness knows there's probably a bunch of them that you could think up, but for us today, at least in this conversation, here's the things that we actually have in mind. Firstly, it's a way of saying, I belong to this group, I get them, hopefully they get me, I understand this particular group. So, for example being British, I would identify with British culture. LARA: You're British? I know right it's a relief for anybody in the room going, where is he from? His American accent is really strange. LARA: [LAUGH] Yeah, I know. So, it's that first and foremost is just saying, yep this is my kind of people. It's also about how you think and how you reason and rationalize the world around you and the kind of social cues that you look for or the slightly strange obsession with green liquids you may or may not have, but it's that sense of the world around you. It's also how you do things. Whether that's the side of the road you drive on maybe the wrong side, the words that you use for things or perhaps in our case how we go about crafting the code. And then lastly, it's how you celebrate things, the things that are important to you, the things that you celebrate and how you go about celebrating it is unique to your culture. And we see cultures at the highest level internationally, nationally, all the way down to our homes and so forth, and actually of course, our workplaces, which brings us back to that whole performance culture thing. LARA: Yeah, we were joking when we were talking about earlier that performance cultures are kind of a team sport. It's important to remember that everybody has to play. And as you say about sports there is no "I" in performance. PAUL: That is true, but if you're willing to look hard enough you'll find there is "prance-for-me". You can stop the slide now. LARA: Alright, alright. So, thank you for that. So, culture change is scary and it's hard and I can understand especially for those of us in this room, we don't know necessarily how to approach it. How do we start to create or enact performance culture within our environments? I'm going to go through some real things that have been said to me as I've gone on this journey within the organizations I've worked in. Lara, "I don't want to think about mobile." Right. PAUL: So whiney! LARA: Yeah. "Lara, I'm a project manager or a product manager and I've look at the deadlines, I've got some resources and frankly building for both desktop and mobile is going to take twice as long." [WHISPER] It's a lie. "Lara, you at the performance Manager, don't you know responsive web design is inherently bad for performance?" Or my personal favorite, "everything changes too fast!" So, here's the thing we've been through this before and when it comes to web development we've gone through these kinds of change the past. Who here has built sites with tables for layout? Yes. PAUL: Yes! Look at all these guilty hands. [DEEP VOICE] I don't do it any more. LARA: It was a pain. So, at probably every job I worked at between 2006 and 2010 I remember these arguments, do we have to move to a CSS based layout? In fact, we did. We did it pretty successfully. This is more like what we would use today, as is actually said to change again with web components. Who has heard this from a very important person, excuse me, the important part is not above the fold. When the EP's would have to scroll to see content. Yeah. This is again what we're seeing today. We used to worry about 800 by 600 pixel monitors, now we're worrying about the spectrum of screen sizes. This graphic represents all the devices that come to ETSY.com that have more than 1,000,000 visits per month in traffic. We're no longer seeing just handsets and tablets and desktops we're seeing a spectrum of screen sizes. You may also think about how we've changed developing for different browsers over time. I remember back in the day we would talk about cross browser compatibility or making things look the same across browsers. Browser hacks, prefixes, et cetera and this is again what we're seeing today. We have to start thinking about mobile web browsers in addition to just our desktop clients. But this is all to say that change is scary, but it's also constant in our industry and it's good. This is a good part of our jobs. We've lost crazy table layouts and now we have semantic markup and more people than ever before can use our sights on our apps. This is good for us as developers and it's really good for users. PAUL: So, we need to embrace change, good, fine. So, where do we start when we want to create one of these performance cultures? Well, the first step for us is to actually gather some data because essentially you don't know where you're going if you don't know where you are and you need to understand how real people use your site, like what devices are they on? Where are they in the world? What journey did they take through your site? Which pages did they arrive on and which ones did they leave on? You need to understand your own situation and if you don't know today you can't start telling that story to the people around you and get them on board to build this culture with you. So, the immediate thing that springs to mind is just going and have a look at your analytics. Go and look at Google Analytics. Figure out what it's telling you. Spend a bit of time, make reports, and start to get that sense of where you're at. The next thing you want to do is actually look at you load stats. So, how long does it take to load it? How long does it feel like it takes to load your site? Again this is coming down to the data that you can share, but it's also in this case coming down to a little bit of empathy as well. How does it actually feel to be one of those people that's using your site on a day to day basis from somewhere else in the world. And for that we can turn to Web Page Test and you can ask it to load your site from a range of locations, a bunch of devices, and different connection types. And it is going to give you a load of really useful, really amazing data. And one feature I particularly like is the ability to compare pages, so you could take for example your own site and oh, I don't know, the site of your co-presenter and see who's fastest. LARA: Not cool bro. PAUL: Oh yeah. I actually did that, as you can see and depressingly it's a draw. So, yeah. Could have been bad, but it wasn't. I'm sure you can start to see how you could start figuring out the story here. Like how does it feel to be one of our users when you compare it to somebody else in the world or-- da-duh, da-duh, da-duh you get this idea. OK. So, you start to get in this insight and you don't even have to leave your desk. That's the best bit. But we can get even more data at Web Page Test and we can share that with our team. Like how long does it take before our server sends some data back or how long before our pages start rendering? But one number I want to call out is this, which is the speed index. It's a bit weird the way it's calculated. You can click on there there's a link. And you can click on it and it will tell you, in all the gory detail, how it figures it out and it's pretty cool. LARA: It's magic. PAUL: This is magic. But it is a really good number for figuring out in milliseconds how long it feels like it takes for your page to load. So, that's a really good measurement, better than say, the onload event. But speaking of perceived performance, we don't just want to stop caring when people-- when they've landed on the site and we go oh, what have we done. We need to care about scrolling and animations and interactions and they all need to be this silky smooth 60 frames a second because people care about that. They want that feel of responsiveness and smoothness. Again you go to like Dev Tools to look at your pages for data and figure out what your frames per second is like. So we get frames per second, we can dive into the frames a little bit there and find out where we've got issues and then start fixing them. Now if all that's new to you it's time for a shameless plug, which is to say I've got a session tomorrow morning that will tell you exactly what you need to know about these tools, "The Tools You Need to Succeed." It rhymes, it's true. So, come to that if you're interested. Anyway, hopefully at the end of this situation we have a load of information, we have a lot of data, and we're starting to hopefully build this story in our heads of what it feels like to be one of our users. LARA: So, you've got this data and you're excited about it. What do you do with all of that excitement and all of that data? You should go talk to some very important people. You want to enlist the help of the very important people at your company and get them to understand what your users are feeling and experiencing. There are few things more powerful than a very important person saying, this is important. Performance is important. It's crucial to getting others at your company invested in performance. So, what can you do to make this happen? Here's an idea that we came up with, you should send your very important person one stat a day for two weeks and see how long it takes before they cave or just get really annoyed with you. One that we often like to cite is this Google study that found an additional 200 milliseconds of delay triggered a 0.3% loss of engagement. You may say to yourself, 0.3% is not a lot, but Google is pretty popular. So any kind of loss of engagement is going to have a huge effect. Or remember that old stat that we just had where 40% of people will leave a site that takes longer than 3 seconds to load, tell your very important person that stat and say, by the way our takes 5 seconds to load on a 3G connection. So, after the stat thing has run its course consider running some experiments. Measure the business impact of these experiments. Know what kinds of metrics your very important person cares about. Maybe it's balance rate, maybe it's conversion rate, maybe it's something else. Go ahead and run performance experiments and see what the effects are. On Etsy, we ran an experiment in which we added 160 kilobytes of page weight to a page on a mobile device and we saw that it increased mobile bounce rates by 12%. This is the kind of thing that we can share with the folks at Etsy and say, hey, this stuff is important look, at the effects that it has. However, this is kind of a negative stat and I kind of prefer to make a positive. So, what we found when we eliminated jank, that's that scrolling issue, when we eliminated jank on Etsy's activity feed we saw people "favorite" more often, and "favorite" more items. And this is another kind of experiment that you could run, make something better and measure the effects before and after and pick and choose the engagement metrics that you know your very important person is going to care about. You could also use that web page test film strip, thanks for that-- PAUL: Your welcome. LARA: --and take the video output and compare that before and the after the experiment, make an improvement, show how slow it was before and show how long-- how short it took afterwards. And get that person to care and feel about how this works. Or compare your site on desktop to how it loads on mobile or compare you're site in the United States to how it loads globally. Get your very important person to see and to feel these things so that they actually care about this stuff too. You want to get them to feel it. Once they understand you can help them empower others. By changing how you're very important people think about performance it will help everybody who's surrounds you. PM's, designers, developers care and work on performance. PAUL: Speaking about those other people, so, we've got data, we've got our VIP's to say, OK performance is important, we see that it's got real value. How do we then make it so that the people around us can actually-- start actually taking this and using it. Well, the easiest way is to educate them through something like a brown bag, lunch and learn session on all the tools, all the data, all the things that you've figured out about how you're actually doing. And it's not-- as we said it's not just developers, it's designers, is UX, it's project managers, it's anyone who's involved in what you do because it's a team sport. And we want to make sure that the people that we're working with know the impact of the decisions that they take, so it's not the case of, well the developers have done all they can, but actually the problem is originated from another place. You know if you include everybody you've got a much better chance of success. The next thing that's well worth doing is to start documenting your best practices and start writing things up. Because what gives you is an easily copy, pasteable set up that you have. It makes it more obvious about how to do the right things as far as you're concerned. Anybody who joins your company is going to start figuring out, oh this is how I'm supposed to do things, rather than just having to guess and muddle their way through. And you can use it to show what worked and what didn't work and if nothing else it kind of gives everybody a focal point and say, right this is-- because you will find there will be trade offs in everything you do. This thing and doing it this way works because of this. So it's a really good place to sort of-- it's really good to start writing these things down. Another thing that is definitely worth doing is seeing what you're uses are seeing, which is to say invest in a device lab. And I mentioned this to somebody the other day and they went, "psha $10,000, really?" Because that's what they were assuming it was going to cost. Well first of all it doesn't necessarily have to cost that much. Secondarily, the cost of not testing across multiple devices may be way higher and so, that's something that you want to decide for your selves. But it's a sort of-- it's an out of sight out of mind kind of problem, this one. If you put these devices in front of everybody it kind of gives everyone that reminded that there's this whole range of devices they should be testing on and that they are building for the multi-device web and that they need to care about performance on all of them. It's also a social place as well, so people can meet and gather around these devices and start to figure out together how you can solve particular problems and again that will broaden the horizons beyond just the developers. One thing that is pretty cool out in the Design Sandbox, if you haven't seen it we have a Device Lab. And the team there will talk to you about how you can go about making your own device lab. The source apparently is on GitHub because it does some crazy stuff where it which is to all the devices at the same time, which is really cool. So go and see the Design Sandbox people they will help you. LARA: And then also if you go to laraswanson.com/devicelab you can see all the slides that I just gave for a tutorial on how to build your own device lab. How to choose devices, how to troubleshoot power, and all of the other things that we've learned along the way. PAUL: Awesome. Alright, so, you-- it's great to have the device lab, but it's not great if you don't use it. It's a bit like having a gym membership and they never getting on the treadmill. Yeah. So, make time to actually test your stuff for real. It's good you've hopefully got the VIP's to say it's important so you can say actually we need time now to make sure that things are working well. So go and give your devices a big old hug. Let them know you love them. Like we said earlier though educating your team isn't just about developers and performance isn't just about an internal thing some of it-- sorry it's just not an external thing it's also internal, get that the right way around. It's about everyone who builds for the web in your company. And that means in a lot of ways that you want to eliminate duplicate code, you want to basically embrace responsive. Instead of having a mobile team that does the M-dots and you know the other team that does all the other stuff. M-dot. What do you do for TV? Do you do TV-dot? LARA: What do you do for refrigerators? PAUL: F-dot? LARA: R-dot? PAUL: R-dot. LARA: I don't know. Don't do that. PAUL: No, don't do that. That seems like it's not going to scale well. LARA: No. PAUL: OK, you said earlier they do taxies. LARA: Oh yeah, taxis in New York have the little-- you can access the internet. Mind, [SHOOTING SOUND] blown. Alright, point here is your going to eliminate duplicate code, you going to make it easier for your team to iterate more quickly, hopefully, and start to break down the barriers between you, the designers, the developers, and it just gives you a much greater chance of success. So, in summary, when you've got the green light from your VIP start teaching your team about performance and the impact of their work, it's going to empower them. Sorted. LARA: So, you need to start surfacing performance within People's daily lives. We can talk about performance all day about how important it is and when you ship something new you can see the end of the day how much performance was impacted negatively or positively. But this isn't help people as they're designing or developing. So, the first thing you can do is add performance to your build tools. Automate image compression. Get a command line tool running like Grunt or Gulp that runs performance tests and compares your new work to your performance budget. You could use something like Travis to do the in a continuous integration environment. And these tools can even report back to dashboards, which is my next recommendation. So, at Etsy we look at something like this every time we deploy code, which happens upwards of 50 times a day. When someone deploys something new they'll go over to a dashboard and say, how did this impact performance? It's really important that as people are continually pushing out new work they can see immediately how their stuff has affected it. But also at Etsy we have this tool bar that sits at the top of every page of etsy.com if you logged in as an Etsy employee. And in this we've got information about visitor traffic and experiments, but we also have performance data. So, we surface the timing's for people as they're developing in developing, staging, and production environments. And we also have a clear baseline for what is acceptable. We'll let you know if you're violating one of our performance service level agreements. By surfacing your team's performance data during the workflow it'll help improve their work, it'll become baked into their workflow. They'll start to care about it because they can see how their work directly impacts it as they're designing and developing. And this brings me to our last point. This stuff is going to make people so excited and people are going to ship things that are improvements to your site. You should be celebrating everything. Again, I'm all about the excitement. I'm all about getting people pumped up about performance. PAUL: Prepping the talk with Lara was like an object lesson in excitement. LARA: Nice. So, for me, this is actually the most important part. Back in the day in August of 2011 the man behind the sunglasses, Seth Walker, published Etsy's first performance report. He published it on Etsy's news blog, so it's super public. He chose a bunch of baseline business metrics or page load time metrics, rather and he showed how long are our major pages were taking to load and you can see there's a huge outlier here, the homepage. It was embarrassing, but he published it anyway because this stuff isn't a secret. What's amazing about this is that developers teamed up to fix this. As soon as we publish it, as soon as Seth put that into the world people got excited about it and they wanted to help and they want to fix it. And by the next time we published reports, which was in November of 2011 there was a huge improvement. Not only did the home page significantly improve in page load time. It was the fastest one on this list. So, you should be sharing your findings. Make sure that you're celebrating externally the stuff that you're doing to help improve things along the way, but also as Paul mentioned it's important to do this internally as well. This is an example dashboard that we have, the Performance Hero a dashboard, in which we celebrate engineers and designers who make huge improvements to Etsy's page load time and they're not on the performance team. In this case Chris Fairbanks, who's on the checkout team, eliminated a ton of duplicate code and had what we call a Baumgartner. Remember that guy who jumped out of the hot air balloon and landed on earth? Yeah so every time we have a graph like this-- PAUL: It wasn't a dance move, right? LARA: It wasn't-- no, it wasn't a dance move it was a plummet to earth. Every time we have one of these, a Baumgartner, we celebrate this internally. We put this up on a dashboard and we have that little printout sign, and we hang out with them and we're like, thanks. Thanks buddy. And we want to celebrate the things internally lots of high fives, lots of doughnuts, lots of cake. You should be rewarding your innovators. It's not just about coming down with a hammer. It's not about being a cop or a janitor. This is really about celebrating improvements and getting people excited and invested in their performance. Celebrating wins will motivate your team to be performance champions. So, to summarize gather the data. You want to make sure that you have a baseline of understanding how your users feel. Again, this is all about understanding the overall user experience. It's the aesthetics and it's page load time. You then want to share all that stuff with your VIP's. Get them to understand what your users are really experiencing. Get them to understand what it's like on mobile and globally. Get them to understand also how this stuff impacts the business metrics, run some experiments and share that data with them. Once you get a very important person to say, this is important or just a few find that it's awesome enough to say this is important, educate your team. Do those brown bags and lunch and learns. Make sure that your surfacing that data in their daily work flows. Make sure also-- your celebrating things. Again this is a journey right? You may be at any step in this process and you might have to start again gathering more data, getting more VIP buy in, educating the team again. New designers and developers will join and you'll have to do more brown bag lunch and learns. New technologies will emerge and you'll want to share that data and that new information with them. You'll find new wins and you want to celebrate that stuff. This is a continual journey and continually positive process. PAUL: OK. So, as we said at the start we're in this period of dramatic change where we're seeing mobile traffic go, whoosh straight up, and we're facing this world where essentially we need to deal with these performance constrained devices like building for this tomorrow that we're looking at involves facing that fight and saying you know what most of the devices that people are going to be using are not desktop, they are not powerful devices. The thing is it's not really tomorrow it's kind of now. And that's the thing about dealing with performance is it really starts and it can and should start today, but the only way you're going to get to that point is if absolutely everybody in your organization from the top to the bottom cares deeply about performance and its impact. And the only way you're going to get there is if you start building performance cultures. Thank you. We'd love your feedback. Please do snap the code or take down the URL. And we'll be outside if you want to ask any questions and say, hi. LARA: Come hang out. PAUL: Yeah. LARA: Thanks everybody. PAUL: Thank you.
A2 初級 Google I/O 2014 - Perf文化 (Google I/O 2014 - Perf culture) 70 13 Hhart Budha 發佈於 2021 年 01 月 14 日 更多分享 分享 收藏 回報 影片單字