What is a large scale website? [closed] - terminology

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I was reading a job listing that said:
MUST have prior experience on large
scale websites
What is the definition of a large scale website? Is it defined by a certain number of pages in a site or traffic perhaps?
What is a large scale website as referred to in the job listing?
* EDIT *
This is the full job listing so you can see how it relates to the position:
Strong HTML Developer
Specific Requirements:
MUST be local and be able to work onsite.
MUST have prior experience on large scale websites
Prior ad agency/comparable experience is ideal
Possible Fulltime Opportunity

Large scale website is a relative phrase, for what one consideres large, another considers mid-sized.
I would expect they want somone who has worked with the issues of high visitor volume and spreading a website over multiple machines - maybe even over an entire server farm.
I would also expect that a large scale website has a lot of individual pages or sections.
Definitly large scale websited are the portals of intel.com or microsoft.com, both in sheer volume of information presented and dayly visitors.

A movable feast.
I would personally measure the size of a site by a combination of it's traffic, it's server footprint, and (where applicable) it's sheer content, but the statement here is obviously unqualified so you're guessing at what large is. Biggest thing I've worked on had two "pages" but had several thousand requests per second, which is more important?
If I was hiring I would basically consider any non-trivial site (i.e. more than a four page site for some random shop or hotel or such) sufficient, but not meaningful in and of itself.

Definitions of large scale can differ.
But even if we don't know exactly how to measure scale and just how large is large, I think we can say that if a site runs on only one box it's probably not large scale.

Related

Any downsides to exclusively using SVG image files? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm building a photography portfolio website, which will have a fluid, responsive design. To have the images look good at all sizes, and to not have to deal with retina resolution issues, I'm thinking of just using SVG files for all images.
Using SVGs sounds like a perfect solution to these issues, but for some reason I haven't seen any websites exclusively use them, which makes me wonder if there are any downsides to them (aside from lack of support in IE8, which I don't care about).
If you use them too much, or in animated form the end user might have some performance issues, especially on smart phones. Icon fonts are much CPU-friendly, but they are much simple and monochromatic.
Other than the lack of support for older-browsers, there's no downside to them. We love SVGs.
As mentioned in the comments, I would go with SVG icons/sprites/cartoons, and stick to bitmap/raster formats for photos. Photographs are bitmaps by nature, and when trying to convert them to vectors you may find some issues:
Not everything can be converted into a vector... or it could, but at a high price (bigger file size, complex files that require more processing). Then we could start a whole debate about file size vs image quality.
You are limited by the camera/lens technology: using photos in SVG may give crispier/sharper edges on scale, but the details inside won't appear because they are not there (e.g.: you may have a picture of a hand in SVG, but it doesn't matter how much you zoom in, you may prevent pixelation but you won't see the cells either).
Older browsers will not support the format (although you already mentioned that this is not a problem in your case).
Then there are other issues specific to a photography portfolio/store website:
If you are planning on selling the pictures, by using SVG you'd be giving the product away for free: right-click, "Save image as..." and the user will have the full size image without paying.
You could add a message/watermark to prevent that (or to sign/give credit to yourself), but watermarks would be "easy" to remove. And sadly we all know how the Internet works.

