 So welcome everybody back. This is the dreaded after lunch event when you're all in a carbohydrate coma So hopefully you'll all wake up with the the fierce debate that is about to be ignited here The inventor of the onslaught system Wesley assures me it's going to be working so so please put your hand up and Give an opinion you don't have to just be putting standing up to ask a question stand up Let's ask an opinion. We want to hear what you think as well quickly introduce you to the panel She'll start from this side Pat Menon from Google the inventor of web page test the basically the best page load performance testing tool out there Wesley hails from shape security Front-end developer mentor of of onslaught and load report.js. We have Luke Blaney from the FT Very much did a lot of work on speeding up the FT web app and as big fan of varnish apparently We have Peter Hidden skull Okay from cybercom group creator of site speed IO and browser time and last but not least We have Andy Davies from NCC group web performance velocity speaker And the person who was going to kick off with the introduction Okay, so Steve's already introduced me, but I'm Andy and I'm frustrated And the reason I'm frustrated is the web is too slow or rather Too many sites are too slow Because you know, we've been talking about why we need to make web pages faster for a long time Steve Souders first invented the concept back in 2006 2017 wrote his book and We understand how to make sites faster and this is one of the reasons why I really get frustrated We know that to make sites faster. We need to minimize latency whether that's using CDN to move our Content closer to our users Whether it's speeding up our back ends so the time to first bite is quicker You know, we know latency doesn't change You know, it's governed by the speed of light. So we have to move to reduce it The other thing we need to do is, you know Cut down the number of round trips we make because every round trip is bounded by how quickly we can make it All the latency involved, you know, and we do this fire Turning on gzip to compress stuff We use minification. We merge resources together in a build system and one of the reasons we do all this is there's a tension between How we build sites or how we break it down into modular components and the best fought way to get them to the browser For the browser to be able to load the page quickly a render it quickly We um, you know, so, you know, we can minimize latency We can reduce another round trips and we can minimize blocking because some of our resources block If we've got CSS we have to wait for the CSS before we can render the page We've got JavaScript. We have to wait for the JavaScript to execute and before we can move on We have web fonts and now depending on how we load web fonts sometimes we have to wait for them Sometimes we don't the other way of making sites load fast is to maximize the value we get out the first round trip So when you hear Paul Irish on stage at fluent conference talking about Put it in the first 15k. This is effective. What he's talking about. He's talking about Turn the initial con TCP initial congestion window up to 10 Make so you've got it roughly about 14.8k depending on how big your TCP segments are on it and push that out to the Browser everything you need to render the page on that first hit. So that's what the guardians do on the mobile site You know, they have the content the idea that they serve out the content Which is the HTML and CSS to render the page They have the enhancements so where they insert JavaScript for Swiping and then they have the idea of leftovers. So advertising analytics So, you know, we can make our pages faster, you know But we seem to want us to leave it to the browsers to do it and browsers are doing a great job and have done a Great job over the years of helping us make our pages faster, you know The HTTP standard Recommends we only have two connections to TCP connections to our server, but we've moved on from that, you know Typically browsers have four or six or sometimes even eight They open TCP connections in advance. They speculate that we're going to request something from the same server So we open the connection. It's there ready for us to use. We have the preloader Which while we're busy waiting for CSS or blocked on JavaScript execute preloader will go looking through the rest of the page picking up The resources the page will need to complete prioritizing them and downloading them in the most optimal order. We've got faster JS engines We've got new image formats faster layout engines. So, you know browsers are doing a great job We also have new protocols HTTP doesn't fit very well on top of TCP so we have speedy now we have HTTP 2 coming and They will help improve the performance of our sites on some tests. I did I got a 30% uplifting performance Just by switching to speedy and that includes the TLS negotiation overhead HTTP 2 may get rid of some of our build steps. It may reduce the need to merge stuff We're still going to have the challenge though that we have people on HTTP one as well as HP on People on HP to we're gonna have to work out how to optimize both But despite all these improvements that kick them across we keep adding more and more stuff to our pages Our pages are getting fatter We're relying on browsers and networks to overcome the performance hurdle and Perhaps more worrying is we're including more blocking resource Now the number of times I see a tweet going somebody going I Hate web fonts because this is the experience I get and a page with no text on it But yet they put web soft fonts on their own site So, you know, we're making our pages more and more complex and delivering more and more of a challenge We can automate some of this optimization. So we talk about merging stuff and image optimization we can use things like mod page speed or Akamai's FEO service to take some of these optimizations away to simplify our build services but okay, so why aren't we getting faster and my View is we don't measure enough You know, we've got great tools. This is site speed. I owe that Peter out. We've got things like web page test We can measure in the visitors browser. So we can measure the page level. We can measure individual resources We can tag the page so we can measure when something we're interesting appears but You know, there's a lot of data and we need to move beyond Why which pages are slow to why are they slow? You know, this is a waterfall in web page test There's actually some interesting things in this waterfall in that the time to first bites are always about 200 milliseconds And this is because I did the test from Dulles in Virginia instead of the UK by mistake, you know But I ended up looking at this for a while working out what was wrong with it And it took me a while and am I destined to be a human pattern matcher for network waterfalls for the rest of my Life to help me at the web faster, you know, we need to move on to how do we fix it? You know, and we know the order browsers need resources to be able to render a page and get a page to a user But you know, we don't really have the tools to help us get there and finally, you know We think of performance as a technical issue and it's not or I would argue for technical aspects to it But we need to go back and think about performance as an aspect of user experience You know, we go to fluent or velocity or edge conference and talk about page load performance But we need to fit it in to the rest of the user experience picture Will a be test whether a button should be green or blue But will we a be test how our performance improves if we remove our a be framework or our fonts? We don't generally do it. We need to design for performance You know, it's if it's a user experience facet. We need to design it into the way we build sites it's just another constraint like time or budget and Design, you know clear left Tim Cadillac put forward the idea of a performance budget So you decide how long should your page takes a load over what conditions? How big should it be and we need to As well as technical solutions. We need to go and look for the human solutions and we've come a long way, you know We've got much faster browsers. We've got better networks But we need better tools. We need to fit Performance in and look at it in a holistic way in the way we build websites And we also need to be careful about new technologies, you know, we we've got HTTP to coming We don't really we know some of the performance improvements it makes But we don't know what other impacts may come with it We've got web components that we talked about this morning and things like the potential blocking effect of rally equals import And we need to work out if we deploy web components on the large scale in a blocking format What are the issues it brings? And now I believe our moderator will put to us your questions Thank you, Andy So Andy's Andy's frustrated because he's gonna spend the rest of his career as a human pattern matcher I don't think that fits in a tweet, but it would be really good if it did Okay, so kickoff first question Is basically one on responsive web design from Peter O'Shaughnessy Using branched loading the Guardian have made their new website responsive But 42 percent smaller on mobile than on desktop Does this end the performance arguments against responsive web design? Are there still cases when a separate mobile site is best You're the front-end developer Representative ways you want to touch that with this one. Yeah, it really depends on the goals of the organization I guess and I Mean you can have a separate team sometimes like when I was at CNN We had an entire separate team working on a separate mobile web site for CNN And then we had a and they were completely divided and it was a really uncomfortable situation not being able to To our cross teams. It was just the way they had siloed it off. So Like I said, it depends on the company like I guess how what your goals are, but It does make sense for like a crud if you have a heavy like, you know client side application single page, whatever Then you would not want to try to scale that down to put on mobile, right? I mean chances are you unless you're trying to achieve the same thing on mobile But sometimes developers just build for desktop first a lot of cases Pat you're looking at yeah, I mean you're looking at websites all the time web page test And I think it's it's gonna get interesting. We're probably gonna see this a lot today is Depending on how extreme you're trying to get like when we start talking about deliver the above-the-fold content in the first 15k right if you're gonna try and do that on mobile the first 15k is Fairly easy to get your one image and your story or whatever What you're trying to deliver for your first for 15k of your desktop or your responsive site is gonna be very different So I think it's gonna be really hard To do a responsive like uber optimized site that scales for both mobile and desktop You may be able to do well enough Now it's 42% smaller now, but how small could it be if it was catered just for that device and You know, it's a car. It's a compromise You know responsive design is about building a site that works on a wider variety of devices as possible at unachievable cost effort If you look at the studies people build really small mobile sites You can build a really a mobile site. That's you know tens of K. Whereas how big is the Guardian site Patrick? Yeah Yeah, so, you know the 42% is a still a huge job so You know, it's a it's a working progress as to whether the responsive argument has gone away Luke Ft you're in the same business publishing. Yeah We still have the separate mobile site and we have a web app as well But I think that that's more like an internal legacy sort of thing a lot of these Yeah, yeah, it's not a technical thing and a lot of these things Yeah, if you're starting fresh, you do it completely different But if you've got this big massive website that's already there You know just going from that to say gonna snap her fingers and make it immediately responsive. That's you know Yeah, there's a lot of that so it I don't know. I think Eventually, yeah, it would be great to get there. I think from a performance point of view as well Like say you're if you're supporting every individual browser You can make something really performant in one browser and make it work in that one use case really well the more more things you support The more compromises you have to make Like that that goes for just desktop browsers for example You can optimize to Chrome and say I'm gonna make this work really well in Chrome and not care about IE But every time you support one extra thing you're gonna have to make you know, it might be small Compromises it might be big, but then This team goes for saying if you want mobile on desktop. I think it depends was good enough for your audience And it's the YouTube example of when they shrunk YouTube. They got new audiences Yeah, it's it's whether the Guardian feel that 700k on mobile fits their audience Well, and it I wouldn't necessarily even look at the 700k number, right? That's the all-in. Yeah It's what does it take to deliver your initial experience the visual experience, right? And focus on that if you can get that small enough on both the mobile and the desktop sites with with one Delivery then you're a lot better shape or in with that So come take question from guy and in a minute But just it comes back to does it end the performance arguments against responsive web design I think we're coming to the conclusion that answer is no There's still some arguments for in the gates The responsive or not responsive websites and the m dot sites in the top 5,000 sites It's almost the the responsive websites are but three times bigger on mobile than those of m dot sites Just that m dot naturally lends itself to be more lightweight and fast while in responsive you need to do a lot of work Possibly eventually you can get to the same performance, but I think we're sort of very far from the point where it's just as easy or just as implied And you can also I mean it's not unusual for the m dots Especially the legacy ones not to be doing advertising tracking and all sorts of other things that the business gets when they're doing a responsive one too so you sort of It's true and correlation is not causation and all that but But the reality is that if you look even at anecdotally and pretty much all of the newly launched websites You know it it's hard most of them would have done you know very little at least today We've done a good job at images responsive images are being tackled much more frequently But still at the end of the day There's just a lot more excess as compared to if you were to do something that I think I think one interesting things is What do we need in way of tools or in browser features to be able to build sites in the same way the Guardian have built their sites More ease more to make that easy for everybody rather than just needing somebody with guarded skill set developers And I think that's probably the topic I'm gonna touch on most through the day is it is damn hard to build a fast site and We need it to be easy. We need it to be the default case We need it to be especially like with components. You just drop them on and they're fast right not you have to figure out how to cash in local storage or Figure out how to plug in service workers to cash it if you're offline and Not to not to fetch it if they're not We have two seconds got two seconds left Andrew quick comment I Think it's a really frustrating trade-off because you have on the one hand as Luke says, you know You can optimize one particular agent very well as you try to introduce more and more I think it becomes more and more of a challenge and I think ultimately that's not a scalable challenge because You know, we could we'll talk later in future web about things like wearables and Non-conventional devices and TVs and that kind of thing is responsive web design going to deliver one single solution to all of those things And and could it be performant as well? I think that's very probably very unlikely Okay, who needs to move on to the new topic and the next question is actually from Andrew Bates That's called a seamless segue people Okay, here we go so Do can do concatenation and spriting become anti patterns with the advent of HTTP 2 if so when? And he's got any time velocity presentation on this, so I'll I think we're aware of is what we're doing when we Concatenate and sprite stuff and what we're merging resources together So we're merging say JavaScript together potentially got different rates of change and we're making them all cashable together So if we can split them out then we can cash them individually. So hopefully they live longer in the cash Well, they become a when do they become anti patterns? It's a it's an inch I'm gonna pass on that for me now. I'm gonna come back to that somebody else pick it up You could argue at the moment spriting already is an anti pattern in some circumstances if you're doing it wrong You can have you know forcing users to download a whole sprite when they just need one icon is just that's just a waste of performance for everybody So I'm you know doing it in the wrong way can it can already be an anti pattern and I think HTTP 2 just makes that more obvious rather than Completely changing the ballgame Peter. Yeah, I mean it will be at one point It would be right it will be hard for us as developers when we need to serve both HTTP 1.1 and 2.0 So I mean we need to find the best way to do it. Well, we're kind of doing it now I mean, I know I am at least with this site up it runs PDM website But I I don't really care about older browsers right now. It's a side project. So I mean I can afford to but I mean the way developers are Developing sites today. I mean you've got a lot of controllers or modules You have a lot of different JavaScript files that you kind of divide out to organize your application on the development side, but You know, it's it's a tough question to answer like how how can you support both like speedy today and And and the older browsers that don't support it. I mean, it's It's almost like I don't know. Why would you? Not to concatenate everything. It's gonna save your older, but it doesn't matter I think the challenge is actually when you need it on the page In that if you've got a Webfonts referenced in CSS for example, it's you know the browser has to download the page So we don't know anything about the other resources we need until we download the page then we start parsing the CSS and parsing the DOM building a render tree to decide we need the web font and Then we have to download the web font and wait for it to arrive and the question becomes is Instead of concatenating or inlining stuff in CSS is can we push those resources? Using HP to so can we push the font object early so the font gets there earlier so we can render the page But I don't think it's even just pushing. I mean the the big problem. We're gonna have is knowing When you have to support both, right, but assuming you don't have to support both. It's the The granularity you get by not having to concatenate all of that stuff, right? You'll add all sorts of JavaScript into your main JavaScript file because it's needed on three pages or whatever And all of a sudden you're bloating it and when you break it out and you don't start concatenating You can granularly just pull down what these individual pages need On the browser side the browsers won't parse and evaluate the JavaScript until it's complete So breaking it down into little chunks is nice for the browser as well Same thing goes for the sprite You'll have like three images on there that are needed for some random page somewhere else And you need to rebuild the whole sprite anytime you change one of those I think one thing that can help with this is rather than using a sprite or whatever is if you have something that your Client-side application can understand the individual parts like on the FT web app What we do if we're downloading images is we actually use JSON and have all these JSON images then we we can this the The clients I could can cash each of these images separately and it can handle them separately And if if we need to clear the cash or anything like that We don't have to download the entire spread again because it understands each of these are individual resources It's only for the network bit that we're actually concatenating them then we split them up again Right, but this is all JSON data URIs local storage back to not making it easy. It's horrible to do the right thing We've got a question from the audience Mary Okay, we'll skip that one there to Jonathan Fielding So We'll just talk about would you say that with HTTPS to be one or HTTPS to be two You could perhaps have to have different different assets and like the text on the server side So that people who are you want they're getting sprites still and using that the old anti-patterns ways And then with HTTPS 2 we're pretty out of the cash can actually perform the best it can They're casting the individual images so effectively you're saying you get it's a bit the same argument You know end up with the the m dot version which is going to be the HTTP 2 dot version I'm gonna have a low balance of it since somebody the HTTP 2 pool and somebody's to the HTTP 1.1 pool. I think the You're not going to be penalized at all if you continue your old ways of development They are anti-patterns and they do cause us as developers more frustration, right? But or more work essentially, but um, you're not I don't think you're going to be actually I know you're not gonna be penalized for Concatenating versus not concatenating on the HTTP 2 side, right? Well, you get penalizing cash terms Potentially, but no more so than you get with it speedy pushes to the cash though, right? I mean it pushes straight. Yes, there will be possibly a larger download But I mean what speedy or HTTP 2 once it opens a connection It will push directly to the cash even if you have caching disabled in your browser During this during this I think so the issue if I'm clear is the you know during this intervening period when you're gonna have to Support both protocol. Yeah, it's really it's more for the developers. I think it's more for us to have better workflows and Not have to go jump through so many hoops, and that's kind of what HTTP 2 will bring but I think I mean Automate it you'll have to decide at some point Do you have server-side logic that detects and spits out the HTML because fundamentally it needs to be in the HTML differently for speedy or HTTP 2 versus HTTP 1 or do you look at your traffic mix and you go, okay? Now we've got 70% of our traffic coming in that's speedy or HTTP HTTP 2 capable it'll be slower for the older browsers or the smaller group, but it doesn't break That's you decide at what point do you cut out or you use something like mod page speed that's protocol aware So it will do the optimizations for HTTP one and it'll do different optimizations I know Google had a report out last November about using speedy on maps and drive and a few different properties and they observed like around a 30% increase on all those so I mean at least we have some larger Entities leading the way there we need to we need to move on to the next topic, but just on this on the HTTP 2 just so I mean the timeline You know it's Specifications not even due to be ratified until November You've got to get all of the web server Effectively speedies out there, right? Yeah, I mean he's out there now 11 chrome Firefox. It's effectively all the capabilities are already out there So it's what's your traffic mix? What's your server-side support? And what's your so if you're expecting HTTP 2 to answer all your questions It's probably a way away, but you can start playing with some of the ideas and the technology with speedy Next question Patrick Hammond so as Steve Sout is said in a great blog post in May last year that We need to move past the on-page events and metrics or the unload events and metric and With a lot of us moving kind of enhancements to pass that load event as well, you know What is the new golden metric or is that one Peter or throw that one to you? Yeah, you make you make a tool which measures performance I mean it is speed index that I have in my page test, but we want to move it to other tools and Be able to use it in rum also. I mean we need to know when the content is The bother for content is It's an ace in the browser. I mean that's the important thing or how do you guys see it? Yeah, I mean it's fundamentally If you own the site you're trying to measure Instrument it you are the one who knows what you care about so put on load handlers for your above-the-fold images for example Tag your ads so you know when they load and then beacon all of that stuff back I mean nothing is ever going to be custom instrumentation Doing it generically. That's when you start to get into To difficult cases right if you have if you're a rum service offering something to everyone and trying to automatically Tell them when they're above content is above-the-fold contents complete. That's a much harder Currently unsolved problem Yeah, I mean synthetic. I like speed index obviously, but you really do need to move beyond the Technical point when everything finished because there is so much stuff on pages these days. That's not User-visible all of the ad tracking the analytics. There's even your a b platform testing all sorts of stuff The single page apps that scroll down forever Trying to figure out a generic complete load time metric for pages is I try to encourage people to target start render time So when some of the visitor actually starts to see something in the browser, you know My third option after that is speed index, which measures when the viewport is Complete visually complete and for what it's worth. There is start render in the rum from IE in Chrome It's kind of buried in different places like windowed up performance that MS first pane I think is IE's but is it really want to have a white screen, right? You'll want to make sure it's real for some sites and it's not real for others So you'll want to actually test the pages you're looking at first to see if it's actually a useful metric for you Before you start basing any decisions based on that. It's a quick quick audience poll Who realistically in their websites are sort of using the page on load event as their most common page load metric? No, yes, no first question start with is who actually measures their page load Okay, so only about what about half the audience is actually measuring their page load times Who's actually doing custom instrumentation so they know exactly when they're above the fold Okay, and who doesn't work for the Guardian the FT Okay So okay Christian Christopher Imre JWT. Yeah My question was actually touching on I mean we're going on about using the page on load event as the kind of de facto That's when the page is ready. I mean I work for an advertising company and I've kind of come to peace with that but actually It brings with a lot of actually knowledge and actually an advertising They've actually dealt with this problem about ten years ago And actually in when you're building adverts to specifically digital ones you have polite load It's the idea is the minimum viable content you need on the page to get it functional without distracting the user the end of They add to passive experiences when they're done on the concerted page So the restrictions inherent in that platform kind of mean that we have to be as efficient as possible And actually now when we're doing a lot of sites now, we've done actually some of the very effective kind of responsive sites We take the same thing There's a polite load where she defer everything that we need for about three seconds when the after the page load event the idea That's enough time for someone to click on a menu button and click deeper into the site So they want to so we're not actually forcing the way and this is a strategy that we're using right now it actually works quite effectively and it means that It kind of blows the line like the page isn't ready a page on load But it's actually usable and actually above the fold everything looks the same soon as the JavaScript files after three seconds We then hook into that and then all the carousels start working all the interactive videos and things of that fire up Patrick you got a comment on that That's great. And it's good to hear from an advertising company that actually It means he isn't going to get out of the room alive On that note something going back to to measurement metric something that we've been doing with adverts and we we now that resource Priorities API and timing API is here. We've we're starting to have discussions with our advertising suppliers that so that they can Set the timing allow original Flag so that then we will be able to beacon and measure and on our wrong grass have these statistical data for the load The load time of our person will know when things are going It's very pleasing to hear And contrary to sort of popular opinion you generally do want to get your ads loaded early So your users will see them click on them and you will make money So it's really important that you actually know when your ads are loading though And you know, I've talked to several companies that just stopped loading ads So that they'll get faster page load times and that's the wrong answer, right? It's how do you get your ads not competing with your content, but both loading visually quickly for the users? Because at the end of the day, you still want to make money And more insights like from companies like you but you're obviously not allowed to talk about it But this is like the same problem with flash flash solve the problems that HTML5 has but the information never got out and We probably have a lot of performance stuff in the In the ad space that was never talked about because the competitive advantage over other providers Please I mean actually the previous point we're talking about having Responsive ratio mobile versus a desktop site We actually find because we're building kind of campaign sites So we're doing for brand is like three to six months that lives and then it kind of dies a lot of those because they have a lot of money thrown at them both in media spent targeting to it as well as kind of organic search We find it's kind of a tricky road We were actually finding a lot of times having the dedicated mobile site works because at the end of the day There's a path to purchase that we kind of want the user to do and the desktop might have that rich immersive kind of interactive Visual video experience whatever the might be but actually So actually we're finding a lot of times even though we push for response over time Realistically mobile, you know gives you that direct path to purchase the dollars behind it at the end of that You've got to get the customers products sold So so to summary the answer. Is there a new golden metric? No, it's the one you roll yourself using user timing in the navigation in the Timing API and big it back making it back somewhere where you actually look at it. Don't just Bit like Bitcoin you got to mine your own gold Right next question is from Patrick Hammond This is very similar question, but it's in a different light So how we're now very well equipped to measure our initial payloads performed? with great tools like web page test and and and things like rum But yet we're seeing a rise in large-scale long-living single Page applications, but so do we need new tools? To measure these and new metrics and new visualizations to to measure long-living applications that we're seeing So performance measurement in single page apps user timing well, I mean it's back to instrument Instrument it and figure it out. I mean you've got hopefully the browsers are giving you all of the primitives you need To understand what's going on Especially in the single-page apps as you swap in content as you scroll down and do stuff If you're not getting the primitives you need I know we were talking like a velocity summit a few weeks ago or months ago at this point about possibly adding Load event timing handlers or first paint timing handlers to images and stuff like that To all elements so that you can get the the primitives, but it really does come down to You know what you want to do with your app? Time it beacon it back and if you can't get it what you're what you need Let us know I think it becomes more of a rendering thing too, right? I mean your page is already set up So it's it's about image decoding and making Ajax requests and getting the images and decoding those and Any other transforms you're doing to the page and that's really where it comes into Jank and other kinds of measurements as well Also suspect there's probably some APM vendors in the in the house that would have a conversation about If you go single-page at this doing lots of Ajax requests to the to the back end you know Your sort of that measurement is also going to become more inherently related to the measurements of that round-trip time For that back-end Ajax request and you've got to start tying those two things Titered together for those single page. It also depends if you're if you and waiting on all those Ajax requests like in our web app As soon as because we've gone for we want something that works offline We try and make it when you click stuff you never waiting for an Ajax request, right? We want all the content to be there up front and in advance So it really depends on your your site whether you're doing these click and wait for content to come or whether you're doing something else In the background and that I think that affects what you need to measure as well So you guys are putting everything in local storage, right? Local storage and where we're SQL or So what is like your limit like is there a limit on the content you download like we actually have like It's very complicated. There's different modes and like when you first load We try and just get the basics. So just the article content. We don't bother with all the images and stuff Because on some road well particularly old ones you need a press of prompt to allow like 50 makes a storage or whatever And then we'll go and start doing all the images and stuff but we try and keep all that in the background where possible and It shouldn't we try and not get in the way if the user, right? They should just be able to navigate the app and not come under rendering at that point Yeah, it's all done to rendering but aren't you just generating another problem when they run out of local storage And they have to go from to manage to start managing local storage themselves That If we come back to the to the question about do we need new tools new metrics and new visualizations You're saying if a single page at measuring the rendering of that thing that I've done becomes critical Do we have the tools? I mean Peter you make tools. Do we have the tools to measure that right now? And I think the answer is probably not actually we do but they're manual I mean you have the timeline and dev tools of rendering and painting events But I don't know is that a request animation frame is probably your best friend But back to it's not easy, right? I mean figuring out if your single-page app is behaving smoothly on the client side in rum By hooking together a bunch of wrath calls and looking for jank and that kind of stuff. It's doable But it's complicated So the answer The answer the answer to that to is is yes We probably do need new tools and new metrics and I think with you get to a point where to be honest Sometimes it's best just having a manual test to using it and going. That's a bit sluggish, you know, there's some things that But then you're limited by CPU and whatever your system is running. Yeah, but that's what the user's gonna do at the end of the day That's that's what I 11 as a lazy load attribute for images Is it worth having maybe an attribute for a tag which would be like above the fold But which would basically give the browser a hint that this is your main content that you want to prioritize Well, maybe below the fold you'd have a lazy look there's a combination of the rise or what's going to be above the fold You don't know whenever you're sending the stuff down like where where is that fold going to be if people can There is no fold in the browser Yeah, so that's not a IE specific IU was the first ones to implement it It's a W3C spec for lazy load and I think postpone is the other one or I'll probably get the naming wrong But there's sort of two of them one is Don't load this until later and one is I care less about this And it's sort of the the opposite of saying this is important But you'd have to tag all of your content and it's kind of an attempt to eliminate the JS lazy load Implementations for images while still letting the browser know about all the content and give it priority hints So the this is above the fold and important is basically the stuff on your page that doesn't have lazy load on it But you should start seeing it come out to the other browsers It's part of the same group that did the performance specs I've got about a minute left. I'm gonna take one last question from our last day on the back there If you can run the mic will yell very loudly a lot just Yeah, well for the video So about the single page up topic do we need new tools and new visualizations? Tooling wise so there's there's a couple of rum tools who worked into this there's commercial ones Look into frameworks and I think the story is a two-fold one first of all we need definitely support from Framework vendors because that's how we made it possible We had to interact with them because a lot of their asynchronous logic We have to follow just like typing in a keyword that goes back with an XHR to the server Updates a table and then renders it on the page comes down to framework instrumentation that you would have to do or Frameworks would build this instrumentation right into those frameworks. That's the part. It definitely is I think Where's the framework vendors and they have to do it because they are the ones who know best part of frameworks actually work The other piece to it is What are you really missing is that piece like this with this framework instrumentation? I could to the point like I updated the dumb is really knowing when certain elements have been painted on the screen That would then be something I see in the browser The question may repeat this instrumentation of frameworks And the one and framework should build it in for those who have not built it in You would also have to have some beans in the browser to instrument the browser runtime because that's what you have to do today Because sir round tools are often not able To instrument it while it is sent to the browser But it's a two-fold story the framework story to a great extent and there's two solutions to it Okay And it's also a story when it comes to rendering that really ties down to the browser I've got to move on to the to the next topic, but just to summarize that I think that is a good point You've made there. There's some big sort of Emphasis may be shifting to the framework vendors to really help people understand the performance and and the timing Instrumentation within that framework plus there's also the point you're making about the the browser vendors, but we've got to move on Rich Howard So my question to both the panel and to the audience is What role will automated front-end optimization tools play in our increasingly complex world? Do they add yet another complicated layer of abstraction or will they become an assesity? so feo tools like you know mod page speed or River bedstinger optimizer, I mean you're a you're a fan of varnish. That's a front-end reverse proxy type I think I'd class varnish is different than those sort of things because varnish it behaves like a htb proxy You know it follow by default it'll follow htb headers and it won't do anything weird a lot of these other ones I I get very Hesitant about using things that are just going to do magic in front of any coda, right? I think it's such a large education process for front-end developers as well. I mean especially those that Might just be you know entry level to mid-level it's it's a lot of companies are trying to take care of things like like performance and and security with appliances and plugins and things that go along with the with the web server, so I don't know if it's needed or not. I mean, I don't know if what developers should just know the rules automatically or they need the help So I think there's a beta first. Yeah, I mean I As a developer, I want to know what happens So I don't like these kind of tools because I don't know exactly as I said the magic the magic things about it up It's make me on secure actually, but there's an operations manager Who's been waiting for the developers to speed up the website rages if I can sling 50 grand at Riverbed and it makes my site faster That's the cost of one developer. Well, why wouldn't I do that? Well, give Andy you'll come knock on that chicken I We're trying to optimize for different browsers behaving different ways different devices over different network conditions I think For a certain number of custom people. I think it's the only way to go I think it's because you know, we're trading off the cost of employing developers who may not be doing a great job anyway You know because there are some great developers in the world And there are some very average developers and we see it in the way that pages behave and it's you know If I can deploy an automated device That will speed up that site and give those visitors a better experience then why not? I'll take I'll take coming from from Perry and can somebody refresh on slide because I think it's So Perry stand up and wait for the mic quick All I was gonna say is that I think I agree with Steve and with Andy because I think you know We're getting asked as developers ops web ops wherever we just whatever we do We're getting asked to do more and more and more with less and less and less time to do it And it's actually the business that's going to dictate this I think and I think these kind of automated Tools and devices are going to be the only way that we're going to be able to keep up with so that it's going to be 1.1 we've already we're already struggling just dealing with what we have to deal with now We're talking about later on there's going to be new devices wearable technologies TVs to Concern ourselves with I just think we're gonna have to do and for those of us that are not in the consult performance consulting ring, I guess It's it's hard to get time in companies to work on performance to make your pages faster It's hard to sell a lot of bosses on on doing that as developers who work on an application Or a site that's driven by Whatever advertising dollars, whatever you want to call it with someone else's budget basically and they don't want to a lot for that performance boost I can speak to that personally And I think there's some class of optimizations that you're gonna start getting more comfortable with handing off The one that comes to mind in particular is image transcoding Supporting webp. There's a whole bunch of things that you're not gonna want to have to rebuild an image server And you'll start pushing off to appliances or a service to do for you Because you're not gonna want to maintain libraries of ten different image formats as we get like webp JPEG XR Whatever else comes down the pipe. I think there's a difference between you know Making a conscious decision as a developer saying I want to farm this off to somebody else who's gonna look after me Which is to have just some appliance stuck in front of all your code that does whatever it wants because it thinks it's better We've had problems with mobile operators doing this sort of thing where they're gone like oh that bit of Java script We can optimize that for you. I'm sorry the person who asked this question works for Vodafone well In the early days of the web I was one of the things that caught us off guard and you know Because yeah, I've already just think that they know things better than you But if you're a developer who knows what they're doing Sometimes you know better than the appliance and the appliance just gets in your way I think I think you know will they will they become a necessity or increasingly complex Well, I guess the question is do you see the world? We've talked about components. We've talked about HTTP 2.0. I Don't see the world getting less complex So there's only so much complexity that you can deal with as a developer Surely before somebody's going to say let's hand this off to an automated process that does it better I'm sure guy would say that you know Akamai the next generation CDNs So yes, I'm But I do think that you know two things one as opposed to the carrier proxies the intent here is to be something It's an extension of your platform So it's the same you time it operates based on your instructions granted instead of writing code you're checking a box But you're tuning it and you're configuring it to your needs So not quite as simple as a varnish HTTP instruction, but not that much different than varnish ESI or the varnish Kind of elaborate caching policies So that's just sort of a general thought and yeah, and I think that the point I come come back to every time we talk to To users of this or people considering using it is you know if you can automate it Why do it manually? So the the exact range of where the tools good enough or they aren't good enough what what is your level of comfort? That's something that as a as an industry we still need to evolve and improve But I think at the end of the day if you have a way to do it automatically and it encompasses knowledge and takes away complexity You know the only the only reason not to do so is that you're not used to it, right and you can overcome that 30 seconds if you want to It just wanted to add on to what you're saying It's great that very quickly yourself and try to act as an extension of the platform But actually This is my experience with the kind of clients. I'm doing RMS days don't actually give us free reign on our platform We have to play by their rules So a lot of times what is in our control or things like the build tools Optimizing things down on our end with the guys before we get on to that platform So a lot of times like said sticking to the basics effectively is often the best platform Who could my coffee go over here one last very quick question or very quick comment For me load time is important. Yes, you need to get stuff down as quickly as possible, but what's more important is how quickly the user can see the stuff and that goes through the hardware you're discussing stuff like Batching is bad back. Do you consider the hardware and underline as well? Batching is really good for a GPU So batching a GPU doesn't know how to deal with a sprite though, right? So as far as the browser is concerned the GPU doesn't deal with the sprite the GPU deals with the sprite in a whole Bunch of different places and clips it and doesn't deal with it better than images I'm gonna have to cut that one off and you can take it offline because we've got about five minutes left And we still got a question to go from Paul Lewis, which actually ties in very neatly with Some of it was just mentioned actually My question got tweaked Which is topic of the day so I thought I'd fight fire with fire and tweak it back How should teams balance branding and personality Against performance, and I guess I had web fonts and images and such in mind And how can they meaningfully measure the benefits of branding versus the benefit of speed? Hashtag perf matters on the end hashtag perf matters always good I mean you started to talk about this in the answer to the previous question That you know you come up against a thing the designers want their cool web fonts They don't necessarily want performance, right? It's the same kind of argument as the mobile versus desktop side I guess I mean you have to measure I mean the business knows what it wants whether it's it's a brochure side or whether it's Or it doesn't want its users to drop off because the page load time is is too high or whether there's a lot of jank Going on in the page because they can't scroll down the page and their user base drops because of that so I mean it's it's about do you want better performance or do you want better-looking better-looking site? I guess there's a balance somewhere in between there, but right now you really have to focus on one or the other. I think Who's had this conversation with their business on So who wants to stand up and in reach for a microphone to say we've had this conversation with our business and how this is how we tackled it Patrick go on. You know you want to or next go on and get tag team it Behind you Yeah, we've had this conversation quite a lot actually because the garden So designers like their beautiful web fonts, but mobile users don't like to wait for the text to show up What we've found is that maybe we could find a compromise Maybe you can have the really really iconic fonts in there on mobile, but the the other fonts Maybe you can load them only on desktops So that's the kind of compromise we came up with now But I mean Can I answer Paul's question? Yeah, because the other the thing lots of people do is you know We talk about fonts and how many people just chuck open sounds or a font on the page without considering all the font Glifton it so there are even using web fonts There are optimization options in the take out the glyphs We're not using which takes you know Open sands off Google if you start stripping it down to just font the glyph on glit You need for English it ends up being 60% of the original size Sorry 60% reduction in size So you end up with a much smaller glyph that's quicker to download that you can embed as a day to your eyes So you avoid the round trip, you know, and it's a it's a choice some some brands. It's as a brand Measure what the impact of performance is having and test whether You know, you can take stuff out the page and still keep your brand quality And whether that has an impact on you know, visitor behavior And I think I think sort of this is the worst thing I think maybe the panel I don't know still missing missing the question Which is which is how do you get your business to engage in this conversation? And I think the answer has to be You've got to be able to measure the performance and tie the performance back to the measurement of your site Perry gave a presentation at Velocity this year where he gave some great examples where they were tying it into the analytics They tied it into their adobe omniture So the marketing people could see very clearly that conversion rate changed at this point in time So step one is measure your performance step to measure the performance money step three start doing a B testing of slow versus fast or pretty versus not so pretty and the The key thing there is make sure your performance data is in with the business metrics having them completely separately Where they can't sort of correlate the two to each other becomes a really big problem It becomes difficult to say the extra two seconds is costing you 10,000 users a day kind of thing But if you want to have a conversation just strip out all the web fonts they'll come find you You want to figure out how to start the conversation I just want to say with regards to this I've actually had this conversation with our clients and Because of the type of company I'm in we actually have a lot of media money in terms of TV ads pointing at web properties We actually find that a lot of it actually the conversation about performance is actually being talked to by the client It's actually out of fear And it's actually two sides of the coin. We're talking page of the forms that if the server can handle the load Actually come in as pointless about fonts and stuff like that. So a lot of our conversations actually start off with okay Well, what's the media buy? Okay, we're expecting, you know, it's gonna be on how many TV channels up with that They're gonna drive it to we have to keep the server up So there's that part of it and then on top of that it then becomes a little bit to pack the purchase with regards to Buying a product then it becomes okay. Well, how fast can they do that? Not so much, you know if there's different parts of the site that load a bit slower That's okay depends on that critical path in terms of How fast they can they get to kind of click the buy button So there's my friends the really big friends are talking performance But it kind of comes from a fear factor that they don't want the site to go down They don't want to be a laughing stock and they don't want to lose their kind of value Was the performance of you know metrics how many visitors to how many We're gonna have to wrap it up there I'm sorry to get you not be able to get to your question, but so we're actually reached the end of the session So I think the message there is play the fear uncertainty and doubt card and your site will crash if you put all this stuff on it Which is not not an argument I like from an operations point of view because it's my fault if the site goes down, but anyway, so anyway Thanks very much guys. Thanks to everybody on the panel for contributing. Thanks great contributions from the floor and Yeah