Client Side Performance for Back End Developers - Camb Expert Talks, Nov 2016
•Télécharger en tant que PPTX, PDF•
1 j'aime•741 vues
Slides for a new talk - honestly, an alpha version (thanks to everyone who came for playing guinea pig) - of my client side performance talk. This is very much aimed towards back-end, or full stack developers more used to working behind the scenes, who may be less comfortable with JavaScript and other front-end performance concerns.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à Client Side Performance for Back End Developers - Camb Expert Talks, Nov 2016
Similaire à Client Side Performance for Back End Developers - Camb Expert Talks, Nov 2016 (20)
Dernier
Dernier (20)
Client Side Performance for Back End Developers - Camb Expert Talks, Nov 2016
- 1. Client side web performance for back end developers Bart Read http://www.slideshare.net/bartread/ddd-nights-client-side-performance-for-back-end-developers
- 2. Who am I? • Bart Read, Web, Database, and Mobile Performance Consultant • Previously worked for Red Gate • Contacts • E: bart@bartread.com • W: • www.bartread.com • https://arcade.ly (site on which this talk is based) • B: www.bartread.com/blog • T: @bart_read • GH: https://github.com/bartread
- 5. Partial Browser Page Lifecycle
- 7. Modern web apps are becoming more and more like fat client desktop apps that run in a browser
- 8. Stuff that’s out of scope • The back-end • Front end/SPA frameworks • WebGL • The latest and greatest JavaScript libraries, build tools, blah…zzzzz • ECMAScript 6 (or 7!), TypeScript, etc.
- 9. HTTP/2 If you take nothing else away from this talk, take this
- 10. HTTP/2 • Multiplexing • Server push • Stream priority • Header compression • (De facto mandatory encryption)
- 14. Express.js app with HTTP/2 and SPDY support https://github.com/indutny/node-spdy
- 18. HTTP/2 Platform Support • IIS on Windows 10 and Windows Server 2016 • .NET 4.6.0 or later • Tutorial: http://www.c-sharpcorner.com/UploadFile/efa3cf/creating-http2-supported-website-with-Asp-Net-core-hostin/ • Node/express – spdy module • https://www.npmjs.com/package/spdy • Tutorial: https://webapplog.com/http2-node/ • Java • Go – http2 package • https://godoc.org/golang.org/x/net/http2 • Demo: https://http2.golang.org/ • Ruby • Python • PHP Full list at https://github.com/http2/http2-spec/wiki/Implementations
- 19. Memory usage and GC
- 20. Chrome Dev Tools Timeline
- 21. JavaScript heap usage over time
- 22. Chrome Dev Tools profiling options
- 24. Particle Creation in Star Citadel
- 25. Strategies for reducing JS memory usage • Object pooling rather than creating new objects • Use of prototypes • Reducing closure usage
- 27. Create object from prototype with pooling
- 28. Long Running JavaScript • Intersperse delays • setTimeout(function() { /* Do your stuff */ }); • allow content to render • Web Workers
- 30. CSS Effects • First run of CSS animations is often ropey • Transform/scale/skew • Forcing hardware acceleration • https://www.smashingmagazine.com/2012/06/play-with-hardware- accelerated-css/ • transform: translate3d(0,0,0); • (still necessary in 2016?)
- 31. Tools How to find out how your page’s are performing from a client’s perspective
- 32. Tools • Chrome Dev Tools (obviously) • Speed testers • https://developers.google.com/speed/pagespeed/insights/ • https://www.webpagetest.org/ • https://tools.pingdom.com/#!/
- 33. Housekeeping All the small things true care, truth brings…
- 37. Inline enough CSS to load above the fold content (part 1) https://pugjs.org/api/getting-started.html
- 38. Inline enough CSS to load above the fold content (part 2) https://github.com /VFK/gulp-html- replace
- 39. Inline enough CSS to load above the fold content (part 3)
- 40. Asynchronously load other CSS https://github.com/filamentgroup/loadCSS Before: After:
- 45. Google Adsense scripts (applies to third party scripts in general) <- Leave this inline And load the Adsense script at the bottom of the page, /// after your own scripts
- 48. Don’t get too carried away in <HEAD>! https://developers.google.com/speed/docs/insights/PrioritizeVisibleContent https://en.wikipedia.org/wiki/TCP_congestion_control
- 49. Payload Don’t join the cargo cult
- 50. Do you really need that library or framework? https://developer.mozilla.org/en- US/docs/Web/Reference/API
- 51. Many libraries are componentized Include only what you need
- 52. It’s the latency, stupid! • http://www.stuartche shire.org/rants/latenc y.html • Minimise requests and roudtrips • Sprite or concatenate
- 53. CDNs
- 54. Questions?
Notes de l'éditeur
- With this talk I’m going to talk you through the kind of diagnostic techniques I use for isolating performance problems in .NET and SQL Server web apps. I’m going to start off with an overview of the tools I use, and then go through some scenarios illustrating how to use them. I’m going to focus mostly on the server side but, obviously, nowadays with the rise of the single page app, and mobile devices, the client has become a lot more important performance-wise for a good user experience. How many of you are writing client-side code using a framework such as Angular, React, Knockout, Durandal, Ember or whatever? How many of you are building apps that you expect people to use from mobile devices and tablets? Obviously, particularly for these, performance and resource usage is critical. You often find you can get away with murder in desktop Chrome whereas on a phone your app runs like an absolute dog. I’ll talk about this a little at the end if there’s time.
- I don’t want to spend ages on page lifecycle because apart from anything else you probably already have at least an inferred understanding of what’s going on that probably isn’t a million miles from the truth. But it is worth spending a little time on it so you can see where the topics I’m going to cover fit in, in terms of lifecycle, and therefore better understand why they have an impact. Client side web performance used to be all about page load and to be honest, this is still hugely important, and it’s probably the single biggest predictor of whether users will hang around on your site and whether they’ll come back to it… or not. It also goes without saying that server-side performance impacts the client significantly, as should be apparent from the diagram. So, if you’re running loads of complex logic, database queries, and the like, before you start returning data to the client, well, they’re going to have a bad experience. I do talks on that stuff, but we’re going to leave it to one side for today’s talk and assume that your server is really fast and that you have no performance problems there to focus (largely) on client issues. Nowadays interactivity is becoming ever more important. Often there’s a lot going on with the client in terms of presentation of data loaded on the fly, data binding, validation, visualisation, aggregation, real-time feeds, notifications, along with complex applications: Google Docs and other aps, Trello and similar project management systems, YouTube, MixCloud, Soundcloud Appear.in, Hangouts Office 365 Social networks such as Facebook and Pinterest Games
- Here we can see the basic flow of the browser rendering engine. As content is loaded the HTML is parsed into a DOM tree. Generally this is done in chunks; the chunk size is obviously an implementation detail, but say 8K. The DOM tree is then used to build a render tree. This is really a tree made up of rectangles that have visual attributes assigned to them – such as colour and size. They’re also structured in the order they need to appear on screen (ish). The next phase is layout. This is where the exact position of each node or rectangle in the tree is calculated or assigned to it. Finally the tree is painted so that the user can see it. The important point here is that the render engine doesn’t wait until all the content is loaded and parsed to start this process. As I said, it handles chunks of data, and pushes those chunks through the pipeline as they arrive. This means the user doesn’t have to wait for the entire page to load before they can see any content. In general this is better for the user because, if the page is well designed, they should start to get the relevant information they visited the page for almost straight away. It’s also good for us because we can ensure that the most relevant information is rendered first, in what’s known as the “above the fold” area of the page – i.e., the area of the page the user can see without scrolling.
- Why do this? Take advantage of the power of modern devices Reduce load on server (doesn’t have to generate content) Offer users a richer experience (sometimes even a better experience)
- Recently a new tool has been added to the web performance armoury, in the shape of HTTP/2, which was published as a proposed standard in May 2015. HTTP/2 effectively reduces latency by adding a number of features. Mutliplexing allows clients to make multiple requests over a single TCP connection. Requests can be sent before responses to previously sent requests are received, thus clients can request all required assets for a page in parallel without running into connection limits that apply to HTTP/1.1 (e.g., Chrome only allows 6 outgoing connections to a given host). Server push allows servers to push web assets down to clients before they’ve even requested them. Stream priority allows clients to prioritise assets such as HTML ahead of, say, CSS or JavaScript. This can allow for faster rendering. Header compression involves compressing HTTP headers to reduce bandwidth requirements – this works because headers often contain redundant information. Note that under HTTP 1.1 compressed content can be requested using, e.g., Accept-Encoding: gzip header and specified in the response using the Content-Encoding: gzip header but that the headers themselves are not compressed. The HTTP/2 standard itself doesn’t actually require encryption, but the fact is that all browser vendors only support HTTP/2 over TLS, so it’s basically required. This has been somewhat controversial because honestly, not all sites require encryption and, whilst when you look at a single site, adding TLS isn’t that much hassle, if you have many sites to deal with certificate management becomes a pain. (A pain that perhaps LetsEncrypt can ease, but whilst some love LetsEncrypt, others have had less success, and my own experience with it hasn’t been great – it seemed like more aggro that just getting a certificate through CloudFlare in the end, or just buying one from elsewhere.)
- The great news is HTTP/2 is now supported in current versions of all major browsers. (Hands up who cares about Opera Mini?) Obviously if you do need to support older versions of IE you’re out of luck (sorry).
- Fortunately using HTTP/2 is actually pretty simple. It uses all the same verbs, and request/response layouts as HTTP/1.1, so code changes are pretty minimal. As an example, the above shows some express.js code for creating an app that supports HTTPs.
- Here’s the HTTP/1.1 trace in Dev Tools. Note the staggering of requests. Nonetheless, performance isn’t awful: everything we need to play the game, including sound effects (but not the music) comes down in about 450ms. Note that this is over a very fast corporate network connection. You could probably double all these times on a rural broadband connection.
- And here’s the code for the same app, but now supporting HTTP/2. Disclaimer: this is just going to serve content over HTTP/2, which in itself is an advantage. I haven’t configured server push here, which does require some extra work.
- And here we can see in Chrome Dev tools that HTTP/2 is being used. Note how the requests are grouped together. The top request is obviously for the page. The next group are for the resources that the page loads. Then, after that, the next group are all the sound effects. Almost all of these are loaded using HTTP/2, with the exception of some external resources. Cloudflare actually supports HTTP/2 out of the box. I believe you have to check an option, but here’s what you see when you go to arcade.ly without me having had to do any work: Cloudflare has done it all for me. Above the red line is the content actually required to render the page: HTML, CSS, JS, and images. All loaded in less than 200ms. Note how I’ve strategically ensured that adsbygoogle.js is loaded last. I’ll talk about why in a minute. Below that, above the blue line, are the sound effects and music, none of which are required to render the page, or even play the game. Even so, all the found effects are loaded in around 380ms, with the music taking roughly 1.4 seconds for three tracks totalling just under 6MB – these are by far the biggest contributors to the payload so I load them last, and I’ve prioritised the in game music first (this is mostly because on iOS you won’t get any audio at all until you click a button in the app so there seemed little point prioritising the title screen music). Note that with browsers that support Web Audio, an audio file can start playing before it has completely downloaded, which is handy. Another point related to payload: this trace is for the desktop version of the site. The mobile version loads smaller versions of the music files to allow for the fact that they may be coming down over a 3G or 4G metered connection. And then below that is the mess of all the Adsense crap that gets loaded, which goes on for ages, because people who build Adsense content are I surmise colossally undisciplined. And this is why I’ve loaded adsbygoogle.js last above: there’s nothing wrong with the adsbygoogle.js request itself but, as you can imagine, the same can by no means be said of the content it loads, which is generally a dogs breakfast and will slow down your page load dramatically in a way which you have no control over if you let it start loading before you’ve got all your own content sorted out.
- The key thing I really want you to note here is that, after the request for the homepage, all these requests for other assets are fired off simultaneously. No connection limit applies here.
- Even more striking, all of these requests for sound effects and music, 18 in total, are fired off at the same time. If this were HTTP/1.1 we’d run into that 6 connection limit and these requests would be fired off in batches. See how much more efficient this makes loading these resources. To be honest this is all now happening so fast I could probably end my talk right here and we could all get smashed instead, if you like, but there is a bit more to it than this. Note that I’m not even doing any kind of server push here, which Cloudflare added support for earlier this year. You have to do a bit of work but it’s not too bad. The spdy docs aren’t awesome so I haven’t tried doing server push with it yet, but it’s almost certainly not that hard.
- You’ll find you can get away with murder on this front with desktop browsers, at least some of the time, but on mobile it’s a different story. With interactive apps you’ll start to pay a price in terms of framerate and responsiveness, but in my experience this manifests itself differently on iOS and Android: - iOS (Safari) is quite tolerant of lots of garbage being generated and doesn’t seem quite so prone to suffering with GC pauses; on the other hand high memory usage can definitely lead to framerate issues. - Android (Chrome) on the other hand will exhibit a choppy framerate when you create a lot of garbage; GC pauses are much more noticeable. For an app to work well on both platforms you therefore need to be mindful of, and minimise, the amount of garbage you create, as well as looking to reduce your overall memory usage.
- The Chrome Dev Tools timeline is excellent for getting an overview of what’s going on with memory on your pages, and for visualising garbage collection.
- The blue line shows JS heap memory usage over time, after the app has been running for about half a minute. Note two things: The characteristic sawtooth pattern as memory is allocated, and then cleaned up by the GC. Overall memory usage is steadily growing, suggesting that we are possibly leaking memory. The problem with (1) is that the size of the teeth is about 8MB, which is quite a bit of memory to be throwing around, particularly as we’re averaging about one peak per second. The problem with (2) should be obvious – eventually the page is going to crash.
- CDT’s profiler allows you to get a much more detailed view of what’s going on with memory usage, once you’ve identified that there is a problem.
- This is the Chrome Dev Tools snapshot view. It’s completely horrendous but, if you patiently start digging through objects you can find out what they are (by looking at their properties), and where they’re allocated.
- So anyway, after quite a lot of digging around what I found is that a lot of the objects we’re creating are particles. These are used for things like bullets, explosion, the thrust effect coming out of the back of the player’s ship. It’s not just the point particles either; the same type of object is used for the larger, expanding circle effect, which I’ve called vapours. Problems: We create a new particle object every time this function is called – it would be better to use object pooling, only creating new instances when we run out of existing unused instances. Because we’re using a closure, we also create new instances of the isLive() and move() functions. As well as not pooling, we’re also not using a prototype, which could be used to create only one instance of the functions on the particle Overall this means we’re being incredibly wasteful, especially when you consider that we can create hundreds, occasionally even low thousands, of these objects every second.
- Here’s a simple object pool implementation. Btw, if you think that looks suspiciously like angular 1.x boilerplate at the top, that’s because it basically is. When I started working on this I thought it would be fun to write an article, or do a talk, on creating games with Angular. I shortly realised that this was a blatantly insane thing to do because Angular was adding nothing but bloat and execution overhead. By that time I couldn’t be bothered to change all the boilerplate so I quickly coded up an injector that behaves very much like the Angular 1.x injector. At some point I’m going to shift over to another module format but, of course, the more code I write, the less I can be bothered to. Anyway, back on point, the way this works is you supply a constructor function which builds new instances of the object you want. You could just supply a prototype but I think this is more flexible, because you can wrap up the prototype creation in a function and customise the instance you create in any way you choose. When you want an instance of your object you call create(), which will try to pull an object out of the pool. It will only actually create a new object for you if it doesn’t have any left in the pool. When you’re done you call release() and pass in the object you’ve finished with. If you don’t do this, create() will just create new objects all the time. Generally you’ll want a pool per object type: so particles, asteroids, etc. We structure the pool as a linked list, not an array? Why? To avoid array expansion and the creation of more garbage when this happens. Also, we’d end up using it like a circular buffer and that’s kind of a pain in the butt compared with pulling the first item in a linked list.
- When using the 2D context for rendering to the HTML5 canvas, it’s generally quicker to blit images than draw vectors using the primitives provided by the context. Star Citadel uses vector drawing. Shoot The Rocks, because there can potentially be dozens of asteroids on screen, uses pre-generated bitmaps for rendering, which performs much better. You can verify this for yourself by running the Canvasmark 2013 benchmark in your browser or on your mobile device.
- Worth pointing out that a lot of the benefit of implementing these rules will fall to mobile users who, unless they’re connected to WiFi, often have higher latency Edge, 3G, and 4G connections to contend with, though obviously 4G and LTEE can be very fast.
- Excessive redirects are a pain in the neck for users because they slow down page loads, *can* break back button navigation, and are genuinely a nuisance. Historically sales and marketing people love them because they provide even more opportunities to track peoples’ behaviour on your website and in your sales funnel. Fortunately the golden age of multiple redirects was probably ended 4 – 5 years ago amongst most intelligent people, although you’ll still find sites on the scuttier end of the internet (like these clickbait black holes that facebook have recently spanked) that still use them. Even a single redirect slows down browsing though because it adds another roundtrip. But generally on landing pages you want your users to see content as quickly as possible so they don’t get bored and go elsewhere. First impressions last. So putting a redirect on a landing page is really an awful thing to do. If you do want to show users different content depending on how they arrived at the landing page, or where they are in the world, or the value of some parameter in the query string, that’s cool, but figure that stuff out on the server-side in as few a branch points as possible and send back the right content. Preferable pre-compile that content so the overhead isn’t much more than a request for static content. Legitimate uses for redirects include redirecting people to HTTPS, in which case you’ll want to use a permanent redirect. If you *must* redirect from a landing page, do so with a permanent redirect (like the starcas.tl redirect above). Note that the only reason I’ve used a temporary redirect at the bottom is because there really *should* be some homepage content; I just haven’t got round to creating it yet. But understand that this isn’t good practice. A completely non-legitimate use is to redirect mobile users to a specific mobile site. A much better approach is to use responsive web design to offer the best experience to users regardless of device. A great example of this is the BBC News website which shows exactly the same site to both desktop and mobile users and, I believe, was designed for mobile first. As such it’s one of a relatively small portion of sites where the mobile browsing experience doesn’t suck balls.
- Again, I mentioned redirecting to HTTPS as a legit reason for redirecting, and I’ve illustrated that here. Note that my redirect behaviour differs for debug and release. I’m also checking for blocked referers to reduce the chance of my analytics getting filled with cruft and, as you can see, I’m not sending back a terribly friendly response.
- Compression obviously reduces the amount of bandwidth your content uses. It also (obviously) won’t do anything to improve latency. Worth pointing out that we’re talking here ONLY about content compression, not header compression. Only HTTP/2 offers header compression, so worth supporting it if you can (remember: all current versions of major browsers already support it). Particularly important for mobile devices as they may be using metered connections. Compression is easy to switch on, as you can see from this Node sample, and the IIS settings exposed through inetmgr. The node sample uses: https://github.com/expressjs/compression. If you visit the GitHub page you’ll see that you can tweak the behaviour in various ways. With IIS it’s all just point and click, and is again configurable, albeit that the options are different. Note that proxies and AV software can interfere with compression, and may request content uncompressed. Not much you can do about this but something to be aware of when you’re performance testing your website.
- You want to avoid blocking rendering by loading external CSS sheets to display your above the fold content. Thus include just enough CSS to display this content without triggering glitchy relayouts/reflows when the rest of your CSS loads later. But don’t include so much that you end up with loads of non-visible content at the beginning of your markup. This is actually a pretty fine line to walk so I’d say don’t get too hung up on it unless it’s a problem. On the relayout/reload front, this is something you often see on mobile versions of clickbaity sites people post links to on facebook. It’s the kind of situation where you go to tap a link on the site and then suddenly find that the page has moved around and there’s now an ad under your finger, and that opens up another site or fires up the app store, or some other low grade scummery. This might be because the people who built the site suck at being web developers and didn’t have the sense to preallocate space for the ad on the page, or it might be because they’re massive scumbags without the balls or the imagination to become international drug traffickers, or it might be a combination of the two. The point is: don’t do this. It’s really annoying for users, and makes your site seem slow to load and generally crappy. So I’m using pug (formerly jade) templates for my pages because it’s just a convenient way to share chunks of markup and styles around between different pages with easy support for overriding. And you can see here with these slightly odd comments in the template that I want to insert some inline styles here. This isn’t actually anything to do with pug at all, but rather with gulp-html-replace.
- So here’s an extract from my gulpfile. Here we have a couple of tasks, plus a function that’s used by multiple different markup processing tasks for different games to substitute a bunch of CSS and script information into the markup that pug spits out. In this case I’ve just trimmed it down to one substitution for the inline styles.
- Loading CSS synchronously will block further rendering until the CSS has loaded. Therefore it’s generally recommended that you load CSS at the bottom of your body. This is all well and good but (a) you probably want at least some styling on your page to begin with, and (b) wouldn’t it be nice to load it asynchronously? Fortunately most current browsers support preload, which allows for the asynchronous loading of CSS… albeit that JavaScript is required to handle the onload element. Depending on the type of site you may or may not care about this. If you do, include a standard link tag inside of a <noscript> block. This will background load CSS and then apply the styles once the file has loaded. Be careful this doesn’t lead to ugly glitches/relayouts/reflows. If you care about older browsers, use the loadCSS polyfill, which will detect all of your preload links and load the CSS in the background for you.
- Javascript, especially stuff that needs to load synchronously, should be loaded last. Here you can see the top two JavaScript files relate to Star Citadel and are loaded synchronously. Why am I loading them synchronously rather than asynchronously? (They do work async, btw.) Two reasons: Google Adsense Social media integrations (like button, G+ button, twitter) I want my game initialisation code to run, which will create procedurally generated content, fire off requests to load sound effects and music, and show the main menu, BEFORE all the social media and adsense stuff. Why? Because otherwise they’ll interfere with the game appearing: it’ll take longer because of all the other stuff happening, and both those social media buttons, and Adsense are SLOW.
- Note that document content loaded fires in a mere 676 milliseconds. See the red line? That’s where we can render the page! Then we get a big block where the sound effects come down… and then we get all the other guff related, mostly, to adsense.
- And it goes on…
- And it goes on… for nearly 4 seconds. And this isn’t even bad. Not even close to bad. Some of these adsense ads take two or three times that long to sort their lives out, and spew a load of errors out to the console in the process. I’m not kidding. (I can’t comment on what other ad networks would be like but, suffice to say, there are quite a few crappy ad providers on Adsense. I’ve had to block a couple because they’re so poor.) Now if I loaded my scripts asychronously the adsense stuff (mainly), and the social buttons (secondarily), would interfere with the execution of those scripts. The page would take noticeably longer to load and display interesting content. So load your ads last. There’s not much you can do with adsense here because most changes are forbidden but you can at least remove the redundant <script> tags that load the adsense script, and move the one remaining script tag to the end of the document. (Btw, it’s not the adsense script itself that’s at fault, it’s the ads themselves.) To my users the content is more important than the ads, so I want to load the content first. If you don’t have to worry about ads, you might want to load all your JS asynchronously. Note though that if the order of loading or execution is important that async doesn’t guarantee anything. Defer does supposedly guarantee execution order, and executions scripts before the onLoad event for the document, but there have been bugs here so I don’t really trust it. You can use defer and async together for browsers that don’t support async but do support defer. If async is supported it will override defer.
- Worth a mention on its own because this applies to any script you don’t have control of in general. You can split the adsense code into two chunks so… LOAD THE JAVASCRIPT LAST! OH, FOR THE LOVE OF PETE, LOAD IT LAST! WAAAAAAAAH!!!! If it’s not under your control, and it’s not key content for your page, make it the lowest priority. Make sure you also preallocate space for any content that’s going to be loaded in order to avoid reflows, which are extremely irritating for users (especially on mobile). AFAIK this isn’t (it certainly wasn’t) against their ToS. Doing stuff like loading their script via XHR definitely is against ToS, and in any case doesn’t work (I tried out of curiosity) so don’t bother with it. Btw, if third parties are going to be douchebags about this and insist you do stuff a certain way, I’d be looking for some alternatives.
- Another thing that you can do is inline small JavaScripts. These will be executed as the page loads, and will block rendering whilst they execute, but they won’t have the added overhead of loading. You can see here I’ve inlined a script that displays the loader message, as opposed to the message that appears when people have JavaScript disabled (meaning that arcade.ly games won’t run). Loading these two lines of code from an external script file would be insane. (That being said, you can obviously take advantage of your templating engine to insert this script, or use something like html-replace during your build, so you’re not repeating yourself all over the place.) (If you’re using a framework I wouldn’t recommend inlining it but you may wish to consider rendering the first cut of your page on the server, ideally precompiled, and only then use client-side templating with your framework.)
- This isn’t going to change the world but DNS lookups *can* sometimes take a while; anywhere from a few tens of milliseconds to a few hundred milliseconds (or worse), depending on latency, and whether or not you’re using BT’s DNS servers. Ideally they only take about 1ms for locally cached results. Assuming that lookups are going to take longer, DNS prefetch forces your browser to go and look up the addresses of domains for resources that you’ll use elsewhere in the page. This means that, hopefully, by the time it gets to the point where it’s loading the resource it’s already completed the DNS lookup that it would otherwise still have to do.
- https://developers.google.com/speed/docs/insights/PrioritizeVisibleContent Don’t go mad sticking loads of stuff, like CSS, in <head> because you want to get your above the fold content before the “initial congestion window” bites. According to Google (above link) this is about 14.6kB compressed content. This relates to TCP congestion control. You can find out more at https://en.wikipedia.org/wiki/TCP_congestion_control. If you go over this it can result in another round trip to the server, if congestion is detected. On mobile devices this can really kill your page load time. Here we don’t really have a problem – although this document <head> looks quite large it actually only weighs in at about 3kB uncompressed, so we’re well inside the limit.
- This applies to JS libraries, such as lodash, as well as to CSS resources such as Bootstrap. Don’t just speculatively dump a load of stuff in to your projects because this is how you end up with 1.5MB of JavaScript for a mobile site.
- A CDN can be a mixed blessing. You need to test, because they’re not necessarily faster, but they can certainly be useful when you have varying levels of traffic, and traffic coming from different areas of the world, but perhaps only servers in a single geo. CDNs also won’t help that much where you have a ton of requests for very small resources, that you could perhaps sprite up.