Placeholder Image

字幕列表 影片播放

  • 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.

PAUL: Welcome to this session on Performance Culture.

字幕與單字

單字即點即查 點擊單字可以查詢單字解釋

A2 初級

Google I/O 2014 - Perf文化 (Google I/O 2014 - Perf culture)

  • 69 13
    Hhart Budha 發佈於 2021 年 01 月 14 日
影片單字