I have a quick question and It might not be the right place the ask it but I hope someone can help me becuase im curious.
I'm creating a one-page website whit a lot of style (isnt designed webfriendly and uses a lot of images) this isnt a big problem because we believe we're aiming at a more design branche who most likely have kind of good pcs with a pretty ok connection to the internet and the site is sized down a lot of mobile.
But still I wonder what people recommend. my site is currently 2.2mb on loading (is there a website where you can check this btw? I just made a guess by calculating the file sizes of images etc.) I can still optimize a lot but I think going under 1mb is being a hard task. is this good enough or is there anyway who has experienced it isnt?
thanx in advance
You shouldn't worry about the size of your website (especially since you know your target audience) if the user experience doesn't suffer. However, you should optimize everything you can without sacrificing the design. Google's Page Speed might help you a lot. They even have the total size calculator you wanted. There are tons of similar tools available online as well.
Also, read this about last year's website size trends: http://www.theglobeandmail.com/technology/tech-news/bloated-web-pages-costly-for-smartphone-users/article9355125/
According to the website HTTP Archive, which regularly studies the top 10,000 most-visited sites online, the average web page now weighs in at about 1.3 megabytes, up about 35 per cent in the last year.
UPDATE
Inspired by #pwdst's comments, I'd like to add that if you want support for mobiles, tablets, etc... there's no need to sacrifice the look of the main site - you can use media queries and practically serve a different presenation to those users. Of course, you can go even further and make a different website for them (usually a subdomain).
If you use dev tools, for example in Chrome, you can see the number of requests and total transferred data under the "Network" tab. To accurately replicate the experience of your users, you should do this with an empty cache - "Incognito" or "Private" tabs can be a great way to do this in most browsers. It's also worth remembering that the experience when testing locally will be drastically different from that when the effects of latency and upstream bandwidth come into play.
Be extremely careful about assumptions regarding users if you want to maintain usability. "Good enough" is extremely contextual, it may be "good enough" for a user on a desktop, laptop or premium tablet on a solid DSL connection - but anything but on a Edge or 3G connection on a phone. Wherever possible assumptions should be backed up by analysis of user agent strings from server logs, or from analytics software such as Google Analytics. It's also worth remembering that you may have relatively few mobile or tablet requests, not because mobile or tablet users don't want to visit the website - or choose to visit using another device, but because it is difficult, slow or even impossible to use on their device of choice. This case study from an engineer at YouTube illustrates how customers were being completely excluded from the site.
In general the page should be as small as possible, and you may want to look at lazy loading in addition to optimisations, which will help initial rendering time - in fairness though your estimated size is not much larger than the internet archive average page weight of 1681kB as at January 15th this year. Don't forget that other resources can also use a lot of space - JavaScript makes up 274kB of that average - and it's not clear if you have factored that into your estimate. Aggressive use of caching will help return visitors and minimise the data transfer required in these circumstances.
I always try to consider if you can justify the page weight cost against functionality. What is the objective of visitors to your site? Does the added functionality or imagery help this sufficiently to justify the performance cost. Many performance orientated developers are now actively setting a page weight budget but this is harder for single page apps where you cannot be as granular with resources.
I would recommend using Image Pre-loading which can help your page loading times, even when its large.
Related
I'm excited about the rel="preload" property, because it looks like it can help speed up page render times.
The use case is a web page with a large image above the fold. Right now, Chrome doesn't start downloading the image until after fetching jQuery (a fairly heavy file). With preloading enabled, they download in parallel.
But I'm reading conflicting reports about whether I should use preload for things that are in visible HTML elements elsewhere (as opposed to things made visible by user interaction, like a dropdown menu).
This post seems to recommend not preloading:
When not to use preloading:
When the asset is referred to somewhere else on the same page.
When you're not sure the user will actually require that asset. Like on a page visitors only go to 3% of the time.
While this one seems to indicate it was really helpful for a similar situation on the Financial Times website:
When the Financial Times introduced a Link preload header to their site, they shaved 1 second off the time it took to display the masthead image...
So which is it? Should I provide an early "hint" to display the always-shown, above-the-fold image? Or should I just let the browser get to it in the usual order?
I think that in cases involving performance optimization, you really want to create an A/B test to determine which one you should do. There really is no cookie cutter answer for image preloading that applies to everybody as a best practice.
One of the biggest tenets of a favorite book of mine, Lean Enterprise, is use to A/B tests to prove or disprove a HIPPO (highly paid person's opinion). Certain opinions carry a lot of weight, both in your organization and on the internet. Because of their importance and reputation, their opinions veer towards the realm of fact, even though it may not be.
The practice of measuring performance empirically is also touted by another book I love which deals with performance tuning - Code Complete 2nd Ed. In that book, McConnell gives several code examples where you would expect one piece of code to be optimal, but in fact, it performed poorly (see chapters 25 and 26). One of his key points is that you should always test a performance optimization. If it isn't worth testing, it isn't worth writing the "highly performant" code in the first place. McConnell's premise doesn't just apply to his low level coding examples, but to high level decisions such as preloading images above the fold as well.
I can also attest to the importance of A/B testing at a professional level. I used to work on Amazon's SEO team and we A/B tested everything. The fact of the matter is that you never really know how customers will respond to something. Nobody can predict customer behavior - not even Jeff Bezos - and you really need to back up your hypothesis with real data to prove or disprove the validity of what you're doing.
Even though you can find multiple blog articles and online sources discussing whether preloading is better or not, you don't really know whether that will work for you until you've done it. Different people have different servers with different performance characteristics and different network topologies, etc. You just don't know which way is better for you until you have the data. If you launch your A/B test and find that find that your repel rate goes up when preloading, then you know that you have to dial back your treatment and return to your control. If however, you find that customers don't get bored waiting and click through at a higher rate than before, then you have a winner and you dial up the treatment - deleting the control code entirely after a period.
I hope that helps.
The article is wrong about those statements. Preloading is used by the developer because he already knows those assets are needed on a page. Preloading is not a "hint". Prefetching is more in line with what he states, that you are telling a browser that it's possible the asset may be needed.
If an image is above the fold, then you know it will be needed, and that is exactly what prefetching is for.
Addy Osmani of Google
preload is a declarative fetch, allowing you to force the browser to
make a request for a resource without blocking the document’s onload
event.
I would use rel="preload" for images only if they are to be found in css, javascript that will led to a bottleneck in the render of the page at a later time, if user driven events will request the image and it will have detrimental impact in user experience or if you are experiencing any flows due to this large image in the rendering of the page.
I understand your image is above the fold, and if it's to be found in the source code from the beginning I would let browser prioritize what to download first.
On the other hand you could always A/B this change and see if it works for you.
I have been working on a few factors to optimize my webpages. I have optimized the delivery of everything else and now I am thinking about making some optimization related to the HTML.
Since HTML can change frequently I was thinking caching it would be counter productive or an overkill but I know exactly when my HTML is going to change ( it changes every six hours). Is caching my webpage for lets say 1 or 2 hours worth it? What are some best practice that I should follow in case I decide to cache HTML?
For most smaller to midsize web sites, I would think this would be overkill.
In order to determine how much time is being saved, the question is: how large is a given page on a site, and how often will people be clicking between pages? (Or, for that matter, are your users on particularly slow connections?) Unless the pages are very large, or people are spending a lot of time clicking between pages, the time spent loading the pure HTML should not be especially significant.
The CSS and JavaScript, sure, that makes sense to cache, but I believe most browsers handle that caching automatically. But loading HTML content is a relatively quick process; unless you are using a vast amount of HTML-generated graphics or other items (e.g. HTML5's SVG) I can't see much need to store that for later.
Think about how your users browse your sites - will they be visiting each page only a few times, or is your site built in such a way that they have to keep clicking back and forth between pages?
Any site that would have people clicking back and forth sufficiently often to merit this might benefit from being built as a single-page application (SPA). If people are clicking back and forth enough that caching HTML becomes a serious concern, it might be better to think of those as different parts of one page.
I want to make a site from scratch, and Im considering to use Flex to make a R.I.A instead of the standard approach (xhtml + css + some ajax).
The kind of site I want to make is something like e-bay, but less complicated.
But.. I know that 95%+ of the sites like that are built in the previous mentioned techs... so, what are the cons and pros if I want to make a pure Flex site?
Thx.
If you write an entire website in Flash, the entire website lives at one URL. (Short of mucking around with whatever Flash provides to let you offer deeper links.)
Whereas a website written in HTML, unless you go mad with your AJAX, lets people link to the stuff they’re actually interested in, like unicorns:
http://cgi.ebay.co.uk/DESPICABLE-ME-AGNES-Unicorn-Doll-Plush-Character-Doll-/180602861597?pt=LH_DefaultDomain_0&hash=item2a0cc4f81d#ht_1755wt_907
Or for a non-eBay example, Stack Overflow questions:
Flash for business web applications - why not?
HTML also has a pretty standard and understood user interface: links, and form controls. (Mainly links.)
Flash doesn't work on iPhone/iPad. End of story.
Other reasons: not a web standard, often quite slow, not good for SEO, etc.
It requires users to have a proprietary plugin which some users don't want and other users can't have (since isn't available for all platforms (iOS being a key example)).
It also has performance and stability issues on some platforms (OS X and Linux being prime candidates).
While some search engines have started to index Flash content (so long as it exposes the information), the results aren't as good as for content rich HTML sites.
You can do that simply using traditional xhtml + css + jQuery (or any JS framework if you want to increase UX). Flex won't do much in your scenario.
In my experience, performance is not a real issue unless you play video - one can write bad programs in JavaScript, too...
Your pros are mostly on the development side: You can have a great looking site quickly, and you can almost completely forget about browser incompatibilites.
You rely on the customers having the plugin installed, though, and you rely on Adobe's technology for development and playing of the content.
If this is not important to you, and you can afford to do without all iPhone and iPad users, accessibility and standards compliance... go for it!
Flex is good if you want to install as an application using Air. ebay actually has a RIA version, or at least they did for a while.
There are several concerns with a Flash site, some of which Adobe has addressed in the last couple of years.
One is accessibility. It is more difficult to make a Flash site accessible to the visually impaired, who use screenreaders.
Related, people like to be able to copy and paste content, as well as print. With standard web pages, the developer need do nothing to support this, it just works from the browser. With Flash, you'll have to take care to make your text content selectable, and I'm not sure a user could ever select a section of text + images. I've never done it, but I can only imagine that implementing printing ability in your Flash site would be nightmarish, at best.
Another is linking and addressability. For most sites, you can copy or at least get a link that you can share or save to get back to where you want to be. With Flash, you usually go to a single address and then the rest of of your experience happens inside the Flash "window" and the browser isn't actually navigating any pages. It is far more difficult to implement this ability in a Flash site.
A Flash site is usually very slow to load, especially the first time, and page load times are immeasurably important to a site's success.
Finally, you've perhaps heard the furor over the last couple of years about different vendors supporting or not supporting Flash in their products/devices. An all-flash site would be completely inaccessible on any iPhone or iPad, for example, which do not support Flash at all. Furthermore, some employers do not allow plugins like Flash to be installed on work machines, so you'd eliminate that portion of possible traffic, as well.
Nobody has yet mentioned Silverlight.?
I mostly agree with Jay's answer concerning accessibility, but as a further note would like to add that development in Flex/Flash vs HTML/CSS/JS could be more costly not only in terms of money but also for maintenance. Many Flex/Flash devs typically charge a higher price and their dev tools, which are necessary for compilation, usually aren't free, compared to HTML/CSS/JS devs, who often use freely available text editors.
This question already has answers here:
Closed 13 years ago.
Possible Duplicate:
Does it make sense to use the <table> tag on a “modern” website?
Everywhere I go I see don't use table layout, it's evil, even Google says that, so why one of the most visited websites, Google and Twitter, use it for their homepage?
I don't think it is any kind of mistake, or any other stupid problem.
The only reason I can think of is, that they want the page to look similar even if client doesn't support CSS, like with Lynx.
So why everyone say it is so bad, if the biggest websites on the internet use it.
In my opinion, there are some cases, like those mentioned above, where it is vitaly important to have the same look everywhere, than it is OK to use tables.
edit: The same question goes about html elements like <center>, or formatting text with attribute align and other "html attributes and elements used to substitute CSS functionality"
Page load time is king for these guys, and bandwidth usage is extreme.
I'd have to say they use tables for raw data speed, since they are serving up so much bandwidth every day.
Also, notice that they use inline styles in the page header to reduce the number of HTTP requests to help speed up page load time.
Table layout gets more grief than it deserves. It's easy for developers to use, it's consistent across nearly every web browser, and it allows you to easily add rows/columns with little to no effort.
The only downside is that it goes against the mantra that your document should only contain content, and your design should be contained separately (in a CSS file).
Google doesn't have to care about ranking high in search engines... ;)
Yep, agreed. Sometimes, just sometimes tables are just fine. Not everyone is writing websites that are targeted at every possible browser, that needs to support text to speech etc. In general, try to learn and grow your skills and use CSS positioning etc, but nothing bad will happen if someone uses a table to position things on a webpage.
Maybe this question should be community wiki, though?
It's evil, it's a pain, but rendering is pretty much guaranteed to be consistent across different browsers.
Table layout is working on most browsers. Google and others want to reach all user, not some or only modern users. Having different layouts or layout technologies is hard to maintain and costly in delivering content.
Table layout is not tricky. Its straight forward. You dont have to look for css hacks, browser incompatibilities or others.
Table layouts are bad. Because thy mix layout and content.
Twitter works pretty well from phones in web mode. Some web browsers are truly gruesome, so I assume Twitter does what it has to.
Given how poorly so many web sites work on phones, I'm more concerned about mobile compatibility than with the concerns of CSS evangelicals.
Three main reasons:
Tables are mainly bad for search engine reasons (there's also the issue of them messing up the DOM a bit, but that's not too bad). People don't search for Google on search engines, and people don't search for Twitter posts on generally either.
Tables render consistently on nearly every browser, including smartphones (which is a big concern for Twitter especially).
Tables consume less bandwidth. Both sites have immense data loads and need every bit of speed they can get.
Browser Support - These guys need to have their websites render perfectly on ALL web browsers (New, Old and Obscure). No matter who's using their websites and what OS/Browser their using, these websites need to work.
Each web browser supports it's own implementation of CSS and this causes a similar issue to that of the JavaScript DOM support in various browsers.
Page Load Time - Also their pages are optimized for Page load times. If it takes a user too long to load the page they'll just go somewhere else. There are still plenty of users without broadband, even a lot of mobile devices don't have very fast connections depending on where you are.
With today's modern mobile phones, is it still worth programming the mobile version of your site in WML?
Most mobile browsers even a few years old can manage to do okay in regular HTML. With WML, you are obviously given more control over what is displayed and what isn't with less fear of it not working on a particular device, but today, with all the advancements in mobile browsing (iPhone, Android, etc) is it really best to go this route?
I am wondering if the best option is instead to go with an HTML4 document that has a few more bells-and-whistles than what WML can do, but not quite the glorified super-spectacular AJAXified interface that one might design for a modern desktop browser.
Yes, I know, this is objective and has a lot to do with site audiences and how far I want to extend support. To put a scope to this question, my main concern here is whether foregoing WML for HTML is going to devastate a huge chunk of my audience and leave them completely stranded.
Edit for Dr.Dredel's point: the site would NOT be used by an SMS campaign or anything of the sort. The website is an event booking site for pickup games for hockey. Some users currently browse to it on their mobile phone to sign up for different sessions.
Do both. There's no reason to ignore the browser string and display the same markup for every device. WML is simple enough that you can use template styles (which you should be using already) to provide a custom experience for all your useers, regardless of the device they use.
Those with bare cell phones will get a usable interface that meets their needs, while those with PDA phones get a nicer interface with more options, and those with the iPhone might even get the eye-candy iPhonophiles really bought their phone for.
If you can't do that, for whatever reason, go with the least common denominator to gain the greatest visibility and usage - that's what's going to make your site successfully and useful enough that you can afford to use a real templating system and move towards the ideal state. This is likely WML, although even older phones were ok with very simple HTML, it just has less control and ease of use features.
-Adam
I think the primary problem with this question is that it fails to identify what exactly it is that you're offering your users, which would instruct who, demographically, would find your site.
If your site is arrived at via SMS based links (through some global marketing campaigns) then you need to try to reach the widest possible audience, since almost all phones will allow a user to click within their SMS client and then launch whatever browser option is on the that phone.
If, on the other hand, you have a site which needs to be browsed over to manually, then there's a reasonable expectation that most people simple won't bother on their crappy pseudo browsers, because even the act of inputting the url is a fairly large hassle.
I would say that if you're dealing with option B you're pretty safe just delivering an experience that is tailored for a browser like Netscape 1.1 (just dust off whatever you were doing in 1995 and you're good to go! :)
The vast majority of mobile phone users have a phone that was purchased within the last few years, and any users that have a phone older than that are unlikely to want to use the internet from their mobile. Personally I think you would be better of making a high-end 'AJAXified' site with all the bells and whistles and a standard XHTML-MP site that would be accessible to most users.
You should use XHTML-MP for mobile versions of sites. You'll get better continuity with the non-mobile version and it will work with more (particularly newer) devices