Web Design and working with images [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I've been an IT pro for awhile and I am recently getting more and more into web development. I'm especially interested in HTML 5, CSS 3, JavaScript, jQuery, and responsive design concepts. One thing I always seem to have problems with is images. I'm hoping some pros here can help out someone just starting.
Where do you find images to use for your client's sites / or your own sites?
Besides taking your own pictures, is there a "go to" site that devs use that has good variety, high quality, and is preferably free?
Once you acquire some images, do you go through a routine of re-sizing them or otherwise fixing them up for use on your site? Gimp is pretty good for re-scaling, but sometimes the image quality degrades. It's probably best to get good images with the right size to begin with. Is there some CSS magic that devs typical use to get their images the size they want?
Like I said, I've been using Gimp to do simple things like create cool text, re-size images, and create basic banners. Is this a pretty good tool to use for this, or am I missing out on something better (and easier to use).
I've read a lot of articles online, but I trust people's input on this site.
If you need images for production, that you yourself can't make, you can check out shutterstock, for example. If your clients need photos or graphics, they will have to pay for them, one way or the other ;)
Here are some good primers for dealing with images on the web:
Adaptive images - http://adaptive-images.com
or
Responsive Images - http://scottjehl.github.io/picturefill/
Retina Quality Images on the Web – http://imulus.github.io/retinajs/
With Bitmap images (Photos for example) always get the largest you can get and scale down to the sizes you need. With Vector - SVG for example - you can scale without losing quality, but when you scale vectors you will likely have to rework the drawing, because the proportions will not fit.
GIMP is open source and if you can not spend any money it will do the job. Like is said: scale down from large photos. No the other way around. You will lose Sharpness and Quality fast when enlarging images.
I don't know of good Photoshop alternatives on Windows. But I could give many great and cheap alternative for Photoshop, should you be using a Mac.

Why not always use 2x images when building web pages? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I was having a discussion with a designer friend yesterday, the salient points of which I'll detail below:
2x images are larger files, but not the 4x you may think. In one example a 1x image file is 47kb & its 2x counterpart is only 55kb.
2x images are only for Retina screens, and despite being phased in on the desktop/laptop side, the truth is that most retina screens are mobile.
While wifi is becoming fairly ubiquitous, desktops (mostly 1x) are the only devices that never have to download data off a cell network.
These all led me to posit the question: Why are we spending energy on providing 2x images, when they are mostly accessed by mobile devices which have the greatest bandwidth limitations?
After sleeping on it, I started to wonder: well fine, if we're going to ignore that last issue, why not just only deal in 2x? CSS can handle scaling down the images in any case (perhaps I'm wrong here?) so why not save the media queries & save the effort to generate and store 2 copies of every image by just using 2x everywhere?
Am I crazy?
The file size issue does bother me. I think things should be as small as possible.
If you're not worried about that, though, the only, temporary issue I can think of is browser support for background-size. IE8 doesn't support it and it's still used enough to have to worry about it (at least on my projects). There's a polyfill for it, but it's not up to snuff with the real thing.
I think the answer depends on where you live in the world. Believe it or not, I live in an area with a lot of country roads that still only have dial-up. Sometimes, even that does not work. We are still not nearly as high-speed as we should be with desktops. I can't imagine them having to download that extra data when they view 1x.
So, I think it depends on your target audience, where they are more likely to live or what devices they use. We will get there in time, but for some, not yet.
Let analytics be your guide
I use the 5% rule. Once any feature is more than 2 standard deviations out of the norm, I drop support for it. In browserland, that means IE6 and IE7 are gone for me but I keep supporting IE8 because a size-able chunk of the audience is using that feature. Yeah the big guys like Google have dropped it but I still see a good chunk of traffic from it on a lot of sites. Why make them suffer?
Now how this relates to your question: ask yourself what percentage of your audience is on a 10Mbps+ LTE connection with retina screen. Maybe in your case it's 95% retina screens with LTE on mobile, but check your analytics package. My guess is that it's probably under 20%, in which case having fall-backs gives a better UX to 80% of your audience - easily worth the effort.
In my opinion I see those problems:
some older phone models (ex: iPhone 3G) and tablets (ex: iPad 1) have low memory. A big enough image can cause out of memory errors.
to scale an image the system has to load it at full size and do a complex scaling operation each time it draws it (sometimes it is cached).
a scaled down image doesn't look as good.
you can run into problems with them in older browsers (as mentioned by Bill Criswell)
it increases download size. If we consider a 10kb increase in size / picture * 10 pictures per page than you get 100kb per page load. If your page has to display a lot of images (think social), than the overhead is a lot.
you can improve your search engine rankings if your page loads faster and it is smaller.
The only major issue is file size. And as you state, in a lot of cases, the file size differences are minimal.
If we're talking mostly icons, the benefit is that a) icons aren't huge to begin with, so the file size increase is minimal and b) icons benefit the most from retina resolution.
On the other hand, if we're talking 'full screen' news photos, those could be quite a bit larger file-size-wise, but also look perfectly fine if they are not retina (as they are continuous tone) so there's a less compelling need to make those retina if you are targeting a mobile device.
A compromise for the latter might be to lazy-load them. Check the screen size. If phone-sized, load the regular image and call it good. If it's larger than phone size, load the regular image, then go back and grab the retina version for those on an iPad 3, for example.
The only technical problem is IE8 and older. They can't handle the CSS you'd typically use for retina images. There are workarounds, but not for sprites--which you'd commonly use for icons.
Eventually, we'll see more SVG support, which will solve this problem--at least for icons. When I am doing pure iOS work, for example, most all of my imagery is SVG now. It's smaller, and automatically retina-ready.

