I'm working on a web application, and it's getting to the point where I've got most of the necessary features and I'm starting to worry about execution speed. So I did some hunting around for information and I found a lot about reducing page load times by minifying CSS/JS, setting cache control headers, using separate domains for static files, compressing the output, and so on (as well as basic server-side techniques like memcached). But let's say I've already optimized the heck out of all that and I'm concerned with how long it actually takes my web app to generate a page, i.e. the pure server-side processing time with no cache hits. Obviously the tricks for bringing that time down will depend on the language and underlying libraries I'm using, but what's a reasonable number to aim for? For comparison, I'd be interested in real-world examples of processing times for apps built with existing frameworks, doing typical things like accessing a database and rendering templates.
I stuck in a little bit of code to measure the processing time (or at least the part of it that happens within the code I wrote) and I'm generally seeing values in the range 50-150ms, which seems pretty high. I'm interested to know how much I should focus on bringing that down, or whether my whole approach to this app is too slow and I should just give it up and try something simpler. (Based on the Net tab of Firebug, the parts of processing that I'm not measuring typically add less than 5ms, given that I'm testing with both client and server on the same computer.)
FYI I'm working in Python, using Werkzeug and SQLAlchemy/Elixir. I know those aren't the most efficient technologies out there but I'm really only concerned with being fast enough, not as fast as possible.
EDIT: Just to clarify, the 50-150ms I quoted above is pure server-side processing time, just for the HTML page itself. The actual time it takes for the page to load, as seen by the user, is at least 200ms higher (so, 250-350ms total) because of the access times for CSS/JS/images (although I know that can be improved with proper use of caching and Expires headers, sprites, etc. which is something I will do in the near future). Network latency will add even more time on top of that, so we're probably talking about 500ms for the total client load time.
Better yet, here's a screenshot from the Net tab of Firebug for a typical example:
It's the 74ms at the top that I'm asking about.
IMHO, 50-150 ms on client side on server side is fine in most circumstances. When I measure the speed of some very known websites, I rarely see something as fast. Most of the times, it is about 250 ms, often higher.
Now, I want to underline three points.
Everything depends on the context. A home page or a page which will be accessed very frequently will suck a lot if it takes seconds to load. On the other hand, some rarely used parts of the website can take up to one second if optimizations are to expensive.
The major concern of the users is to accomplish what they want quickly. It's not about the time taken to access a single page, but rather the time to access information or to accomplish a goal. That means that it's better to have one page taking 250 ms than requiring the user to visit three pages one after another to do the same thing, each one taking 150 ms to load.
Be aware of the perceived load time. For example, there is an interesting trick used on Stack Overflow website. When doing something which is based on AJAX, like up/down-voting, first you see the effect, then the request is made to the server. For example, try to up-vote your own message. It will show you that the message is up-voted (the arrow will become orange), then, 200 ms later, the arrow will become gray and an error box will be displayed. So in the case of an up-vote, the perceived load time (arrow becomes orange) is 1 ms, when the real load time spent doing the request is 100 ms.
EDIT: 200 ms is fine too. 500 ms will probably hurt a little if the page is accessed frequently or if the user expects the page to be fast (for example, AJAX requests are expected to be fast). By the way, I see on the screenshot that you are using several CSS files and ten PNG images. By combining CSS into one file and using CSS sprites, you can probably reduce the perceived load time, especially when dealing with network latency.
Jakob Nielsen, a well known speaker on usability posted an article [1] on this a few days back. He suggests that under 1 second is deal, under 100ms is perfect as it interrupts the user flow a bit more.
As other users have pointed out it depends on the context of that page. If someone is uploading a file they expect a delay. If they're logging in and it takes ten seconds they can start to get frustrated.
[1] http://www.useit.com/alertbox/response-times.html
I looked at some old JMeter results from when I wrote and ran a suite of performance tests against a web service. I'll attach some of them below, it's not apples-to-apples of course but at least another data point.
Times are in milliseconds. Location Req and Map Req had inherent delays of 15000 and 3000 milliseconds, respectively. Invite included a quick call to a mobile carrier's ldap server. Others were pretty standard, mainly database read/writes.
sampler_label count average min max
Data Blurp 2750 185 30 2528
UserAuth 2750 255 41 2025
Get User Acc 820 148 29 2627
Update User Acc 4 243 41 2312
List Invitations 9630 345 47 3966
Invite 2750 591 102 4095
ListBuddies 5500 344 52 3901
Block Buddy 403 419 79 1835
Accept invite 2065 517 94 3043
Remove Buddy 296 411 83 1942
Location Req 2749 16963 15369 20517
Map Req 2747 3397 3116 5926
This software ran on a dedicated, decent virtual machine, tuned the same way production VMs were. The max results were slow, my goal was to find the number of concurrent users we could support so I was pushing it.
I think your numbers are absolutely ok. With regards to all the other stuff that makes websites seem slow, if you haven't, take a look at YSlow. It integrates nicely with Firebug and provides great information about how to make pages load faster.
50-150ms for page load time is fine - you do not need to optimize further at this point.
The fact is, so long as your pages are loading within a second, you are OK.
See this article, which discusses the effects of load times for conversion (100ms increase = 1% for amazon).
Related
I'm building a quiz backed by a lot of Census data, and I would really like to power it with flat files rather than worry about a database and servers. (More on the case for flat files here.) The uncompressed JSON file I need for the file part of the quiz is currently 11MB.
Right now, I'm making an AJAX request for the file right away, but not using it until the user has completed the quiz, which will take about 1 minute.
I realize this is a bit of a subjective question, but I'm wondering how much this is pushing the envelope when it comes to supporting a wide variety of modern phones and computers in 2015. I'm worried less about the bandwidth than about the memory and processing power in the device. The code parses through all the data, matches entries to user responses, and computes a result.
TL;DR
Is it crazy to AJAX an 11B JSON file if I don't need it for about 60 seconds? (I'll check to make sure I have it when the time comes, of course)
I am benchmarking a default Drupal 7.28 installation with no extra modules or themes. And I am curious why I get slightly different results using Firebug considering everything is local. Here are some results I get in milliseconds:
394
385
389
459
440
381
Does anyone know why the page load time varies locally?
Benchmarks normally don't always give the exact same results when they are run multiple times.
The page load time is not only influenced by the network speed. The results are also influenced by multitasking or dynamic compilation optimizations.
The (local) server doesn't always return the response at exactly the same time as it needs to process the request while it's running in concurrency with other programs. The same counts for your browser.
Multitasking assigns different time slices to your program to simulate that the programs run in parallel, though they actually run in sequence. And these time slices are managed by the underlying OS and may vary.
Also the server as well as the browser may do some compilation/execution optimizations when a request is run multiple times in sequence.
I'm a web designer and will make a document to train my sites clients how to know if the internet bandwidth speed is slow or quick for each visitor of their sites, depending on the images or site weight (in bytes or in megabytes) and on their internet speed (in kilobit or megabit), for taking how long seconds or time by 250, 500 or 750kb and 1, 2, 4 or 10MB.
I guess there are a few different ways to look at that question. If you are just looking to calculate how quickly the data can be downloaded in a perfect world, Jim's answer explains doing that calculation. But simply downloading files is a small part of the overall performance of a site. There are a few tools out there which will help you understand the performance of your site at different connection speeds.
One of those tools is Webpagetest.org. Enter your URL, choose a location and a browser then expand the Advanced Settings section. Choose a connection type and enter the number of times to run the test. It should be more than 1, but you are limited to only 10 through this UI. Its probably a good idea to go over to the Video tab and choose to capture a video as well so that you can demonstrate what its like on each size pipe. Then repeat for each of the connection types you want to test. This will give you a pretty good idea of how long it will take to view this site at different connection types.
The downside here is that its a bit of work to create a bunch of tests, then collate that info. An alternative to this is the Site Monitor feature at http://yottaa.com. You can setup a single test which will look at the site from different locations, or different browsers, or different connection types, then let you easily graph out the results. To get access you have to register for a free account. An alternative to that is at http://websitetest.com which requires no registration, but you get none of the management of test results.
Webpagetest.org is run by Google in cooperation with a lot of other partners.
Full Disclosure: I am the Technical Evangelist at Yottaa.
If you're asking how long it takes to download, say, 54 megabytes on a 10 megabit (or whatever) connection, the simple solution is pretty easy.
For the sake of simplicity, and to take into account the overhead involved in TCP communications, we typically say that 10 megabits per second is the same as one megabyte per second (that is, we assume one byte is 10 bits rather than 8 bits).
So if you want to know how long it takes to download 54 megabytes on a 10 megabit (1 megabyte per second) connection, the answer is 54/1, or 54 seconds. If you have a 250 Kb connection, that's 25 kilobytes per second, or 0.025 megabytes per second. 54/0.025 = 2,160 seconds, or 36 minutes.
In general, this is a best case estimate. It assumes that the connection between client and server can support the sustained maximum rate. The numbers don't take into account other things the server might be doing that would reduce the bandwidth it can dedicate to a particular connection, nor does it include stalls that could occur in the many hops between client and server.
In practice, the number will most likely be larger. That is, if the above calculation says that the entire site can be downloaded in 27 seconds, it could easily take twice that long. There's no way to reliably predict, based only on the client's bandwidth.
It's also possible that it could take less time, if the client's "10 megabits" is an average, and bursts of higher bandwidth are available. Especially during times of lower overall network usage.
Can a human eye perceive a difference between an image that takes 150ms to load and another image that takes 160ms to download?
If a page has 30-40 images, then does this 10ms difference start making a difference?
10 ms might be just barely noticeable. On a typical laptop with a refresh rate of 60 Hz, each frame is on the screen for about 16-17 ms, so (all else being equal) a 10 ms delay means a roughly 66% chance of making the image show up one frame later.
However, a 1-frame delay (which is the maximum delay possible as a result of this) would in all likelihood not be noticed by most users. It would be very noticeable for animation, but not very noticeable in terms of when the static image appears.
According to 3D Developer John Carmack, "Human sensory systems can detect very small relative delays in parts of the visual or, especially, audio fields, but when absolute delays are below approximately 20 milliseconds they are generally imperceptible."
That is to say, 20ms is a good rule of thumb, even though flicker may be noticeable quicker. So 10ms (150 vs. 160ms) shouldn't be perceptible. However, you're asking about whether the user will notice the difference between 150ms and 160ms. If it's a one time event (as opposed to something blinking at 15 or 16 kHz), I don't see how people could notice the difference.
People will see the 30-40 images loading, if they look carefully and there's no buffering. However, there are a lot of other things going on with web pages.
Network plus OS latency varies far more than 10ms, so your 150ms load time will vary-- even if you're talking to localhost.
The browser will typically have several connections open at one time to load files more efficiently. So files will seem to load simultaneously or out-of order. If there's any file size to pay attention to, it's the size of one Ethernet packet. If the complete response fits in one packet (typically 1500 bytes, including packet headers), making it smaller shouldn't improve performance.
The browser may delay displaying images for a few milliseconds to minimize frame buffer (window) re-writes.
The browser needs to parse the CSS rules for displaying the image. Browsers start loading images before they have completed the CSS parsing, and CSS parsing may take longer than image loading.
If you are testing animations, your knowledge and anticipation of an event makes it seem slower. Other users won't notice things that are glaringly obvious to you.
So long story short, image file size is probably the least of your worries. If it's important, don't rely on heuristics-- do your own testing. All the modern web browsers have great timing tools, although Google's are the most focused on latency. (They may get leap-frogged at any time, though.)
Also, test over different types of Internet connections (local network, across 1000 miles, cellular network) and on different browsers and devices. Cellular networks are particularly weird, since the initial network connection takes a long time and then shuts down shortly thereafter.
If the page takes 150 ms to load and the image takes 160ms that's 310 ms total. The human eye can read 10-12 images per a second, or about 1 every 100 ms's. So yes they would notice the loading if they looked hard enough.
I know it's a good practice to minimize the number of requests each page needs. For example, combining javascript files and using css sprites will greatly reduce the number of requests needed to render your page.
Another approach I've seen is to keep javascript embedded in the page itself, especially for javascript specific to that page and not really shared across other pages.
But my question is this:
At what point does my javascript grow too large that it becomes more efficient to pull the script into a separate file and allow the additional request for the separate js file?
In other words, how do I measure how much bytes equates to the cost of one request?
Since successive requests are cached, the only cost of calling that same js file is the cost of the request. Whereas keeping the js in the page will always incur the cost of additional page size, but will not incur the cost of an additional request.
Of course, I know several factors go into this: speed of the client, bandwidth speed, latency. But there has to be a turning point to where it makes more sense to do one over the other.
Or, is bandwidth so cheap (speed, not money) these days that it requires many more bytes than it used to in order to exceed the cost of a request? It seems to be the trend that page size is become less of a factor, while the cost of a request has plateaued.
Thoughts?
If you just look at the numbers and assume an average round-trip time for a request of 100 ms and an average connection speed of 5 Mbps, you can arrive at a number which says that up to 62.5 KB can be added to a page before breaking it out to a separate file becomes worthwhile. Assuming that gzip compression is enabled on your server, then the real amount of JavaScript that you can add is even larger still.
But, this number ignores a number of important considerations. For instance, if you move your JavaScript to a separate file, the user's browser can cache it more effectively such that a user that hits your page 100 times might only download the JavaScript file once. If you don't do this, and assuming that your webpage has any dynamic content whatsoever, then the same user would have to download the entire script every single time.
Another issue to consider is the maintainability of the page. As a general rule, the more JavaScript you add, the more difficult it becomes to maintain your page and make changes and updates without introducing bugs and other problems. So even if you don't have quite 62.5 KB of JavaScript and even if you don't care about the caching side of things, you have to ask yourself whether or not having a separate JavaScript file would improve maintainability and if so, whether it's worth sacrificing that maintainability for a slightly faster page load.
So there really isn't an exact answer here, but as a general rule I think that if the JavaScript is stuff that is truly intrinsic to the page (onclick handlers, effects/animations, other things that interface directly with elements on the page) then it belongs with the page. But if you have a bunch of other code that your handlers, effects, and other things use more like a library/helper utility, then that code can be moved to a separate file. Favor maintainability of your code over both page size and load times. That's my recommendation, anyways.
This is a huge topic - you are indirectly asking about many different aspects of web performance, so there are a few tricks, some of which wevals mentions.
From my own experience, I think it comes down partially to modularization and making tradeoffs. So for instance, it makes sense to pack together javascript that's common across your entire site. If you serve the assets from a CDN and set correct HTTP headers (Cache-Control, Etag, Expires), you can get a big performance boost.
It's true that you will incur the cost of the browser making a request and receiving a 304 Not Modified from the server, but that response at least will be fast to go across the wire. However, you will (typically) still incur the cost of the server processing your request and deciding that the asset is unchanged. This is where web proxies like Squid, Varnish and CDNs in general shine.
On the topic of CDN, especially with respect to JavaScript, it makes sense to pull libraries like jQuery out of one of the public CDNs. For example, Google makes a lot of the most popular libraries available via its CDN which is almost always going to be faster than than you serving it from your own server.
I also agree with wevals that page size is still very important, particularly for international sites. There are many countries where you get charged by how much data you download and so if your site is enormous there's a real benefit to your visitors when you serve them small pages.
But, to really boil it down, I wouldn't worry too much about "byte cost of request" vs "total download size in bytes" - you'd have to be running a really high-traffic website to worry about that stuff. And it's usually not an issue anyway since, once you get to a certain level, you really can't sustain any amount of traffic without a CDN or other caching layer in front of you.
It's funny, but I've noticed that with a lot of performance issues, if you design your code in a sensible and modular way, you will tend to find the natural separations more easily. So, bundle together things that make sense and keep one-offs by themselves as you write.
Hope this helps.
With the correct headers set (far future headers see: 1), pulling the js into a separate file is almost always the best bet since all subsequent requests for the page will not make any request or connection at all for the js file.
The only only exception to this rule is for static websites where it's safe to use a far future header on the actual html page itself, so that it can be cached indefinitely.
As for what byte size equating to the cost of an http connection, this is hard to determine because of the variables that you mentioned as well as many others. HTTP resource requests can be cached at nodes along the way to a user, they can be paralleled in a lot of situations, and a single connection can be reused for multiple request (see: 2).
Page size is still extremely important on the web. Mobile browsers are becoming much more popular and along with that flaky connections through mobile providers. Try and keep file size small.
http://developer.yahoo.com/performance/rules.html
http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Persistent_connections
Addition: It's worth noting that major page size achievements can be achieved through minification and gzip which are super simple to enable through good build tools and web servers respectively.