 And welcome to your first post-lunch talk. And to prepare for this, everyone stand up. Everyone, put your hands in the air. I know what lunch does, everyone. We're not going to have everyone sleeping. Shake your hands. Up, up, up. Down, down, down. Up, up, up. Down, down, down. Now, jump five times and sit down. There we go. Welcome to elementary school again. See, I have to do that because I'll fall asleep just standing up here, like, okay. Welcome to Creating a Culture of Performance. We're going to talk about how to create a culture of performance at your organization. My name is Ian Kerco. I am a web performance artist at Vox Media, formerly at Four Kitchens. I am Kerco everywhere across the internet. It's my website, Twitter handle, Drupal Door username, GitHub username, and pretty much everything else. And I am Chris Rupal, front-end, well, front-end performance is one of the many hats I wear at Four Kitchens. And I am Rupal all the way across the internet, truncated web 2.0 style. I'm so cool. So first of all, what does this talk about? We're going to talk about how to consider performance at every step of development, what performance the budgets are and how to use them, how to share information with teams on performance, and implementing some continuous integration tools. So first off, we're going to start with a quote that actually one of our coworkers used actually just this past week about performance. And it's, for a small site and even some slightly larger sites, none of this performance work is mind-blowingly difficult. It's just a matter of setting it up and committing to it. It's from Taylor Swift. Taylor Smith. He's going to kill me. Yes, yes it is. And it's a good idea of kind of when it comes to performance, there are a lot of tricks and tips and things that we can do and tech we can put forward, but none of it is incredibly difficult as long as an organization, we're all doing it together. And this is why we want to talk about a culture performance as opposed to creating a singular person who is a performance janitor or performance cop who's trying to come in clean of everything because that makes everything far more difficult. So what is performance culture? We define it just simply by getting everybody on board to make performance choices on the web. Fairly, fairly straightforward. So kind of everybody, what do we mean by this? Everybody, yes. From designers, developers, project managers, product owners, and your C-level employees, the people in charge as we like to refer to them as. So getting everyone on board, right? There's lots of discussion that can happen when you're working on a project and things can be hot in the moment and you want to ship something and get it out the door. And so a lot of times you say, oh, I don't have time for that or this or that. So we wanted to go through a couple of trigger phrases that you might hear in the course of a project from each role to kind of keep in mind and go, oh, hey, but we've got a solution for that or here's how to take the next step and kind of respond when you hear someone saying X or Y or Z. So we're gonna basically just kind of work towards trying to get buy-in. First is CXO, of course. So this one's kind of easy. If you can demonstrate how it's going to make you more money to do this, then you can probably convince someone that this is the right way to go. What does that mean? Faster websites turn more traffic. People will stay on your website longer and stay more engaged when your pages are loading faster. The interface is responding to your interaction very quickly and reliably so you can just keep people on there longer, get them to convert more easily or quickly, or if you don't have a specific conversion to make a lot of times people are putting ads on a page or trying to do that and drive impressions to their website, obviously a site that loads a page faster will also either load ads faster if you defer that kind of thing or basically just get it out of the way so that you can get the money generation happening on the page and get more page views. So these are all things to kind of like throw towards the top level stakeholder and say, no, but if we do this then we can actually squeeze more out of each person that's coming to the site or get more people to come if we are faster than our competitors. There have been studies done by Amazon of the faster their site is, the faster their home page is, the more things people actually buy. So if you're an e-commerce site, there have been studies that show faster sites result in more products being purchased. There's also been studies by both Google and Bing of the faster their sites are, the more ad revenue that they actually pull in, the more ads they get to share and to a large degree for some of these organizations as well. It's also important to note that if your site is 20% faster than your competitor's site, it's more likely that people go to your site than your competitor. Vice versa, if your competitor's site is 20% faster than your site, it is more likely that users will leave your site and go to a competitor's site. All things have been backed up by multiple studies, both in just web performance and general psychology. So the next are the product owners. Sometimes people will say, we don't have time to focus on this right now, we just need to ship the feature. And that can be okay, but we need to learn to stop and say, well hey, is it okay if I file a follow-up ticket for this and we can put it in the backlog? You might want to do a full-blown, like a performance sprint or something later on in the project, or you could just ask that maybe one or two of these issues are tackled as a regular occurrence in every development cycle that you do. So it's a way to, even if you don't have time, which can be true, you still can't just defer it forever. And just keeping it in mind and bringing it up and documenting that it needs to be done can actually get you out of trouble later also when someone finally decides that the site is too slow and not doing what they want it to do. You can say, oh well, we've had these tickets around for two months and maybe we should take a look at them now. We also hear constantly the phrase, we want the site to be responsive and that can't be performance, or responsive sites are slower, they load more, and this is not true in any way. Dave Rupert actually did just a base study on his site. Of how much responsive design added onto the overhead of his site. And it was about 10% more code was added to make the site responsive. But at the same time, the proper responsive loading techniques of lazy loading images or loading smaller images for smaller devices and things like that saved vastly more bandwidth and vastly more space than the code up of adding in media queries to your CSS or adding some JavaScript libraries. It's the age old tale of progressive enhancement. So, you know, the next time someone says I just say, no, it's okay, we can spend a little bit of time and if we do this intelligently, we can have our cake and eat it too. Also we hear that a great user experience is more important than having performance and it is very much a piece of user experience to have a performance site. If your user isn't able to actually access the site, that would be the first instance of a poor user experience. You don't have to lose any sort of wonder or magic or what have you by having a site be performant. You know, my site's a bad example of this. It's very performant, but it's a terrible design because I'm not a designer. But that doesn't have to be true for a lot of sites and there's a lot of really fantastic design sites out there that are very performant. So the next person in our role is the project manager and we hear from them is how do we add this to a story or how do we add this as a story? And the entire point of having a culture around performance is by not having an individual make site performant story but have it be a piece that's looked at during every story of are we setting appropriate performance goals in this story or are we adding in a bunch of craft that's not needed to be there? So you might need to include this in the exact user story or something if you are using a scrum system but you might want to say part of your requirement is as a visitor I would like to be able to see the product detail page within two seconds of clicking the link or something like that and if you include a very high level metric the page doesn't have to be completely loaded just as long as you can start seeing some information within and agreed upon amount of time you are factoring in this concern from the get go and you can then use it as a talking point when you're talking to some of the other roles that we'll see in a second here but as long as you document it as part of the project requirement and your thinking of this in each individual task that you're working on it helps everyone understand oh hey that's why you're telling me we can't have this two megabyte background image or that's why you're telling me you want this minor piece of the design to change just keeping it in mind at both the high level and individual tasks and also how do we get the client to care if you are a client services company it's not necessarily you that needs to be convinced it's the client who needs to be convinced of this and really this goes back to the previous two points of the CXO and the PO people there are a lot of ways you can sell as a client so that's something we do have to worry about because in certain reason here ad revenue, click throughs, what have you will all be enhanced by having a more performance site so designers this is one of my favorites there are a lot of people who say you can't have good design and be performance or the one I get a lot which is don't take away my web fonts I'm sure we've all heard this at some point or another and both of these things are just not true you can have really great designs and still have a really performance site and when it comes to the web font conversation I hear a lot of performance engineers who say no no no we can't have developers or performance engineers who say no we can't have web fonts at all we can't do that and that's not a solution it needs to be a conversation between the designer or the performance engineers the developers, the product owners of how can we stay within our constraints of we need to have a performance site and have the right design have the right pieces and it's not so much a developer needs to say no we can't do this no we can't have images, no we can't load web fonts, no we can't do any assortment of things it needs to be a ok we need to have these now do we need all of them or are we loading up an entire web font just for three bold letters on the footer which then we can talk about is this actually needed to have an overhead of 150 kilobytes for a font or what have you or can we remove some of these pieces and how can we better enhance loading techniques how can we make sure that we are loading everything in a performance manner would you like to add to designers? no, cool also the PSD was already approved I hear this one before yes the PSD might have been approved but we can't again we can't add 50 different web fonts just to a page just because we we want to I would argue that's bad design on a number of levels but we need to take a look at the entire problem we're not designing for printing out a pamphlet we're not designing to create a video that's going to be put out we're designing for a medium where performance is one of the constraints that we need to think about on a daily basis just like we need to think about the constraints of database performance we need to think about the constraints of we're working within these windows into the internet that we're looking through this one's also particularly well there's multiple talks that could be made just about this one bullet people that's why it's often promoted to like design in the browser or generate a prototype as quickly as possible instead of relying on your static pixel based comp and so as long as if you're moving more quickly into a live prototype you can check other things amongst beside the visual design you can check interaction speed or decide oh hey maybe we need like an animation here to distract the user for a second while the page does something or goes and fetches more content or information so there is a whole other world to be discussed there but often times the best solution is to just not have a PSD but you know baby steps and developers you know we also need to get buying from developers who will be working on a lot of the performance decisions and what we hear is we don't have time to do performance or I can't test performance easily both of these are for every story every piece of functionality we build there are a hundred different things that we need to think about as we build it if you build like a site needs to be translating about internationalization for every story if you build a site with a lot of information about database performance we can think about rendering time in a lot of Drupal sites but all of these things yes it does seem like another layer but it's a layer that's really needed to make this site cool not to mention if your site is really performant you can brag about it on Twitter and that's really important that's what this is all about right there are things you can do minor tests that you can run that are very easy to set up and continue setting up and that forms the basis for doing some of these other things like even if you don't have time to fix it at the moment you can say during story 224 we decided or we added a half second of load time based on this content that we added we need to go clean that up and make sure we're getting the page back under that threshold that we agreed upon at the beginning so you can test things and make a note of it and even if you don't do something about it right then you at least know when it happened and that helps you go back and optimize something in the future when you have a little bit of time to do it so once we get buy-in from all of these groups we need to think about how we can actually make performance choices perpetually through the process and these choices can't just be made once we start writing code but they need to be thought about throughout the entirety of the project from design, development UX, wireframes and everything so the first thing we think about is setting a performance budget at the beginning of every project of what is our budget that we can allow for performance and these work similar to how a household budget works where you have a user can we decided at the beginning of the project we will allow on a cable connection up to a one second load time on an LTE connection up to a three second load time we want our site to be under one megabyte we want our speed index to be under one megabyte and those are a set of agreed upon ideas that is set at the very beginning of the project that we can then every feature that we build from that point forward we compare to our performance budget so once we hit our performance budget and we say okay we've hit this but now we want to add a hero image carousel on the front page of the site we can go back to this and say okay we already have this agreed upon we either need to remove something else or we don't do this feature and it sets the tone at the very beginning of a project it includes production includes performance in all of our discussions going forward where we have this agreed upon list that is set in Limestone that we can look back and say this is what we agreed upon we can't go above this just like we can't go above the project budget we can't spend more than you know 500,000 on a project because that's all we have the budget for there's also other things you can measure by there's lots of material on this online but a famous one that's often referred to because it was used twice as twitter went through two major redesigns as a milestone related metric so they use time to first tweet like the amount of time it took for the page to load and for you to see the first tweet at the top of your stream so they don't care about how long it takes the template to load because they were using a client side rendering like an MVC in javascript for a while and it seemed like the future at the time but they found that it was actually much slower than rendering HTML on the server and sending that down and then enhancing it with javascript afterwards and so using their time to first tweet metric they don't care about the little sidebars or the little trending or who to follow none of that matters and they can then decide when like what content needs to be deferred and what content needs to be presented immediately to the user and prioritized there's other things that might happen like if you're going to create the off discussed critical paths CSS well maybe you want to focus your styles on the main column of content and not worry about loading in those sidebars on that very first response so there are time based metrics there are metrics established by tools like web page test or google page speed or why slow and then you can also just figure out your own metrics using many tools there are web standards like navigation timing and performance timing there is there are services like new relic that can allow you to generate these metrics pretty easily they just have little bits of inline JavaScript in there that you had to your website and then you are pinging their service and basically telling it exactly how long it took from the beginning of the page load to when that content was visible so there are a lot of ways to deal with it and you just have to find the right one for your group and stick to it as a note you know this works really great at the beginning of projects as we are setting up our budget we are setting up our constraints but obviously a lot of us already have projects that either I have already been built and are live and we are trying to clean up and fix or you know projects that are already going on one of the things that we are doing at Vox Media right now is instead of thinking about performance budgets at the beginning we are thinking about our performance goals of we want to get the site it is a speed index in there 4,000 I believe start render under 2 seconds and I forget the rest of them but it is our goal we are using the same principle of a budget but instead of that we are coming out of the other side we want to get it from here down to here and we are using that as a a method of this is how we are going to decide how we are going to do things if we can get it under these numbers if we are going to hurt that then we are not going to do it and it is kind of coming at this problem from the other side of the tail and so the important thing also to making all this happen is automating it in some way if someone is capable of pushing code and then creating a pull request and even a little bit of light code review then merging it in you basically without a budget without any interaction from other people so I guess we will move on yeah the other important thing when we talk about performance choices is to be honest about what is going on you know don't try to put any sprinkle of our site is doing really well when it is not or the opposite of it is not doing well and it is and people can measure it themselves yes and it is important for the project owners, the project managers the C level employees, the people in charge all to have a sense of where we are, where we want to be what our goals are so like for example one of the things that we just did at box media and Etsy has been doing for a very long time is doing quarterly performance reports of this is where our performance is and it is both for internal and external viewing ours was declaring performance bankruptcy and us trying to come and fix that because we have gone over our budget for way too long Etsy had something similar when they first started and now they are constantly showing slightly better numbers every quarter by sharing these performance reports it is it is important to celebrate the successes that you have on your team of celebrating a performance hero someone who has done an excellent job even if they are not on the performance team there has been many instances we just had someone at Vox been to implement a new font loading technique that is awesome and we are going testing it right now to see how much it will help the site performance but it is loading them asynchronously with some really intelligent tools and on the other side it is also important to acknowledge failures acknowledge when we did something wrong acknowledge when we have gone over budget and find ways of going back and fixing that one way of doing this is by having constant reminders things like having a dashboard that shows goals and status there is site speed site speed.io is a new software tool that is doing this there is also a bunch of other services if you just want to subscribe to one there is a pretty new one called speed curve or you could always hire someone to check your site out for you hi so they are putting the data up there and putting it front and center and looking at it every day and checking it is very important even the most minor of checks is enough a tool that I have demoed at previous Drupal cons is called grunt fontamas and it is a phantom js based performance tool that actually logs trends and it creates a pretty little graph for you and I would always show this graphic of a spike I was working on a project running this every day came into work one day and ran it and someone had somehow inlined two megs of data URIs into our CSS file and so the CSS file just spiked immediately but I caught it in the morning and it was gone by the afternoon and we were back on track the next morning when I ran the tests so it is actually a success in a way because if you are doing this in the middle of a development cycle and catching it before it ever ships then you have done yourself a favor and it is a hot fix that later on as soon as someone notices that the site is super slow once you are actually loading it on the internet so dashboards are good now may I talk about automated testing, is that okay now? Continuous integration is next yeah okay cool so we have the video first okay cool he is so excited about the automated testing as we all should be knowing that these dashboards aren't just for the three developers who are looking at the code constantly but also for everyone site speed as Chris noticed has a great dashboard that we can share with the entire team and everyone can come and look at where we are, our progress they can see where our budget is, where our goals are and there is a distinct line of we are trying to get it down to this point you can compare other competitors if you want on that site it is really good for just overall checks and tests and having a great visualization of everything that is going on on a site load and you can put it on a TV in your office or something like that and watch it all the time and make sure that it is kind of top of mind for people and people get really creative sometimes I have seen little Arduino integrations with GitHub when someone breaks a build then like a siren or a light goes off in an office so you can get pretty creative if you want and make it fun at the same time the other one was a servo controlled nerf gun that would shoot the person that broke the build that takes a lot of creativity and a hack week visuals are also really great the dashboard with graphs this is where we are, this is where we want to be we are still kind of lacking a little bit one of the things web page test does that I absolutely love is you can load up different sites and compare your site either in different locations or with different speeds or two competitors so you get something looks like this where you can see this is visually what each site looks like compared to each other it shows more than just start render, stop render, don content load you can see, for example while CNN loads its content very quickly it takes a long time for everything else to load and then Vox loads its content slightly slower and New York Times quickly has their content up but again it's loading all these bits and pieces on the side and it's a great way you can show this to anyone from performance engineer to developer to sea level employee and they can get exactly this is us compared to everyone else that we are working with all you this can be kind of scary I know it was scary to me when I first started thinking about it especially just as a humble front ender but it definitely helps out there's a couple steps involved so build, test and deploy the basic three steps first is having some sort of build process that can allow you to make changes to your very well organized well documented high fidelity original assets and then create them or have them transformed into your production ready optimized assets automatically for you and so everyone hears about grunt, gulp and all these little tools that you use are very important for that reason because then when you're developing you're making changes to your site but you're viewing it the way that it will be viewed by your end user second would be testing so you might want to there are all sorts of testing methods there are performance tests there are functional tests there are CSS visual regression tests available all of these things should be automatic because they should be either something as simple as linting can be run on every commit and then you never are messing up some JavaScript accidentally or you're keeping your coding standards clean so that someone can come through and read the file well and then there might be bigger things like making sure that you can click on your search overlay and type something and then scroll down the page and still get to another piece of content despite having this very arduous five step process in order to test it have a machine do that type of thing and then also you can put tests in front of your before you share the code with the world so if you work locally and then you want to push your branch up to github you might consider running a few tests on that code before pushing it if the test fails the push fails is kind of a it's a much less personal way of keeping yourself in check instead of pushing some code up creating a PR and having someone go like you know you kind of like misindented this code here can you like fix all that and then I'll give this a review or having someone look it over and think it's all good and then when you merge it in you realize oh hey we made this we slowed this down a lot and then you can review and tell you what you've done wrong hurts well it hurts my feelings a little less than having someone come to me and be like hey you messed that up and so then you can get that first round of feedback out of the way and when your fellow team member looks over the work they are focusing purely on the human side of the review does this make sense have you used all of the other framework that we are trying to use are you following conventions and that type of thing that is a little harder to test and then finally once you've gotten it up there run the tests again there are tools to do this there is an awesome Jenkins PR builder for I think the Lullabots made it there is there's Travis which is what we use often if you have an open source project free to use and it is very simple you can set up a Travis file with 5 lines of code and it gets your tests running and I mean you have to write the tests but the Travis part getting it to run on Travis and run on the system is a very minimal amount of work and Travis will like immediately put in your pull request whether or not the tests passed or failed so it does everything to make you know really easy it actually changes the interface of github in particular when you are using github plus Travis and it either when the tests pass it shows you that beautiful green button and when they don't it says hey the tests are failing you can still merge this but merge with caution and it changes the interface so that you you come to expect a couple of things when you are doing a code review on your tool of choice and it works with those and it enhances them so use a robot and make sure that you are keeping yourself honest there are even ways to run performance tests on Travis so we have a couple of links are they in the slides? yeah we have links to a fully functional gulp file we did a training on Monday here at Drupalcon and it is completely open source you can go check it out and all three of these are contained in the file you build you test and you can even make a pull request to our open source repo and see it in action go try it out if you want and no harm done if you push up a PR that breaks things so try it out for yourself as a quick note the tool to do the three website side by side is just webpagetest.org so it is online anyone can quickly go up to the website in a couple of minutes to have quick side by side video comparisons as well as a bunch of other data as you are taking a look at it so coming back to our definition of what is performance culture we want everybody on the team on board making performance decisions so we take we have buy in from everyone and then using all of these tools using things like getting dashboards out there we use integration for designers and developers getting designers and developers to talk and negotiate between what features are needed with performance budgets and what is allowed what is not allowed setting up these pieces creates a culture where everyone has performance in the back of their mind of we can see this is how our site is loading we can see all of this data we can have our tests running we can have these conversations we can see the effects we can see with visual side by side comparisons and our dashboard and looking at our competitive sites in comparison to have all of that as one any other thoughts with that thank you that is what we want to talk about and we have any questions if you do a question please go to the mic so we can have everyone here and record it we have intentionally given a high level overview but if you want to ask a detailed question we would be happy to go into it we have plenty of time here to do Q&A on performance budgets it kind of sounded like it was a once a number is decided on that is the absolute like you said a financial budget my question is a lot of times it is more of a conversation on is this feature worth the extra money and I guess the same question applies to performance budget if the feature can be justified is the performance budget still flexible in that sense it absolutely should be the performance budget is a framework for discussion and that is its absolute purpose so the result of the discussion might be like oh hey we are getting more sales from adding this feature to the home page so that is cool we should add it maybe we can adjust the budget a little bit and raise it or perhaps because you have that number in front of you you can decide that you should take something off that is a little less important to you and so it just basically brings the discussion it makes it more prescient and up front all the time thank you you guys talked a lot about testing locally and testing on your server but I was wondering if you could get into some of the specifics of tools you use and that you would recommend and things that you like I could give you a list also at the same time I would feel like I am not really doing much by describing them I have actually given a talk in this nature the last three Drupalcons have been an hour of tech and so Megan actually came up here and was like what cool stuff are you guys going to show this time and I was like oh we are just talking about business this time to give you just in a nutshell I could give you a couple though one I already mentioned is Grunt Fontamas I really love it it generates very detailed information there are hundreds of metrics that it is capable of measuring you don't need to use them all you can pick a subset and keep them up front how many kilobytes of CSS are we loading on this page day after day after day or even every six hours or something you can set it up to be run by a robot another one almost always my first stop is now Google PageSpeed Why Slow is another alternative you can run this on any public site and it will give you a prioritized list of things to fix and it actually gives you a relative impact score as well so it basically rates it from 1 to X just based on the relative impact that the tool thinks it will have say you've got 100 unaggregated JavaScript files it's going to complain about that and give that probably a pretty high score like a 25 or something 25 times as effective as inlining like this other little piece of CSS or something like that so Google PageSpeed is one there's a command line tool for that as well you can combine that with this neat tool called ngrok that will allow you to test local sites as well that is not to be taken as like a that's not going to be the same as your production because you're like testing your local environment but it does get you a lot of a lot of metrics that aren't latency bound can be measured with this tool very safely and identified very quickly on your local development Phantom.js in general is a very good tool I have in the past preferred Casper and I like it because it's very easy to set up and you can do many things you can take screenshots of your site there's an add-on called Phantom CSS that lets you do visual regression testing and see when you might have like bumped some CSS around on accident maybe you took away like a global margin setting on accident and then everything like shrinks a little so that's something that you can catch on your local and then also there's just an endless number of plugins that can help you do things like anything from concatenating files to minifying JavaScript and so forth again we've got a link to a repo that has a huge list of them a pretty decent set of Drupal modules are listed an entire workflow is completely defined for you and then some tests too just some example tests great thank you whenever you're using Travis to test out the rendering of sites I'm assuming are you testing them against the live site or like a development site like I know on Travis you can spin up a site right on Travis and test that so are you testing that site or are you testing the production site? It depends so I'm working on a site right now and we save reference screenshots into the codebase itself and then what we do is use Casper to basically take a very targeted screenshot of a piece of the website so there's a test for each like a component of the site instead of taking a full page screenshot which then if you change something in the header then all of your tests will fail instead of just your header test failing and you can have more test coverage more specific test coverage without creating a lot of false positives does that answer the question? you basically save those screenshots into version control when you make a breaking change you just kind of update the reference files and you would say hey I'm expecting this to fail or you update them in advance as with all testing you should always verify like no test is good until you can make it fail and make it pass predictably so both need to be able to happen to have a good test and so then if you are updating those references okay they're failing I made a new copy they're passing there's also what is amortized new thing shuve.io or something so that's a little different and he has described it as more of like a visual regression testing pngdom so instead of doing per deploy tests it basically just monitors the site and says like oh hey this changed it needs to go check on it so there's a lot of ways to approach it per pull request or incrementally every x minutes or something like that how do you make assumptions about like what your baseline network connection is going to be like what you're going to test again so like recently I did a site where my baseline was just like a regular 3G network which is good for mobile but I also use that as a baseline you know as I progressively enhance the site up to desktop so what are your ideas around well it depends on what is important to the business or the organization that wants the site so we have run we've in my career have built sites that are displayed you know they're supposed to be making it to little ones you know all around the world including like Southeast Asia or parts of Africa that have not nearly the same technological infrastructure that we enjoy in the states and so you have to pick something that's relevant to the business you know if you're making a like video streaming site you're probably just kind of making more assumptions about your audience and saying like hey if we are designing this to work well on a new tablet then you know maybe it's okay to assume a better internet connection whereas if you are making something that lets you look up restaurants on the go and you know are expecting people to be doing this you know on a mobile connection then you need to be testing for that up front there are lots of good tools for this I like using Charles proxy to shape network connections Chrome has really good they have a network shaping emulator thing in their dev tools so not only can you pick to emulate a style of device but you can pick the network connection as well and if you combine that with something like browser sync you can do really rapid development and actually see the effects of your changes and it can be heartbreaking to turn that on and leave it on but it's also healthy to face it and approach it as a challenge rather than ignoring it 3G is actually a good starting point I would say if you are shooting for a European or US based audience if you are doing something with a bigger reach then you might want to assume lower than that and act accordingly we test for 3G and a general cable connection for all of our tests and all these tools also web page test has a throttler built into it so you can run these tests and keep them set to a lower connection quality thank you cool thank you guys very much for coming in if you want give us some feedback on the jubilcon site there's a short link there and our slides are up on github with short link there so thank you guys very much we'll be right back