12 ms·
A Guide to Fast Page Loads
- krat0sprakhar 11y agoThis is damn helpful! Thanks for sharing. If you're interested in getting to know more about how other sites perform and how to use chrome devtools to address frontend performance issues, Google developer - Paul Lewis recently started a series on Youtube called Supercharged. Here's the first episode - https://www.youtube.com/watch?v=obtCN3Goaw4 https://www.youtube.com/watch?v=obtCN3Goaw4
- nateberkopec 11y agoI am heavily indebted to Paul Lewis and Ilya Grigorik's writing, which provided much of the source material in this article. Anyone interested in further reading on the topic should check out anything by those guys, they're the foremost in the field.
- daleharvey 11y agoThis is a useful guide, however there is one thing missing that will have an order of magnitude improvement over anything that is mentioned. Use appcache (or service workers in newer browsers). Yes appcache is a douchebag, but its far simpler than going through all of these and will have a far bigger improvement
- nateberkopec 11y agoNeat - I've never used it. I thought appcache only really helped "offline" web apps. How can it speed up ordinary sites?
- daleharvey 11y agoBrowsers make a best attempt at caching, but they dont have a lot of information to go on huge amounts of data that may be able to be cached and the only way to check if its out of date is by going over the network. Appcache / service workers give you more absolute control over that caching, generally once data is cached it is loaded immediately from disk forever thereafter (and updated in the background when needed).
- james33 11y agoI can testify to this, we use appcache for our HTML5 game and it massively improved load times. However, if you are going to use it, be absolutely sure you know what you are doing. There are easy ways to mess up and no going back if you do.
- deleted 11y ago[deleted]
- roflc0ptic 11y agoIf you're wondering why this got downvoted, I did it accidentally. Appcache looks interesting, though. Thanks.
- forgotAgain 11y agoAppcache may not be the best approach for new work. It is deprecated and not recommended for future use. https://developer.mozilla.org/en-US/docs/Web/HTML/Using_the_application_cache https://developer.mozilla.org/en-US/docs/Web/HTML/Using_the_...
- brazzledazzle 11y agoIt says that service workers are the replacement but on the service workers page cautions that they are experimental technology and the spec isn't finalized[1]. If you're deploying a new application which should you use? [1] https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers https://developer.mozilla.org/en-US/docs/Web/API/Service_Wor...
- daleharvey 11y agoI use service workers for side projects that only target new browsers, and appcache for everything else.
- mtberatwork 11y agoService Workers is a definite game changer. However, one thing to remember when implementing them is that you will need to be entirely on HTTPS.
- dspillett 11y agoThat is a pain. I've got a project in early stages that is using AppCache to deal with disconnected use, and AppCache's replacement isn't commonly available yet. Then again I'm using AppCache as lightly as possible to get around some of the issues people report, essentially managing my own cache in one or more of the local storage options and just using AppCache for the stub that primes/updates the core code in that cache, so switching to using another option just as lightly might not be difficult. I'll have to read around Service Workers and make sure I'm not arranging to shoot myself in all three feet...
- moron4hire 11y agoIn my experience, appcache only improves second loading time. You need all of these other techniques to improve first loading time. 2nd time is much, much less important to optimize, because returning users have already gotten through the annoyance filter, know what they are in for, has at least subconsciously accepted the necessity of the load time they experienced the first time. It's nice they won't have to experience it a second time, but if first-time loading is very long, your second-time users are going to be much fewer. I had written quite a bit here on the sorts of things that I do to make very short time-to-first-view sites, but basically the techniques all fall in place if you setup Google Analytics and use their Page Speed Suggestions. You should be able to get to 95% on mobile, 98% on desktop (I lose points on some 3rd party scripts I've included for order processing, so I can't get around it.). It will be a bit difficult your first time, but after that you will know what all the tricks are and future sites you will just make "right" the first time.
- JoeAltmaier 11y agoConfused; won't the second user experience faster page load with appcache?
- nostrademons 11y agoAppCache is client-side; it caches a certain set of URLs in your browser so that they are available with no HTTP request. It doesn't work until your browser has hit the page once, downloaded the cache manifest, and saved the files.
- seanwilson 11y agoLoading more than just the first page the user visits quickly is still really important though. If each link the user visits is slow they're more likely to leave the site and that reduces your chance of a conversion.
- moron4hire 11y agoThat has nothing to do with appcache specifically. You'll get that with regular, ol' HTTP cache control.
- blowski 11y agoThanks - a well-written article with some really helpful pointers.
- thekonqueror 11y agoI have been using AppTelemetry plugin for rough numbers on each phase of request. This is much better for performance tuning. Do you have any tips for optimizing PHP, where server response times are poor to begin with? I've been trying to optimize a blog as proof-of-concept[1] but it has plateaued at 1.5s load time. [1] http://wpdemo.nestifyapp.com/ http://wpdemo.nestifyapp.com/
- Gigablah 11y agoYou are probably not going to get decent response times with PHP, especially if you're using a framework. If you've already taken care of the basics (opcache, PHP7 or HHVM, WP-specific caching plugins, etc) you would have to settle for techniques such as nginx microcaching [1], which can drop your responses to around 10ms. [1]: https://thelastcicada.com/microcaching-with-nginx-for-wordpress https://thelastcicada.com/microcaching-with-nginx-for-wordpr...
- thekonqueror 11y agoWow. Microcaching reduced response time from 25 ms to 3 ms. Thanks!
- timbowhite 11y agoAny tips on how to handle site layouts that depend on the js that is asynchronously loaded via the async attribute? Seems like this can cause a flash of unstyled/unmodified html while that js is loaded and executed.
- bshimmin 11y agoUse CSS to hide the unstyled content, and then JavaScript to remove that styling and display it. This will, of course, invoke the ire of those who browse with JavaScript disabled.
- paukiatwee 11y agoHow I did it is begin with .no-js class and using Modernizr to remove the class so I can style element for .no-js .my-class -> visibility: visible and .my-class -> visibility: hidden then finally using JS to remove visibility css. So if .no-js class is available (when browser disabled JS), .my-class element still visible. If .no-js is not available (when browser enabled JS), .my-class element will be hidden and visible by your JS See http://stackoverflow.com/questions/6724515/what-is-the-purpose-of-the-html-no-js-class http://stackoverflow.com/questions/6724515/what-is-the-purpo....
- nostrademons 11y agoIf you can, pre-render the initial page load into HTML on the server, then attach the JS event handlers after the page has finished loading. Both Google Closure (via Closure Templates) and React (via Node.js) have functionality for this. If you can't, you can often load a skeleton containing just the HTML & CSS for page layout into the browser, and then fill in the content via JS later. The user cares about responsiveness; if they see the basic structure of the page load, even if there's no content yet, it'll feel more snappy than a page which waits for all the JS to download before rendering anything.
- ohitsdom 11y agoGreat technical details in this post. When speeding up page loads, I usually struggle with: > You should have only one remote JS file and one remote CSS file. I get this in theory, but it's difficult in practice. For example, this post has 7 CSS files and 13 JavaScript files. Also, combining all resources includes assets that aren't needed (CSS rules used on other pages), and also reduces the utility of public CDNs and browser caching.
- nateberkopec 11y agoHa, I should totally fix that. The site uses Jekyll, not Rails, which I'm used to getting the asset pipeline for free with! Combining all the resources will include assets that aren't needed. Part of the reason I made the post about profiling with Timeline was so that you could test tradeoffs like this for yourself. I don't know what you mean by reducing the utility of CDNs and caching though - surely having only one file actually increases the use of browser caching, since the browser will only make 1 request for CSS and serve the cached copy for every other page?
- nordsieck 11y agoHe's implying that other sites may use the same popular Javascript libraries, so they may already be in the browser cache, before the first page load.
- moron4hire 11y agoI've never understood why this was a good argument, because it just ignores that there are still going to be a lot of people who hit the worst-case scenario. When optimizing page-load time, you should always optimize for the worst-case scenario, not the best-case.
- adanto6840 11y agoIt really depends on your use-case & what you're doing. In many cases you will likely want to target ~ 95th percentile or similar.
- humbleMouse 11y agoLOLZ @the layout thrashing gif! Nice post though, very informative.
- camperman 11y agoVery helpful stuff but I did go to The Verge and look under the timeline. Scripting was a fraction of 1% of the load time. Have they disabled it because of your article or am I missing something?
- nateberkopec 11y agoHmm, you must be. Here's my timeline for theverge.com: http://imgur.com/SOpXFZc http://imgur.com/SOpXFZc Steps: go to theverge.com, open Timeline. Hit CMD-SHIFT-R for hard refresh, which will automatically trigger timeline. Wait. When the load event fires, Timeline will stop recording.
- camperman 11y agoOuch - OK, now I got it. Yeah that's terrible. Scripting is double loading, rendering and painting combined.
- tedunangst 11y agoOn a static HTML site with no scripts or external resources, I see 100ms of loading/painting in the beginning, then 3000ms of "idle" time at the end, which turns the flame graph into a pixel wide column. What is the point of that?
- nateberkopec 11y agoSomething is delaying the load event. You'll have to dig deeper to see what's holding it up - probably a network request for an external resource.
- tedunangst 11y agoNo resources. Happens on example.com, too, fwiw. Weird. Oh, well.
- Semiapies 11y agoDouble-check that you're disabling extensions.
- deleted 11y ago[deleted]
- zeveb 11y agoPure HTML loads ludicrously fast these days—as in, well-nigh instantaneously. With a single CSS file, you can make it quite attractive. Eschew JavaScript unless you really, truly need it.
- nateberkopec 11y agoI ragged on The Verge for taking 200ms to parse HTML, but if that's all The Verge was, it would be a ludicrously fast site. It's the 3.5 seconds of JS evaluation that tanks the site 's speed.
- mwcampbell 11y agoTo be clear, you're saying that Chrome takes 3.5 seconds to evaluate the JavaScript, not download it, right? And what kind of processor (e.g. Intel model number) is that on?
- dfar1 11y agoWhat website nowadays you do not ever truly need JS?
- sotojuan 11y agoMost websites whose primary use is conveying information and documents.
- zeveb 11y agoIf you're displaying text, then you don't need JavaScript. If you're displaying images, then you don't need JavaScript. If you're displaying short animations, then in theory you don't need JavaScript (I don't know how widely support APNG is though). If you're displaying movies, maybe you need JavaScript? I don't know if HTML5 video can work without JavaScript (it ought to be able to, but lots of things which ought to be aren't). If you're accepting user comments, you don't need JavaScript. Forms work just fine without it. If you're accepting user votes, then you don't technically need JavaScript (but the experience will probably be better with it, unless you're smart). Really, it's hard to see what one truly needs JavaScript for. Slowing down pages, sure. Destroying your readers' privacy, certainly. Getting root on your readers' computers, no doubt.
- dates 11y agoThat was awesome- thanks!
- some1else 11y agoThis guide is a comprehensive explanation of Chrome's Network timeline, but the optimisation recommendations are quite skewed towards the front-end. There's a missing piece on server configuration, no mention of CDNs or asset/domain sharding for connection concurrency, server-side or client-side caching. It also doesn't take into account HTTP/1 vs. SPDY & HTTP/2. For example, loading JavaScript modules as individual files can improve performance for SPDY & HTTP/2, because changes in individual files don't expire the entire concatenated bundle. Here's a slide deck called "Yesterday's best practices are HTTP/2 anti-patterns", that re-examines some of Nate's advice: https://docs.google.com/presentation/d/1r7QXGYOLCh4fcUq0jDdDwKJWNqWK1o4xMtYpKZCJYjM/present?slide=id.p19 https://docs.google.com/presentation/d/1r7QXGYOLCh4fcUq0jDdD...
- schneems 11y agoCheck his previous posts, he does lots of work on backend speed. If you put all that advice into one post, it would be pretty overwhelming.
- some1else 11y agoFor anyone that's interested, here's a guide on scaling Ruby servers to 1000RPM, written by the same author: http://www.nateberkopec.com/2015/07/29/scaling-ruby-apps-to-1000-rpm.html http://www.nateberkopec.com/2015/07/29/scaling-ruby-apps-to-....
- cbsmith 11y ago...and if you do HTTP/2, you'll get even faster loads if you pretty much break all those rules (some notable exceptions).
- nateberkopec 11y agoTrue, but that's a post for another day. We've still got another year or so until HTTP/2 gets mass adoption.
- _ZeD_ 11y agothe page it's too slow to load... i waited solid 5 minutes... and... still... nothing... to... see...
- snomad 11y agoQuestion about the 1 CSS/JS file rule. If you have a 'My Account' section w/several unique rules (say 10k), which is best? A) One website CSS (main.css) and your users download the My Account rules even though they may never use them B) 2 CSS files are used for My Account (main.css and myaccount.css) C) 1 file under My Account that incorporates the main and section rules (main-plus-myaccount.css)?
- alexrage 11y agoIt's a case where you should use your best judgement. You may want your marketing landing page to load faster, so probably wouldn't include your account section css there. You can also lazy-load the My Account assets on the login page.
- RussianCow 11y agoDepends on how likely the user is to go to their account when they're logged in. :) Generally, I'd say split that into two stylesheets, especially if your site allows access to people without accounts, since non-users would be downloading the account styles for no reason.
- temo4ka 11y agoIn the case of 10 Kb files those approaches won’t make any noticeable difference. But when you have large code bases consider how often changes would be made to them: in most cases it is sensible to split your files into two bundles — one for libraries or files that are not going to be updated any time soon, and the other for project-specific code, that is very likely to be tweaked in the course of the time following the release of the project. Thus you leverage caching and don't force the users to download the whole CSS or JS codebase every time you make some small adjustment.
- outworlder 11y agoI like this guide, with the caveat that, if you are doing a single page web application, some of it gets turned upside down. For instance, the "javascript will be loaded on every page load" part no longer applies. It will be loaded only once, and will fech whatever it needs from then on.
- FLGMwt 11y agoUdacity has some really awesome free courses from Google devs about this: Website Performance Optimization[1] and Browser Rendering Optimization[2] [1]: https://www.udacity.com/course/website-performance-optimization--ud884 https://www.udacity.com/course/website-performance-optimizat... [2]: https://www.udacity.com/course/browser-rendering-optimization--ud860 https://www.udacity.com/course/browser-rendering-optimizatio...
- eatonphil 11y agoCould someone explain this paragraph? I feel like it is making a lot of assumptions or generalizations about the use of $(document).ready();. I do not follow what he is trying to say: > Web developers (especially non-JavaScripters, like Rails devs) have an awful habit of placing tons of code into $(document).ready(); or otherwise tying Javascript to page load. This ends up causing heaps of unnecessary Javascript to be executed on every page, further delaying page loads.
- eatonphil 11y agoNevermind, he explained this again more clearly in the TL;DR. > Every time you're adding something to the document's being ready, you're adding script execution that delays the completion of page loads. Look at the Chrome Timeline's flamegraph when your load event fires - if it's long and deep, you need to investigate how you can tie fewer events to the document being ready.
- fauria 11y agoI really recommend "High Performance Browser Networking" book by Ilya Grigorik, it digs deep into the topic of browser performance: http://chimera.labs.oreilly.com/books/1230000000545/index.html http://chimera.labs.oreilly.com/books/1230000000545/index.ht...
- bzbarsky 11y agoThere's a lot of good advice here, but also some misinformation. First of all, a script tag will block DOM construction, but in any sane modern browser will not block loading of subresources like stylesheets, because browsers speculatively parse the HTML and kick off those loads even while they're waiting for the script. So the advice to put CSS before JS is not necessarily good advice. In fact, if your script is not async it's actively _bad_ advice because while the CSS load will start even before the JS has loaded, the JS will NOT run until the CSS has loaded. So if you put your CSS link before your JS link and the JS is not async, the running of the JS will be blocked on the load of the CSS. If you revers the order, then the JS will run as soon as it's loaded, and the CSS will be loading in parallel with all of that anyway. Second, making your script async will help with some things (like DOMContentLoaded firing earlier and perhaps getting something up in front of the user), but can hurt with other things (time to load event firing and getting the things the user will actually see up), because it can cause the browser to lay out the page once, and then lay it out _again_ when the script runs and messes with the DOM. So whether it makes sense to make a script async really depends on what the script does. If it's just loading a bunch of not-really-used library code, that's one thing, but if it modifies the page content that's a very different situation. Third, the last bullet point about using DomContentLoaded instead of $(document).ready() makes no sense, at least for jQuery. jQuery fires $(document).ready() stuff off the DomContentLoaded event. The key thing for making pages faster from my point of view is somewhat hidden in the article, but it's this: > This isn't even that much JavaScript in web terms - 37kb gzipped. Just send less script. A lot less. The less script you're sending, the less likely it is that your script is doing something dumb to make things slow. [Disclaimer: I'm a browser engine developer, not a frontend or full-stack web developer.]
- nateberkopec 11y ago> In fact, if your script is not async it's actively _bad_ advice because while the CSS load will start even before the JS has loaded, the JS will NOT run until the CSS has loaded. If you revers the order, then the JS will run as soon as it's loaded, and the CSS will be loading in parallel with all of that anyway. Scripts without an async attribute will cause the browser to stop where it's at in the DOM and wait for the external script to download. The browser will not start downloading any stylesheets that come after the script tag until that's done. This is all straight from Google and can be verified in Chrome Timeline. https://developers.google.com/speed/docs/insights/BlockingJS https://developers.google.com/speed/docs/insights/BlockingJS > So if you put your CSS link before your JS link and the JS is not async, the running of the JS will be blocked on the load of the CSS. Downloading CSS isn't required to fire DomContentLoaded, so most browsers will download it in a non-blocking fashion. Chrome does not behave in the way in which you describe, which is shown plainly in the article. Again, this can be verified in Chrome Timeline. All that said, I'm curious as to what browser engine you work when where what you said is the case - I don't doubt it, but you're not describing the way Chrome (and, I suspect, Webkit) works. Right-o on the bit about DomContentLoaded, will fix.
- pranaya_gh 11y agoGoogle just came out with the AMP project. It looks like google is encouraging publishers to join its initiative in the same way how it herded everyone to get "responsive". At the end of the day, good news for mobile web - https://techbullets.com/ https://techbullets.com/
- arohner 11y agoGratuitous plug, my startup, https://rasterize.io https://rasterize.io, will give you most of the information in the chrome timeline, for every single visitor to your site. It also analyzes the page and detects a lot of these warnings, and alert when you introduce things that slow the page down. It's in beta, but contact me if you're interested.
- mahouse 11y ago"bare-metal Node.js"
- yAnonymous 11y ago>47 requests, 7.474,76 KB, 4,68 s That's on a 100Mbit connection.
- binthere 11y agoHad to disable the font of the website, it's terrible for reading.
- nateberkopec 11y agoI wish I could find a font everyone liked that isn't Helvetica :(
- binthere 11y agoThat's not the problem. When I view on a Apple device it looks good. I use Windows 10 at home and I just couldn't read it.
- CosmicBagel 11y agoGifs in the sidebar, 10/10
- pstuart 11y agoOnly the first cycle. After that they're 0/10.
- dfar1 11y agoThe best explanation of the timeline tool I've ever found. Thank you!
- RegW 11y agoPotentially dumb question from a backend dev: Is there a way to get stats about page loading from Timeline, that could be used to automatically ensure that the load times are not creeping up, and breaking NFRs?
- nateberkopec 11y agoSure, check out the Navigation Timing API: https://developer.mozilla.org/en-US/docs/Web/API/Navigation_timing_API https://developer.mozilla.org/en-US/docs/Web/API/Navigation_...
- resca79 11y agoAnother small advice, but less generic, could be to not include all css and js libs of bootstrap, that is modular. I'm mentioning bootstrap because it is the standard de-facto of many web apps. Just spend 5 minutes selecting only the packages that you really use inside your webpage, you can drastically reduce css and js file size
- dasil003 11y agoThis is a really nicely put together article, and I'll even admit the animated gifs are funny, but damn if they don't make it impossible to focus on reading the text.
- jakub_g 11y agoOne thing that might be non-obvious is that async script, while not blocking `DOMContentLoaded`, blocks `load` event. It means that if you have listeners to `load` event that are doing stuff, you may want to have the `load` event as fast as possible. Also, until the load event is raised, browsers display a spinner instead of page's favicon. Hence for non-critical third-party scripts, you may prefer to actually inject them in JS in onload handler instead of putting them directly in HTML. A semi-related issue is handling failures of external non-critical scripts (analytics blocked by adblock etc) I wrote a draft of a blog article on the topic last week: https://gist.github.com/jakub-g/5286483ff5f29e8fdd9f https://gist.github.com/jakub-g/5286483ff5f29e8fdd9f Context: We've faced an insane page load time (70s+) due to external analytics script being slow to load (yeah, we should have been loading the app on DOMContentLoaded instead of onload).
- paulirish 11y agoSince `load` waits for all iframes and images, you typically don't want JS initialization to be dependent on it. For non-critical third-party scripts, you might actually want to do something like doc.on('DOMContentLoaded', e => setTimeout(requestIdleCallback(init3rdparties), 2000));
- jakub_g 11y agoHi Paul, thanks for sharing the `requestIdleCallback`, I didn't know it, pretty interesting! Though since it's only in Chrome 47+, it will take a while for it to gain market adoption.
- gcb0 11y ago"JS and CSS assets must be concatenated" that is fine if you have a tiny little site. If you are a big company, each micro site will use a piece of the larger set of files. if one use a,js b.js and c.js, when you concatenate you just lost 100% of cache if the user clicks a link to a side of the site that only uses b.js and c.js likewise, try to load, un-concatenated, common libs from widely used free CDNs.
- cheriot 11y agoSpending the last 6 weeks in East Africa has completely changed my perspective on web performance. And it's not just performance, it's reliability. Every request a page can't work without is another chance to fail. React/Flux and the node ecosystem are more verbose than I'd like, but they might be onto something by rendering the initial content server-side.
- paulirish 11y agoFor sure. Rendering JS apps server-side is pretty much mandatory from a performance perspective.
- philbo 11y agoSurely the first bit of advice in any post about analysing website performance should be: USE WEBPAGETEST It gives you access to everything Chrome dev tools do, plus so much more: * speed index as a metric for the visual perception of performance * easy comparison of cached vs uncached results * operating on median metrics to ignore outliers * side-by-side video playback of compared results * different user agents * traffic-shaping * SPOF analysis * a scriptable API * custom metrics I could go on. There's a lot of excellent performance tooling out there but WebPageTest is easily the most useful from my experience.
- _mtr 11y ago> It gives you access to everything Chrome dev tools do, plus so much more: Can WebPageTest (I've never heard of this tool) reach pages that require authentication? http://www.webpagetest.org/ http://www.webpagetest.org/
- jakub_g 11y agoIt's open source, you can build your own http://www.webpagetest.org/about http://www.webpagetest.org/about
- philbo 11y agoIt can, using either basic auth or by scripting submission of login forms. Probably obvious, but you should avoid doing it from one of the public instances. Building your own private instance is as easy as spinning up a prepared EC2 image, or if you have a couple of hours to fiddle about you can do it from scratch on any Windows machine. Details here: https://sites.google.com/a/webpagetest.org/docs/private-instances https://sites.google.com/a/webpagetest.org/docs/private-inst...
- radicalbyte 11y agoI've had great success in the past doing one very simple thing: on first load send the client the exact html/css that must be loaded on their screen. Once the page is loaded, use javascript to take over updates (using framework of choice). It worked great in 2008, hopefully the modern javascript developers can now reinvent the wheel. It'll be a lot easier nowadays what with Node/V8 meaning you can use the same code...
- Kluny 11y agoCould anyone explain like I'm 5 what "layout thrashing" is? As far as I understand, it's when the size of an element is set in the CSS, like div { width:100px; } Then later in the CSS it's changed to div .biggerdiv { 200px; } Or maybe it's javascript that changes it: $('.biggerdiv').style('width:200px;'); but either way it's when an element has some size near the beginning of rendering, then as more information becomes available, it has to change size a few times. Am I getting it?
- troels 11y agoLayout thrashing is when the browser layout engine does some work to render the page, but then something changes and it has to do it over again. A typical case is if you have a loop in javascript wherein you both read and write to the dom. For example, if you change the css style of an element and then afterwards try to read its position property. Because changing the style might have affected the position, the browser will have to render parts or whole of the page in order to give you that information. It's a very easy mistake to make and it's not obvious what you have done if you don't look for it. And in the context of page load, it would be if the dom is changed in many different places (So yes, your example would probably cause layout thrashing).
- amelius 11y agoRegarding layout-thrashing: if only there were a way to hint the dimensions of each element.
- jmartens 11y ago>While I use New Relic's real user monitoring (RUM) to get a general idea of how my end-users are experiencing page load times, Chrome Timeline gives you a millisecond-by-millisecond breakdown of exactly what happens during any given web interaction. New Relic does, too! Its a Pro feature called Session Traces.
- deleted 11y ago[deleted]
- chain18 11y agoCan someone explain his point about $(document).ready()? I don't understand how it is different from DomContentLoaded? jQuery source for the ready function: https://github.com/jquery/jquery/blob/c9cf250daafe806818da1dd207a88a8e94a4ad16/src/core/ready.js https://github.com/jquery/jquery/blob/c9cf250daafe806818da1d...