Responsive Webdesign - Performance optimisation [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
my new website is now finally finished and it runs pretty smooth, on most devices i tested. the only thing I optimized was the code, so i deleted all comments and other unnessescary lines in all .css and .html files. but beyond that, what else can i do to optimise a website specific for mobile contextes?
you can see here here (all images are only used for demonstration): http://mbaljan.de/weblab/sites/designtisch/
Firebug "page speed" provides lot of optimization options . You can try them .
You consider changing what is being served to the browser based on either internet connection speed or device or both. For example, serve smaller images when the website is being viewed on a mobile device. That would speed up the load time. Check out Adaptive Images to do that: http://adaptive-images.com/
Apart from that, trying to reduce the number of files being loaded is a good idea. E.g. 1 jQuery/javascript file. You can also try to minify all your javascript files (and CSS if you really want to) to reduce their files sizes and decrease load time. If you intend to modify those files again in future you'd have to keep an uncompressed backup though.
Check out: http://javascriptcompressor.com/
Another thing you could make sure you're doing is using image sprites. That way you reduce the number of image files being loaded. This won't work with Adaptive Images, so I find it best to use sprites just for things like logos and icons.

Preloading 20MB+ of images. Is it worth it to attempt this? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I'm developing a photography portfolio website. I want to know what would the best practice be for downloading images from a database. As of right now the entire gallery is roughly 20MB. The gallery is still in development, I intended on just having an "loading" graphic run between photos. But the client seems to prefer image preloading. Is it practical to have the page preload 20MB+ of photos, and if so, what is the best way to do so? Or would it be best to go with the loading screen?
20MB to fetch in one go is too much, it will result in a slow and annoying user experience. You should probably ajax-load each image in turn.
Incidently, how big are your images? An 800 x 600 jpeg should be around 50k at 90 - 95% quality. So 20 MB would be 400 images. This seems like a lot for one page. I'm guessing your image sizes are large - consider reducing them. If you want to have hi-res, non-compressed versions available, have these individually linked.
Edit: Just for reference, what I would consider a very large page (the html doc + all css, js and image assets) would be ~ 1MB. An "average" sized page is probably ~ 100k.
Why not "thumbnailing" images via some server side script, preload thumbnails & display full image on thumbnail click (using some kind of lightbox js)
This would reduce a lot preloading time while keeping full porfolio preview.
I think the better way is to preload the next couple of photos while you are viewing the current one
Yeah, definitely don't do this. Rememebr that some users will be connecting with mobile connections and some of them paying by the megabyte - if you do this then you've just used up 20 MB of their allowance with images that they may never see.
I don't think either solution is practical - I would suggest you scale down your images.
20MB is probably too much unless it is a specialized application where you are confident that 1) users will wait and 2) that they will view the majority of those images. Otherwise, you are wasting bandwidth.
I would look at a strategy where your images are cached in server memory to avoid database traffic combined with client-side pre-caching of a few images where you can add it. For example, if the user is on image "A", load "B" and "C" as well.