Placeholder Image

字幕表 動画を再生する

  • everybody.

  • I'm Taylor.

  • Thanks so much.

  • Shooting introduction, Paul.

  • And today we're going to talk about JavaScript performance in extreme environments through the lens of our production Web app for refugee aid groups.

  • Um, so start off with some background on the aid movement.

  • Look at those extreme environments.

  • Setting performance goals is always a great place to start when diving into this stuff and outlining a strategy and then look at the tools and techniques we use to improve performance in our own app.

  • Um, this is my first ever tech talk, both as an attendee and the speaker, so really on.

  • I just want to emphasize like I'm nothing special.

  • Um, I'm just like an average rubbed off.

  • I needed to do this to make our stuff work in the field.

  • But the takeaway from that is that you can do this to you don't have to be an expert.

  • It's not using some really advanced a p I or anything.

  • So hopefully on Monday you can go in, take a look at some performance in your own abs.

  • Um, maybe do some improvements.

  • Who knows?

  • Um cool.

  • So the refugee movement is one of the largest grassroots you know, volunteer driven things in the world.

  • It has had tens of thousands of volunteers working with hundreds of grassroots aid groups welcome millions of newcomers to Europe.

  • It's kind of this interesting network of distributed autonomous groups that each do their own part independently, which means they can respond really quickly to changing conditions or new needs that governments or larger multinational NGOs tent.

  • But there's lots of communication overhead and lots of inefficiencies around these administrative processes.

  • So it's a diverse movement.

  • It's led by women.

  • You can see our board.

  • There on the left is Stephanie, who's ah, admin at Movement on the Ground will be talking about some of their work on the island of Lesbos later.

  • The middle is our own director.

  • Saara say hi if you see around the conference and on the right is Regina, who has started an aid group that takes donated laptops and equipment, loads educational content on them and sends them to informal schools in camps.

  • So I think it's really cool to see women at the forefront of this movement.

  • Um, and this is something that's not going to be solved within our lifetimes.

  • There's 70 million displaced people in the world today, 20 million of them are refugees in another country.

  • Um, and due to climate change, we're looking at up to one billion displaced people in the world by 2050.

  • So this is something that we need to pay attention to.

  • Now we need to build the infrastructure.

  • For now on, I'm really grateful to indigenous people all over the world and our youth like Greta, who are fighting, you know, to reduce the impact of climate change.

  • Um, so little overview of our tech.

  • We have three main areas of our platform.

  • There's kind of discovery and networking.

  • There's the supply chain eso tools around, getting things from A to B.

  • And there's the knowledge sharing section toe help, you know, share knowledge, things like that.

  • So our goal is to increase collaboration, save time and help groups make smarter, better decisions, really by just surfacing more information in a centralized place and an easy to consume and structured way.

  • But the important thing is that our tech empowers groups, which means if they can't use it, if it doesn't work, where their ad, then what are we doing?

  • Right.

  • Um, so yeah, we're free as in freedom and beer.

  • Best of both worlds, right?

  • We're using the GPL, and we're a non profit.

  • So it's free frayed groups, and this is gonna be important when we talk about testing strategies and stuff.

  • Um, I'm the only full time Dev on our team.

  • We have a great team of remote volunteers s o.

  • We need to approach kind of performance testing through the lens of a scrappy, you know, volunteer driven nonprofit.

  • Not through, like a $1,000,000 lab or something that you can just have a bunch of boxes like Automate all of this away.

  • Coop, Just a couple of slides here about our tech.

  • That's the profile.

  • This is the aid marketplace, the inventory manager.

  • Or you can see what's available and what people need.

  • And then we have the shipment.

  • Coordinator helps you keep track of decisions that you make where things are going and this is great, cause it it shows you.

  • Hey, the town next door is sending a shipment.

  • I could just throw some stuff on there on bacon, include it rather than sending another one myself.

  • Cool.

  • So the impact in the real world we coordinated a shipment of 180,000 bars of soap from Glasgow to carrying city in Scotland's.

  • It went to central warehouses in Athens and Thessaloniki, and they distributed it to dozens of aid groups all over Greece, including the islands and, most importantly, the end result.

  • We get this to the people who need it most, so that was kind of the intrasection.

  • I'm glad I'm doing well in time on dhe.

  • Now we're going to take a look at some of the extreme environments that are users operated.

  • Okay, maybe not that extreme.

  • Um, so this is Moriah.

  • It's the largest refugee camp in Europe.

  • It's on the remote Greek island of Lesbos, right next to the Turkish border.

  • It's a former prison designed to hold 2000 inmates on dhe.

  • That's the kind of prison section right there.

  • There are currently 10,000 newcomers living in the Moria refugee camp, and you can see the massive overflow area and kind of an informal camp in the foreground there that's called the olive grove.

  • So this is the kind of quarter outside Moria surrounded by barbed wire on dhe.

  • This is what you see every day as an aid worker.

  • You're going into camp.

  • You're doing all sorts of things to help people out 10 to 12 hours a day.

  • It's like an all day thing.

  • You don't get a lot of time to rest.

  • Relax.

  • You don't get a lot of time to go back to the office and jump on the WiFi or charge your phone up.

  • Azi conceive.

  • There's not really any power infrastructure there.

  • The cell signal.

  • It's spotty on DE.

  • So we have to take all of this into account when we're trying to figure out how to make our app work for for the aid workers.

  • So we don't operate here.

  • But there is a little bit of interesting.

  • Like other extreme environments.

  • You have search and rescue ships at sea who are on the ocean for months at a time.

  • Um, and you have human rights like observers were on borders.

  • This is a photo of the Hungarian Serbian border, which has 500 kilometers of razor wire on.

  • So the human rights observers are gonna be out in remote parts of the country, remote villages on kind of monitoring for things like border pushback, stuff like that and last but not least, my favorite place, which is warehouses.

  • So this is really cool.

  • That warehouse was actually the old 2003 Olympic basketball stadium in Greece, like just a ton of fun to walk around and explore, um, and aid groups Really like they just popped up overnight.

  • They asked the government, Hey, can we have some space?

  • And they have to work with what they're given.

  • So it's not something where they can design a connected infrastructure, set up the wife.

  • I threw the whole thing.

  • You know, it's like, here's a shed in my backyard.

  • Here's a converted basketball stadium, you know, make it work.

  • Um, so the storage space there is in the ring and kind of that concessions area, Um, you know, outside of the main stadium.

  • And that's what it looks like inside there s o.

  • They have cell service.

  • Um, don't have WiFi.

  • They do have power.

  • But again, people are dealing with inventory in stuff all day, every day.

  • Um, so let's actually take a look at what we mean when we're talking about performance high speed situations.

  • This is Amsterdam.

  • This is the office in San Francisco.

  • Low speed might be my own office in Serbia, you know, gets the job done.

  • Sometimes the video calls are a bit flaky, but it's okay.

  • Um, no speed there.

  • Lots of situations we talked about, some of them, like at sea, on the borders.

  • And then we have this fun one I like to call, maybe speed.

  • So this is really warehouses.

  • This is camps.

  • You might have some cell signal.

  • You might have some intermittent WiFi.

  • There will be dead zones, and that produces a lot of problems.

  • It's not just online offline online.

  • It's ping pong.

  • You back and forth.

  • So you have random Leighton see spikes.

  • Race conditions are a huge issue.

  • Um, and the from a u ie standpoint, you have to deal with this back and forth between the different states.

  • You don't want to just be showing up the pop up your online You're offline.

  • Your online very rapid succession.

  • Um, so when we're talking about speed, we're really talking about Layton C bandwidth and throughput.

  • That's an example of a warehouse.

  • So that's the office with the WiFi there.

  • This is about the size of a football field, a CZ.

  • You can see that WiFi is not gonna extend throughout the whole place.

  • It's kind of like a giant fared a cage.

  • Um, and then this is a fun one.

  • So to get WiFi in the olive grove, which is that overflow area outside of Moria, this is the town of mentality.

  • It's the largest town in the islands.

  • They send they have a satellite dish or something that sends it to a water tower.

  • Another satellite dish there bounces it off to the camp.

  • That's about four kilometers right there just beaming that awful water tower.

  • It goes into a satellite dish on the, um, the the office there, and then they have a series of WiFi repeaters around the camp, so clearly dealing with super highlight and see their interment connectivity, um, you know, storm or something like can just knock out that infrastructure.

  • Um, there's the office right there, and that's an example of a telephone pole with one of the WiFi routers, the repeaters on it.

  • So something else we need to consider, um, is data and power.

  • So you have, like, a metered WiFi mobile data or you just don't have data.

  • Um, same thing.

  • The power you plugged into the wall.

  • You're on the go or your devices Debt.

  • Um and these are all resource is that our users have in our contacts there.

  • Very limited.

  • You're out and about using your phone using our Apple Day long.

  • We can't kill that battery, right?

  • You know, you have a certain amount of time, and then your phone's dead, and then you're back to pit, build a pen and paper way.

  • Same thing with data.

  • Uh, you know, it's it's nice when you have an unlimited plan.

  • Most aid workers that I know they might buy one or two gigabytes at a time s so they're constantly having, like, running out of data, having to wait a day, go back to the cell phone store, plug some more data, and on def your stuff just stops working when they run out of data again, back to feel dependent.

  • Paper way.

  • It's a bug.

  • It's my problem, you know, it's it's they're not gonna make it their problem on.

  • And then we have hardware.

  • So lots of old donated equipment.

  • I'm gonna speed up a little bit to make sure I stay on time.

  • Um, but this is an example of what?

  • My friend's computer.

  • It just doesn't have a battery, right?

  • Like she just leaves it plugged into the wall.

  • If there's a gentle breeze that knocks the cable out, then she immediately, you know, loses all our state of what she's been working on.

  • It's my friend's phone, different friends he can't use about half his screen.

  • So I think that's maybe a different tech talk like how to make your app work with a busted phone.

  • But that's the type of equipment that we're dealing with here.

  • Um, this is all more relevant than you might think, right?

  • So a slow connection is a slow connection.

  • Warehouses have dead zones, offices have dead zones.

  • There's some poor guy in the basement, you know, trying to just get the printer to work.

  • And he has to run up and down the stairs every time he wants to print something that connects the WiFi.

  • Um, if you don't have a connection, you don't have a connection.

  • It doesn't matter if you're in the middle of a refugee camper.

  • If you're on a six hour plane to come talk, you know, at Js conflated pest.

  • Ah, dead battery is a dead battery, regardless of how fancy your phone is and old hardware exists in many real world businesses, hospitals are a great example.

  • Where do the budget or regulations?

  • They're running sometimes Internet Explorer in 2019 right?

  • So let's take a look at some performance goals on.

  • You.

  • Want to start here really important when you have these conversations with your managers?

  • You know everyone.

  • The marketing department, the dead Bob's people.

  • They want their stuff included in that page load.

  • And so you need to be realistic and set those goals which will then help you prioritize what's necessary.

  • What can you cut?

  • What can you delay?

  • Um, so in our case, we're looking at a mid range android device on we're going to say a bad three G connection, 400 kilobytes, a second bandwidth and 400 milliseconds.

  • Leighton.

  • See, we want a minute size data and power usage, and we're gonna focus for speed on two key indicators.

  • There's time to first paint and time to interactive.

  • So we want on an initial load, Um, less than two seconds to first paint and subsequent loads.

  • Less than one second on dhe for interactivity.

  • We want less than five seconds on an initial load and less than two seconds after that.

  • And remember that Leighton see, here is the killer.

  • So that's gonna take up, you know, easily.

  • 20 to 40% just pinging the server for a round trip.

  • We have product goals.

  • Hopefully, we're building stuff to do useful things, whether that's relax and have fun or, you know, make something that people want to use.

  • Um, in our case, we try to support modern browsers on desktop and mobile.

  • We're not supporting Internet Explorer.

  • Um, and, uh, we need it toe work off line.

  • So it's okay.

  • We can cut some content on functionality like our maps.

  • Paige, we need thio Get tiles from a server if you're offline.

  • We're just going to say, you know, don't use the maps.

  • Wait until you connect.

  • But there's lots of other stuff that that doesn't need to work.

  • Um, I think that right.

  • Okay.

  • Eso business goals.

  • No ultimatums.

  • I think that performance is something you should take an incremental approach to, You know, make one performance.

  • Change it a time.

  • Something is better than nothing.

  • Building offline support one step at a time, starting with the most used or most impactful work flows.

  • Um, in our case, we need reasonable testing overhead.

  • Like I said, it's a volunteer team, so we have to kind of keep that in mind.

  • We're not gonna have, you know, your budget for extra devices or lab.

  • Um, and we need toe balance.

  • You know, the sort of performance testing with new future development.

  • Adding on there, Um and I think that one of the best things you can do is if you're talking to your users, talk to them about performance, right?

  • It's ah, you know, you have your product and application bugs and stuff like that.

  • But tell them, Listen, if it takes too long to load and that makes you frustrated, that's about like, talk to me.

  • Tell me about that.

  • I want to know what device using what the connection was like Go to speed test dot net and send me a copy of the results so that I can have realistic benchmarks.

  • You know, when we're doing our internal testing, I think that we have lots of great conversations with users.

  • We should definitely extend that to performance.

  • So gonna dive in here on dhe look at our strategy to make these improvements.

  • Look at the tools that were using and, uh, look at the techniques and results that we had in our production application.

  • Um, sweet.

  • So our stack I can hear the groans already?

  • Yes.

  • We're using J Query in production in 2019.

  • I think 2009 called and they want their developer back.

  • Um, so it's pretty modern on the back ends.

  • We have elixir and phonics.

  • I'm sitting behind in engines proxy.

  • We used what, back, of course, to kind of bundle up all of our fun and assets.

  • The reason for Jake Cory is that I love the data tables plug in.

  • And when you're prototyping, none of this matters.

  • Right?

  • Um, we're going to be cutting that out and probably go with no framework on the front end's.

  • But this is good.

  • In this case, raise your hands.

  • If you're building a single page application view, react.

  • It's a lot of hands.

  • So we're not.

  • I'm gonna have some stuff that touches on performance considerations with single page applications, but just in terms of the numbers I'm showing on screen, Jake Query is kind of halfway between view and react in terms of in terms of like, library size.

  • So some realistic numbers there, Um, so it's look at how our usage, what's really going to drain that device battery?

  • Um, it's gonna be two things.

  • It's gonna be the antenna, and it's going to be running that CPU or on the laptop GP and stuff like that.

  • So, um, how to minimize antennas?

  • Just minimizing networking, right batch requests If you're sending telemetry or something, you know if you could if you could match those, collect all the data every 50 milliseconds or whatever you want, but only send it up to the server once a second or once every 10 seconds or on the next load.

  • Um, we don't want to use pulling because that's going to send a heartbeat out.

  • So there's some great tech out there like Web sockets, which do a much better job of keeping a TCP connection open without that heart beauty.

  • Um, we want to limit animations a cz much as possible every time that you have an animation doing, um, it's going to be re painting on the browser running that CPU, and I'll show you some performance stats on that in just a minute.

  • Sinking timers is important as well.

  • If you have, like, 10 different timers going off that aren't synchronized, that's gonna wake the CPU up every time.

  • If you have something that you know 50 million in the second interval and then every third time it goes off, you run some other function and synchronize it that way.

  • It's a much better strategy.

  • Um, and for common events, like the school events or, you know, whatever user types on the keyboard, things that are gonna fire a lot like that you want thio use time outs and just kind of take samples of them rather than responding to every single one.

  • So we're using Ah, come deaf tools.

  • This is the network panel.

  • This is Google's home page, and every time you type in a character, it makes another network request.

  • So this is what I'm talking about with those events with that networking.

  • This is going to keep the antenna on your phone on that whole time.

  • Um, it's okay.

  • I think when you're looking at really optimizing performance, this is great on a desktop, but it's fine to just let the user type in their search query and hit the search button and make a single request up or to do it once a second or once every half second, Um, this is I blowed it up some page with, like, a spinning, loading animation on there.

  • And this is what it looks like using chrome step tools Performance panel.

  • You can see all of that activity.

  • All of that repainting constantly, which is, uh, going to run that CPU and drain the battery.

  • So, um, another strategy is minimizing data usage.

  • Um, this is just a small bundles is really the the answer and aggressive cashing You want to compress your payloads, you need to cash everything.

  • You can, um, load content as needed, which means if you don't need it up front, just grab it in the background.

  • If it's not on that, um, you know, above the fold, then load it as the user scrolls down.

  • If they stroll down there, oftentimes they're just gonna click a link on the main menu and never need that second half of the page.

  • Um and then I think for pre cashing, um, with the service workers, something like that, you want to get your app working off line, Ask for consent.

  • Just a simple button like, Hey, would you like to download the offline experience?

  • Um, I think it's important when you're looking at people with, uh, low data like they're on a limited metered plan to just give them a heads up.

  • It's the right thing to do and then improving speed.

  • A lot of the same thing you need.

  • Thio compress payloads, cash aggressively.

  • Server side rendering is super useful here.

  • That's really going to reduce the amount of time it takes to get to that first pain, which means if you're building a single page application, you do need to do a little bit of extra work and actually send down some HTML.

  • At least send down an application show down the the header in the Footer and a sidebar and, you know, maybe a little loading message or something.

  • Um, just get something on the screen.

  • And then once you're JavaScript loads on bulls in the rest of the content and compiles the templates, it'll it'll fill out the rest of the experience.

  • Um, so, uh, images are going to delay interactivity.

  • It'll it'll show useful stuff on the browser right away.

  • But it's not going to run the drive a script until after the images are loading, so we try to delay that as much as possible.

  • There's also in limited bandwidth situations.

  • You can be pulling multiple things from the network at the same time, but if your pipes are really small, like trying to send it to the refugee camp, then you don't want your job.

  • A script download To be competing with a bunch of user uploaded images, Um, and minimizing the amount of stuff on the critical path is definitely a good technique, especially for single page applications.

  • You don't need all of your templates at once.

  • Load the current template, load the interactivity above the fold and then a synchronously grab the rest of that once the page is up and running.

  • So we're gonna be taking look now at our group's list page.

  • This has static content, static sections of the site, user uploaded text and images and some Java script functionality.

  • You can sort the table by name, you can do a search, and we're using really for tools like keeping it simple for our team is creme de tools, network and performance panels.

  • There is some setup here.

  • So to simulate a bad three g connection, we're slowing down the CPU as Muchas ah, deaf tools will allow.

  • And we're putting in a custom network throttling profile.

  • So remember, it's 400 milliseconds late and see and a 400 kilobyte a second connection, and we're going to take a look at a baseline.

  • This was our app two weeks ago.

  • Um, we already do have some goodies.

  • So because we're doing a service side rendering model of tonics and elixir, that's their what pack already does.

  • Some minimization for us and phonics has built in cash busting raise your hand if you know what cash busting is.

  • Okay, 50 50.

  • So basically, um, what you do, you compile your assets on dhe, generate a hash of the file, and you're actually going to serve up a file with, like, you know, ap dash the hash dot Js.

  • What this means is that, um you can send your you're cashing headers, right?

  • Just tell the browser to hold on to that forever.

  • They never need to load it again from your server as long as they have a local copy.

  • When you make a change in your application, it generates a new hash, and you actually just download a different file, which is, I think, a pretty good way of dealing with cashing and just trying to hold on to that data as long as it's needed.

  • So, Yikes, this is our initial load time.

  • It took five seconds on our simulated connection to paint the page.

  • It took 22 seconds to become interactive, and we downloaded basically a megabyte of content.

  • This seems really bad.

  • It is a bad three G connection in 2017.

  • This was the average load time for mobile.

  • There's 22 seconds to just grab a page, so I think we can do better than that.

  • This is the performance, pain and death tools you see really long load times, grabbing that Java script file to get to interactivity, even just grabbing the images and on the DHD and l took quite a while, so secondary loads are better.

  • We can take advantage of browser cashing, takes about a second to paint the page and become interactive.

  • And because we're using cash busting, we're just grabbing on the updated content.

  • So it's just the HTML file.

  • This might be something with a single page application.

  • It's cashed all your JavaScript and you just have to make a Jason request or something like that.

  • So you can see there.

  • It's, uh, it's loading just about everything.

  • Compassion except for the HTML page.

  • So we're gonna focus on some speed improvements here.

  • Um, we didn't I thought that we had g zip going.

  • It turns out I got a configuration file wrong and we didn't at all.

  • So I did some research, and I threw on broadly.

  • It's basically the new G zip.

  • It has about a 25% smaller file sizes.

  • When the compressions done, I added http to two engines which multiplex requests that can reuse TCP connections, which means you don't have to deal with that lead and see for every single pipe that you have open, you just open up a handful of them at the start, and then you can load up more stuff through those pipes.

  • Um, I implemented a fairly simple bundle splitting strategy in Web packed, so I think that we could do even more here.

  • But for now, I just wanted to separate our application code and styles from our vendor code and styles because the libraries and stuff we use don't change nearly as often as updates to actual business logic in front end code.

  • This will allow me to cash that vendor file and just keep it there for weeks at a time until we throw in the new import while we're making daily changes to the application.

  • Um, yes, um imagery sizing.

  • Just cutting down.

  • Take a look like you're throwing on fun, awesome or something.

  • You don't need 1000 icons.

  • You're probably just using 50 in your app.

  • Double check that and lazy lode User generated images.

  • You can grab them after you get interactivity.

  • So we hit our goals with these improvements alone.

  • We got it down.

  • Thio.

  • Just under two seconds to first pain.

  • 4.5 seconds Interactive and, uh, really cut down on the amount of data we're transferring and the overall size there.

  • So just with some, like simple improvements, a couple of server configurations, lazy loading the images and doing some bundle splitting with wet pack.

  • We see you know, over 60% performance improvement in the metrics that matter.

  • Um you can see here that that side that's those images that were lazy loading.

  • So the paint happens really quickly.

  • We're reusing a lot of the same TCP connections with the cheese to it gets to interactivity, and then we just grab the rest of that user content Subsequent loads, similar source of improvement.

  • We're down to under a second on a bad connection.

  • Four first pain and interactivity, and we're only serving up 2.6 kilobytes, just the updated content on the page.

  • So I got one minute, and I'm just gonna touch on service workers really quickly here.

  • Our basic strategy.

  • We want to cash all the static assets on install, um, and served them with a cash first approach.

  • So this is where cash busting comes in.

  • Really useful is that if you have that file, they're just serve it up.

  • No need to go to the network.

  • If you don't, then fall back to the network, grab it, cash it for next time, um, and then for the pages, because those might be updated with user generated content.

  • We want to do a network first approach, but keep them cash, so grab him from the network grabbed the latest copy.

  • If you go off line, be able to serve that copy from your cash.

  • So we're using service workers were using the cash A p I, um Yeah, and it gets really fast.

  • So this is with online.

  • Um, we have half a second to interactivity, and most of that is a 400 millisecond latency to to grab the updated HTML page.

  • And that's what we see here.

  • So it's just grabbing that stuff and then loading everything from cash.

  • What's really interesting is that, um, offline is actually the best performance because we don't have that.

  • Leighton.

  • See, we don't have to hit the network up.

  • It just loads the last version of everything we cashed 100 milliseconds.

  • Thio get there 150.

  • No, dated a chancer.

  • So once we kind of wrap this up, you know, make a couple of more touch ups to our service workers.

  • I'm just gonna tell aid workers in the field hit airplane mode like download the latest coffee in the morning hit airplane mode, Do your work all day on hit airplane mode and uploaded at the end of the day.

  • Um, cool so thank you so much.

  • Um, that's kind of my talk.

  • I hoped it served is like a good overview of performance.

  • Optimization is you can make and javascript and a little bit about the refugee it movement.

  • Um, you can check out the offline functionality on our APP.

  • All the code is publicly available on Get hub, and I'll be throwing the sides up along with some weeks to further research and tutorials on our Twitter.

  • Enjoy your lunch.

everybody.

字幕と単語

ワンタップで英和辞典検索 単語をクリックすると、意味が表示されます

B1 中級

極限状態のJS。難民支援運動のためのWebApps by Taylor Fairbank|JSConf Bp 2019 (JS in Extreme Conditions: WebApps for the Refugee Aid Movement by Taylor Fairbank | JSConf Bp 2019)

  • 5 0
    林宜悉 に公開 2021 年 01 月 14 日
動画の中の単語