![]() But why not inline all of the CSS in the index.html file in the first place? Frankly, I'd rather not have the page load at all than subjecting anyone to that. Stylesheets could in theory be loaded asynchronously, but a flash of unstyled content (FOUC) would then occur. These are blocking and the page will only render when all the requests are completed. Loading external stylesheets takes additional round trips.So what can be improved here? Three things came to my mind: Thinking about the timeline, it is not hard to imagine what influence the higher round-trip times will have on the DOM loaded event when potentially multiple blocking requests have to be completed before the browser renders the page. Not a big surprise that the Edge connection is even worse, particularly in terms of consistency: That is much worse than the Wi-Fi connection indeed, particularly when multiple files need to be loaded then these times really add up. Using 3G under ideal conditions (five bars) I consistently got a little less than 500ms: But it doesn't really matter a 25ms delay is not near as noticeable as the delay introduced by switching to a mobile network. I have no idea where this delay comes from, could be something in iOS or in the Ping Lite app. Interestingly this is about 25ms slower than what I got with the command line ping on my Mac on the same network. I wanted to know how much worse network round-trip times actually are on mobile networks, so I measured a ( (networkingutility)) to the domain of this blog with a free iPhone app called Ping Lite.Īs a baseline measurement, I did the ping over Wi-Fi + DSL and got around 55ms on average: And things of course do not degrade gracefully when the signal deteriorates. Now pre-LTE mobile networks have much longer network round-trip times than copper or fiber-based tethered networks, even under ideal conditions. So presumably they are much better than what a suboptimal mobile connection would yield. The numbers are comparable to what I can measure in Chrome Developer Tools, with a decent DSL subscription. I have used GTmetrix for generating the charts. You will notice that the DOM loaded event fired after more than an entire second (the blue line), or a little less than 200ms after the blocking screen.css has finished loading. We can examine the request behavior by looking at a timeline chart, like this one for the index page of this blog: Many of the resources are blocking the page will only display after they are loaded. This index.html then typically contains multiple links to stylesheets and scripts, all of which trigger the same cascade (minus the DNS lookup if subsequent requests point to the same domain). If no specific file is given in the request, a server will usually try to return a file named index.html inside the folder that maps to the request URL. ![]() Then that domain is contacted using an HTTP GET request for the particular URL. So what happens when the browser loads a page? First a DNS lookup takes place, translating the human-readable domain name into an IP address. So I went on a quest to make this better. And I would quite likely not even try again. No way I would ever wait that long for any page to load. Opening my own blog made me sad: with the bad 3G connection it took like 10 seconds for the index page to show anything at all. Not terribly difficult to simulate, I only need to disable the Wifi and walk into different corners of my apartment for that. ![]() As in, how long does it take for a web page to load, on a mobile device? I was doing some research by opening different websites under suboptimal conditions, such as 3G with only two to three bars, or even worse the dreaded E with four to five bars. This new project is another single page application based on AngularJS, but that is not part of the story I am going to tell you today at all. A few weeks ago I started working on the follow-up to my BirdWatch project. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |