Since that last post was kind of a bust (in a good way!) – let’s kick off another one right away. We’ll keep it along the same lines: page weight, this time regarding the page as a whole.
Way back in the day Google used to only index 100k of a page (although I think that’s the HTML only) but that’s not true anymore. 200k for the entire page (including all resources: css, images, js, etc) used to be a common goal. I’d say very few web pages these day come in at under 200k.
So the new poll is:
What do you think is reasonable page size to try and stay under for a modern web design?
Full, real time results for this poll and all post polls are in the polls archive.
It depends, if your site is a blog then it would be 600KB + due to images, if your site is a web app then most of your resources would be concentrated towards javascript and css 400KB+ with image resources as well. If it’s something like a project page for something it may take reasonably less components I’d say 100KB+ .
I think you need to split that out into mobile web size and desktop size. However even if the page is 2mb, but it loads within a few seconds, does it matter?
What?
I think John has a point. My total page size is around 1.7MB but it loads in 1.63 seconds. So the size doesn’t really matter if it loads within seconds. CSS-Tricks weighs about 645KB but it loads in 2.66 seconds, according to this report.
http://gtmetrix.com/compare/qjcxT4I7/CWlM1LUN
But I still think that the reasonable page size for a modern web design is arounds 500k including the resources.
2MB loading in seconds makes the assumption that all your visitors are at the high end of bandwidth speeds, and more specifically, is a reflection of your own connection, and, unfortunately, not your visitors’.
Optimising load times for all visitors, regardless of connection speed, is good practice, as is accessibility.
” My total page size is around 1.7MB but it loads in 1.63 seconds.”
Do you ever think about the people with a slow connection, they will never ever see your website…just saying…
keep it low ! css sprite,few http requests,good cache,etc…
try to simulate it (http://www.dallaway.com/sloppy/) for example
So hard to speak of something like this in generic terms, because I think it’s just another one of those cases where context will determine this. Are you looking to have a lot of mobile/lower bandwidth users? Or is the primary purpose an intensely visual, graphic experience or something with a ton of content associated with it? Is there Flash or audio/video content involved?
Anyway, regardless, I chose 1MB as being a pretty liberal cap to shoot for. Anything more than that, you can expect the user to wait excessively long times for the page to load, and probably annoy the hell out of them.
For an unknown page – that is, a page where the user isn’t sure what the page consists of, I shoot for 100K. Anything more than that and it takes too long to download everything.
I realize most people have fast connection speeds, but that doesn’t mean you need to use it. Faster speeds should enable users to view the Internet faster, not view the same amount of content prettier.
For pages where the user knows what they’re getting into (ex: a link to my Photo Gallery), the sky’s the limit.
I dont think its only a question about page weight. From the technical perspective you should at least take the weight AND number of requests into account.
And then it depends (as others mentioned) on the type of website.
I think a good rule of thumb for an average landingpage of a site should be about 200-300k and a max of 20-25 requests.
Well the ideal page weight would be as low as possible, maybe 300k (that would be hard to achieve), but realistically it is often between 500k – 700k
Inside the first floor of a 2-story dense brick and steel building on a cloudy day like today, my smartphone’s 3G signal is getting 3/5 bars. My speed test results are putting my download speed between 600kbps and 800kbps. If I move to where I can pull 4 or 5 bars, that jumps up to between 1300kbps to 1800kbps. We’re talking about DSL and/or T1 speeds here, which is fairly conservative for most residential broadband.
That means that at 3 bars, I’ll download 2MB is under 20 seconds and at 4 to 5 bars I’ll download it in under 10 seconds.
My vote is for 2MB based on those results.
In most country areas in my country, a DSL speed of only 500kb/s is the norm and that’s for a desktop environment and to be shared across the whole house. I live on my own and get a max of 480kb/s on a 8/1MB connection.
That’s horrible. Recent studies are showing that many mobile users stop loading a page it if takes more than just 3 seconds. Even thinking that’s off, you’re talking increasing that time for users to abandon your site from three to six times more, and considering that abandonment is exponential instead of linear that’s a LOT of potential lost visitors.
LOL WOWW!! 20 seconds to load a page?! I quit! If the site doesn’t load in just a few seconds on my DroidX, I leave. I can’t imaging waiting 20 seconds for a site to load, that’s incredible. I’m on verizon with 3G. My Comcast, I believe is a 16mb/s download, and i get anywhere from 1.8mb/s-3mb/s realistically(from what i’ve experienced), maybe I have 12mb/s download and not 16, i forgot but I voted for 350kb. Then again it depends on if it’s a blog with tons of article images or whatnot, or if it’s an interactive children’s website where lots of images are necessary to entertain.
Great blog
I think it depends on a number of factors.
What you analytics show in relation with connection speeds for users. The context of the content your displaying. And the device your aiming the site at.
According to studies , users leave a page if its not loaded in 4 seconds, so anything under that time cap is well and good. As this loading time is dependent on the internet speed it comes down to the fact that either you reduce the Page Size or manufacture some mind-boggling Content (so that users don’t leave your page). Personally I think anything under 500Kb will be good.
P.S. When did I care for the loading time of CSS-Tricks
I recall it to be the 3-second-rule and that’s for loading the page AND familiarizing with the structure of the page. Everything more than 2 seconds is simply unacceptable.
The faster the better, but for a non-mobile site anything lower than 500K is not realistic, it is quite common you have a few hundred Ks in framework code already.
But of course the poll in general means nothing without context. Connection speed, latency, device, audience…all need to be taken into account. You can’t say you need to stay below 100K if half the world is watching Youtube at a few 100K per second.
What kind of frameworks have a few hundred Kb’s of code?
What really matters is how the page loads. Compare the following:
1. You wait 10 seconds with a blank screen, and then the whole page appears at once.
2. Text content appears in 1 second, but you can’t read it properly because it’s beige-on-white. After 5 more seconds the dark background image pops in and you can read the text. After 4 more seconds the whole page has finished loading.
3. Text content appears in 1 second, and you can read it. After 3 more seconds, some javascript rearranges the page layout and you lose track of what you were reading. After 6 more seconds the whole page has finished loading.
4. Text content and layout/styling appear in 1 second (all the decoration is CSS3, not images). It takes a further 9 seconds to load the large content images, and also to bring in some javascript interaction, but nothing jumps about on the page.
All these pages take 10 seconds to load; they may even have the same number of HTTP requests. But the experience is much better in case (4).
With you there Mike. I design for 3rd world clients – and it HAS to be case (4) every time. We work with download speeds of 56Kbps through to 1Mbps. [NB upload speeds never exceed 128Kbps in the region]. Everything has to be legible and stable from the get go.
Most clients here want all the fancy decorations, but are unwilling to accept the limitation of 3rd world infrastructure. So we put a lot of work into ensuring that pages load in seconds even on a 56K connection. And still look good…
For this kid, the deal killer is waiting for the off-site links…having the page frozen for 15-20 seconds while “waiting for http://www.facebook.com” and “waiting for platform.twitter.com” etc., etc. ad nauseum.
This delay is worth it to the site owner – she gets stats and ad revenue and toolbars and etc., and she’s already gotten my hit, but she’s lost me. If that matters to her, she might want to reconsider.
I might come back, but I won’t be as happy as I would if that bunch all loaded after I was given control back over my browser.
I think a more meaningful consideration to take into account is page weight WITHOUT content. Content and vastly impact page load and often is out of the front-end designer’s control. Sure we can make provisions as such but sometimes the client insists on uploading a page with 25-30 images.
However, the site layout is where the biggest gains can be made. Does the site need that massive background image? Does it need to load in one massive stylesheet that contains every style on every page of the the whole site? Does it need to load in jQuery because you have one 10 line script that was written to use it?
Personally unless the design is unbelievably rich I fight to keep the layout’s load weight under 150 kb. If possible I tend to go below 100Kb for most designs.
Cudos to those stressing the importance of time. It is imperative we structure our sites and applications in ways that fit the expectations of the recipient for a given task.
Size is relevant only insofar as size influences time. When the user must wait to visualize, read, and interact we are more likely to lose them.
~ Dao
P.S. Great topic!
I think 350k is great for load speed.
Page weight is not nearly as important as the speed at which it loads.
If you have a site that has 1,000 images that are each 100 bytes in size, this could take significantly more time than a one 1mb image.
Let’s say it takes 0 ms to download each 100 byte image but you have an average latency of 25ms per request (latency will depend on where you are obviously). It is now taking 2.5 seconds to get all 1000 images with a total weight of only 10kb.
On a modern internet connection you can easily download the 1mb image in 1 to 2 seconds or less.
So basically you can have a page weight of 10k and still take a really long time to load.
This is my 2 cents.
So many variables (demographics) that you should take into account for this. It mainly depends however on the type of connection your typical user uses.
A site that is aimed at mobile users should be small (max 100k I think). Aimed at mobile users abroad even smaller (roaming charges). Desktop users on dailup connection (yes they exist), keep it under 250k perhaps? On cable/DSL with limited bandwidth I would keep it around 1M. For the rest, unlimited.
So basically research the target audience and adapt to their situation; no one answer is right or wrong.
When you say “modern website”, I assume you mean using technologies such as jquery, css3, html5 and so on. So, that being said, the use of images can be significantly reduced for slightly larger css/js files. I chose 350k should be the average maximum for most websites today. Overall, it’s about loading time for the user even though server load is very important for us as developers. Personally, I’m a fan of making EVERYTHING AJAX. The website is literally only a single index page and all the content is loaded in dynamically through ajax (for retrieving data from the db) and jquery (load static html from external file as well as parse / use data received from the server via AJAX). Even though this makes indexing a mess for search engines, it is supremely helpful for not only the load time for the user but also the server load. That said, my latest piece of work is several thousand lines of code so far and has a very nice interface yet only uses one image for a banner (and that’s only because it’s a picture of a place). The whole website currently loads at about 50k except for the image which is 350k. The image, for now, remains at a high quality, and is rather large. It could be easily be cut down to 250k and still look nice. The best thing, though, is that it is only loaded one time regardless of browser cache due to the full AJAX nature.
The time it takes for the page to load isn’t the real issue, it’s the time it take the page to deliver what the user wants. Exaggerated example: if the user is looking for “Holidays in France”, it doesn’t matter if the homepage of the travel site loads in 60 seconds if the top nav, with “Holidays in France” displays in 1 second.
I’d aim to deliver the content of a page as quickly as possible, aiming for less than 300k. If some non-essential content (imagery, js, below-the-fold stuff like comments) adds extra weight but loads in later, that’s cool.
It should be no larger than is necessary of course. Not for your users, but for you. It’s your bandwidth you’re wasting too. The more bandwidth you consume, the fewer concurrent visitors you can support.
Often I hear an interesting website mentioned on the radio and shortly afterwards they announce it has ‘crashed’.
With CSS3/HTML5 i.e. ‘Modern Websites’ you may find yourself requiring fewer graphical resources to meet the desired aesthetics for your site.
I can understand that most people are living in a developed country with great broadband, or at least in the UK, which has increasingly good broadband.
It is worth pointing out though that The Web is global and if your page is going to be part of that, you can’t just shrug about pages being 2mb as they just won’t work for many countries.
As always, it all depends on your visitors, your target audience, the type of content you serve – but don’t forget that you are lucky to have good broadband.
I suppose the platform matters, though obviously in every case the lighter the better. I don’t think anyone has an issue loading a 1 – 1.5 meg site on a desktop anymore.
However with the responsive boom and in particular the focus on mobile devices and mobile networks I have really began to look at my websites in far more detail.
The amount of KB’s you can squeeze out of even quite the graphical site can be surprising to say the least. The last build I did for quite a significant brand, with some big images on the page too clocked in at under 350k of which I was pretty proud. I’m hoping to trim the fat even further for the mobile layout.
Ironically the biggest file in the project is jQuery clocking in at 91k. Which makes me consider whether it would be better to start seeking out a really lightweight js library instead.
To be honest I think I use jQuery more for the selector engine than anything else, but 91k just seems excessive when the rest of the site is clocking in at 350
if you gzip your page, jquery-min is just 39kb.
if you use jquery only for selecting, maybe sizzle.js (which is the selector engine of jquery) is your way to go
It’s also interesting to note, that the CSS-Tricks homepage is under 500k if you block advertisements.
In my experience it’s often Flash and High Detail advertisements that end up eating up a lot of extra bandwidth. The CSS-Tricks homepage gains an extra 30% in weight for example.
…and my answer, under 1MB should be the goal on any page, served to 500k or less for mobile devices. But honestly? It depends on exactly what the purpose of the page is, an image gallery may end up adding a MB or two if it’s all loaded up. I guess the answer is to serve content only as it’s needed as much as possible.
Load what’s needed, at the compressed resolution it’s needed, scripts and stylesheets minified and everything cached to bring down server load and latency.
Well it largely depends on the site’s content taking aside the design (aka css, html, scripts, images in the page design). The main content dictates this size so its hard to say – the size that has 6-10 pictures in it can hradly hit any reasonable bariers (50k per picture*6 = 300k just for those), not to mention adds, videos etc…
a better question would be the site’s size with no ‘actual’ content – just the design stuff since the rest really depends on what a client wants as sites content
and even here as pointed out before loading time is the one that really matters, not the size
As a being developer I am trying to limit the page size to 250-350 KB. I think which is best.,
I’m afraid you may have anchored the survey by providing the CSS-Tricks page weight.
International website = under 500kb.
Websites for america/europe and other countries with good connection = around 2mb+
That’s what i think.
The less, the better. Images can be optimized, CSS/JS can be minified, assets can be gzipped, massive JS libraries can be replaced with smaller ones. If a page goes over 500K, it’s too big.
I definitely have to agree with Avi up there^. I’m blown away by the number of people who think it’s OK to have a page size > 1MB.
Are you kidding? Maybe a photo gallery page. But a home page or other frequent landing page? No way. There are a lot of people stuck with 3G modems or even worse – satellite internet – and anything over 350KB is way too much.
Tone it a down with the images, sometimes you can get by with more compression on your jpgs. And it’s not just about the overall size – people go overboard with separate requests all the time. Use CSS sprites for everything and please, start consolidating your 15+ different JS files.
If I can’t load a site in less than 10s, I don’t wanna see it anymore, even if I’m on HughesNet. simple as that.
This post just made me go back and check the last two projects I worked on and check one I’m working on now. I don’t know the right answer to this question (if there is one) but I know I can be doing more to my own sites to optimize them. Thanks for the post
It’s all about your users. Use Google analytics to check network speeds and read those statistics. If your user base is on slow connections, and/or mobile, then optimise for a this.
As mentioned by someone earlier – it’s hard to talk about this generically as most decisions around delivery depend on your user base. If you are launching a new site and have no stats to analyse, look at your competition (ones that rank high), and use there sites as reference.
Users are key. Don’t forget them or you’ll pay heavily.
Under 500kb is what I strive for in most cases.
As small as possible – as large as required!
Touche!!
I make your words, my words.
Exactly the words of wisdom I wanted to share myself after thinking this through some more!
Good one Martin!
I don’t know much about this, but I’m sure aware that my pages are bulky. It makes me uncomfortable. Google wants us to check our pages, why? They know that users skip my pages if loading them takes to long. They also know that the internet as a whole, will be slower and slower, despite the efforts in a faster and more efficient equipment. I thought i’ve read from google, that in some point in the future, the internet will become so slow that bulky pages will nog load anymore. That is why google wants me to pay attention to loading times, change bulky pages into clean and slick html, and so on.
It makes me wonder, if browsers are now already working on zipped content from servers, and new technologies will emerge from this, how important the issue of bulky pages will become.
I think its all relative, for example I’ve recently done a website for a client that is 3mb, but it loads under 2 seconds. Most of the content is only called in on pages that need it. With a good helping of CSS3 and HTML5.
It comes down to demographic too, like for example my clients customer base wont be people in developing countries because of the products and services they sell. So even if on a slow internet connection the site took 20-30secs theres a 99% chance that they are not the customers they want anyway.
But that doesn’t stop me from wanting to tweak it for optimum performance, thats just good practice, but you have to know where to draw the line.
Qwik.Vu (http://qwik.vu/) is 518 kB all inclusive and it’s a quite complex homepage.
I think it’s a good example
There are two things I aim for when making a website. The size of the files and the amount of requests.
There are some things you can do to decrease them. I love to use ImageOptim which is a program that rips the fat off PNG’s. It works great. I also avoid using JPEG’s at 60% quality or more.
Then I short-code as much as possible and compress the file before I upload. I try to go with few fonts and I also make the scripts dynamic. There is no need to load the “contact us” script if you are on the home page.
I think 350-500k is acceptable. To the dude who said 2mb is fine, sorry but you speak on your great connection and not everybody has it.
Agree with others, depends on so much.
* your server pipe & bandwidth limits
* your users pipe & bandwidth limits
* bandwidth needs to convey message
* design bandwidth needs to convey message
i vote for as small as possible.
allow the client to customize/choose what they get and store it in a cookie. can save bandwidth on both ends.
I say 500k, because I used to develop sites from a small town in idaho…god was our internet slow.
In the end, this shouldn’t just be about page weight. It should be about how well you’ve optimized resources for loading efficiency, how many requests are needed and the time to document completion. Wrote a full response to this here: http://dyn.com/web-development-best-practices-whats-an-ideal-page-weight/
It really is about requests rather than page weight. In a “one web” world I would say shoot for 500k and under 700k would be safe. If it is a desktop centric site I think under 1mb is safe.
This really does depend on a lot. Just did a site where I replaced a ton of images with css3 gradients and have a 200k homepage, including inline image assets (which I don’t count since they load progressively, as compared to CSS images). Yslow is your best friend for this stuff, along with CSS sprites. Let the IE users download the images and let the rest of the web use modern CSS rules to save requests! (havent measured page load in IE >9 vs FF yet, but seriously, if you’re using IE7 what do you expect?)
Obviously relevant to your audience, if you are an hd video site you can obviously have larger size, as main part of your content is high quality video, but for a news site obvious you want to be fast, or they’ll go elsewhere.
I like the new design of kevin rose’s foundation.kr, but if i try to hit from android it just points me to itunes, because it doesn’t even try to pretend it’s mobile friendly.
Ideally my team and I try to keep page weight under 500k, images and all. Anything over that and we use a preloader. This goes for Flash and JS projects.
Here is some statistics. Web metrics: Size and number of resources
It should be 450k max and must be loaded under 2 seconds, anyhow!