This is not really a answer I NEED but it is more of a curiosity for me. I personally make my webpages dynamically by checking screen size then create my divs from that size. Now what would be the benefits of a 'static' sizing(like using px) over my method?
The obvious answer would be the benefits to control over your design. Plus, by generating your pages' content entirely on the fly, you're making the (usually, but not always safe) assumption that your uses have javascript enabled. Without a fallback default, what are those non-JS users going to see?
Personally, I'd opt for making large-scale adjustments based on screen/window sizes that fall within a range. That way you're not having to dive into the DOM every time a user adjusts their viewport, plus, as I said earlier, you've got a great deal more control over how your content is presented.
Just my two cents...
I determine which stylesheets I send to the browser based on the size of the window and type of device - but they are fixed width pages. I personally find it very difficult to write good looking websites that scale well and look good on both low and high resolution screens. Keeping control of 2 or 3 different "sizes" is much easier for me.
Waiting for javascript execution also delays the time that users can start reading your content, and is not always desirable.
And sometimes an art designer would actually do that layout designs, where you just put in the vital codes to make things work... And they happen to use a lot of static image sizes for decoration...
Accessing dom can be slow and expensive, for some pages that I just want to see the content fast and clear, maybe all those resizing really isn't necessary.
Related
I am developing a website with React which has what we called "snippets", basically a modal window displaying some kind of media (audios, videos, slides, text quotations, pdfs). These media have "positions", as a page number, an image number, a playback position, or a scroll position. If she likes the user may store these snippets together with their positions in a "locker" and come back later to whatever is in there. Visually the locker will hold a "thumbnail" of the snippet representing the appearance of the snippet at the time of storing it. My question is how to go about making such a on-the-fly thumbnail. Two approaches come to my mind, however, if you have other ideas I am eager to hear them.
Component approach: Since I already have the component, I could reuse or rather clone it, scale it down, disable it for mouse interaction. Would React.cloneElement() be the way to go?
Advantage: Easy to do.
Disadvantage: Too many duplicates of potentially resource-heavy components may slow down website. Styling may become non-trivial as some embedded media (audio, video) bring their own potentially inaccessible styling with them.
Image generation approach: Since I only need an image, I could take a screenshot of the snippet area, scale it down and use it. Can this be done fully (from generation to usage) on the client side? Is there a good library which does the heavy-work for me?
Advantage: Resource-heavy only during the making of the thumbnail, resource-light in the locker. Accessible for any styling.
Disadvantage: Potentially difficult to do?
After some research I found a solution. Interestingly, it is a mixture of the two approaches I was able to think of. It is possible to access and rasterize the DOM elements which make up the snippets, draw them on a canvas and turn it into an image. The most popular library for this seems to be html2canvas, however, there are a number of others among which rasterizeHTML and html-to-image seem to stand out. Often wrappers for React exist, in the case of html2canvas, for example, use-react-screenshot.
I'm currently maintaining an old legacy project, where I just noticed a message from my browser about how scroll-linked effects reduce rendering performance.
The application is rendering a large form, on the bottom there is a slider with lots of data, which will be loaded asynchronously (and only if the user scrolls down, so it gets into his view). Afterwards it creates a lot DOM-elements (a lot means a typical of 100-300 figures with an image, texts and some attributes each) that will be added into the slider.
So I was reading about Scroll-linked effects on MDN to take care about this performance issue, but I don't know what's the best practice is. Neither I can use the examples about "sticky positioning" nor "scroll snapping". Also I do not want to customize scrolling in any way.
The goal is of this behavior is to delay loading the big bunch of data as much as possible (since only when the user scrolls this page down, he really needs this data).
Can you please help me how to take advantage on this, to optimize the scrolling performance of the application without losing the lazy-loading feature?
You can use a combination of check element visible in the viewport + requestAnimationframe
https://stackoverflow.com/a/125106/800765
I am pretty sure that I know the answer to this already, but I am interested to see if anyone has other ideas. We are working on a website to include a major redesign with mega menus. One of my top things in a redesign is to reduce the page download time as much as is possible. All my images, css and javascript are cached and that's good. However, the part that I am trying to work through is the html coding for the menu, and if there is a way to locally cache that within reason.
As a side note, I like to do things as pure CSS as possible (for SEO), and so that would include outputting the mega menus directly onto the HTML page. But at the same time, I know that if it takes a number of seconds for the page to download the html content at the top, well, then, we are probably going to be running some customers off there too. Maybe the best then would be to have JavaScript output the menus, but then you run into the couple of customers that don't have Javascript enabled.
Right now the pages are about 30K for the menus, and I anticipate that doubling and maybe more when we do the redesign.
Do you have some thoughts for this issue? What would you see as the best way to tackle this?
Thank you!!
JMax
Honestly, 30K for an element is nothing in this day and age, with high-speed connections common and browsers effectively caching as necessary. People don't leave because of a second or two. It's when you have Flash movies that preload or crazy auto-starting videos that people get annoyed in a hurry.
I've got a similar application with a menu that's likely double that right now...let me add, it's not by choice, it's something I inherited and have to maintain for the time being. The menu is output simply in an unordered list and then I use Superfish and CSS to do the styling as necessary. There's an initial hit, but after that, caching kicks in and we're good to go. Even as crazy as it is, the load isn't prohibitive. Navigating it, however, is a mess. I'd strongly recommend against confusing the heck out of your user with so many choices, especially on a mega menu that can be a UI hurdle for disabled and older users. When you boil it down, the whole basis behind the "Web 2.0 movement" (I hate that term) is to minimize or cloak complexity.
If you're REALLY concerned about performance, start off with what you're loading. Limit your Javascript by combining files, especially those small Jquery files that tend to stack up. HTTP requests can severely impact a site, especially since they monopolize the loads initially. Similarly, combine small CSS files and optimize the rest via an online tool To reduce image loads, create sprites for your graphics so you're loading one file instead of many. Here's a tut on Sprites and a simple google search will give you dozens of sites that will build the sprite and css automatically. Load anything you can from CDN, such as Jquery, Prototype, etc (hopefully only one framework per site, because two or more is unnecessary)
If you're still out of hand, look at your graphics one more time. Could you take advantage of pure CSS or image repeating via CSS to reduce loads further? Have you optimized all the graphics? Could you tweak the design to take advantage of those tricks?
After all that, if you simply can't change the menu to be more friendly, start investigating options. However, I suspect you'll find better gains in the first couple of steps than you would from taking extreme measures on the menu.
You could either set HTTP caching for a javascript code file that generates the menu, or use ajax to insert a pre-generated HTML menu from another file (again with a long expiry date set on cache).
Both those solutions require javascript through. I can't think of another way to remove the menus from the HTTP traffic apart from an IFRAME (yuck).
30k is massive for plain HTML though - do you REALLY need such a huge navigation structure?
My demo is here.
Basically, I have a HUGE image (19160px × 512px to be exact, just under 2MB) that I transition the backgroundx using javascript to make it appear as if a transformation was happening.
I cannot compress the image much more without ruining its quality dramatically. Is there another way that I can achieve this with the same level of cross-browser and not rely on plugins like flash, but have it load faster?
Have you considered making this a video?
It might improve loading time somewhat.
Also, another idea. Have you tried using only the first and last image, putting the last one on top of the first, give it opacity:0 and fade it in using JavaScript (e.g. jQuery)?
The effect won't be 100% identical to what you have now, but it might look good enough to please the client, and it would reduce loading time to a bare minimum.
If both ideas won't work for you, I think the first 10-12 frames could be compressed more effectively as GIF images. (It's an estimate, I haven't tried.) You would have to split the image into multiple div s to do that and change the method you use to switch the images, and you would have more requests, but it could be worth it.
If it is a jpeg, you can always use progressive encoding. it will become clearer as it is downloaded.
There is also an interlaced
"Progressive JPEG" format, in which
data is compressed in multiple passes
of progressively higher detail. This
is ideal for large images that will be
displayed while downloading over a
slow connection, allowing a reasonable
preview after receiving only a portion
of the data. -Wikipedia
Slice it like Google Maps.
If you want to change that many pixels on the screen at once, you'll have to get them to the client somehow. You could chunk it into multiple images and use something other than background-x, but then you expose yourself to other potential network interruptions along the way.
The only alternative I can think of to precomputed images like this one is to do the computation on the client - start with the full-colour image and manipulate it using the client's CPU. Your options here involve canvas or CSS3 or a plugin.
I'm not a big fan of Flash but in this case it seems like the right tool for the job (unless you need it work on the iPhone). If you don't have the Flash authoring tool you can use the free Flex compiler.
See http://www.insideria.com/2008/03/image-manipulation-in-flex.html
Make it into an animated gif? Break it up into individual parts to remove all the area that is obscured by content.
Is there a good advisory / best practice manual etc. out there which outlines methods to make a page layout fluid in the following two ways:
a) The layout should be robust under window resize
b) The layout should seamlessly handle font resizes committed by the user
Every time I design a page layout I end up using different, ad-hoc methods to make the page robust under both a) and b) above. Some of the methods I have used before are:
handling body onresize()
declaring all values in % (this gets stuck when image dimensions have to be defined in px)
placing a div at -10,000 px and polling it at intervals to check for font resizing (gasp!)
I find these above methods quite bad and would love to find standard, robust methods for this problem. I am sure other people here face (and solve) these problems everyday.
Designing web pages is like cooking for a large group of people. There will always be people who dislike your cooking. What you need to do is to design in a way that will make most of your visitors happy.
All liquid pages will have a mix of viewport-relative sizes and fixed-pixel sizes (for, as you noted, the images, and other elements that have to be sized to match the images). You may also want fixed-em sizes for some elements.
So a common approach would be, say, to absolute-position a fixed-width sidebar on the right, and give the main body text a right-margin equal to that width. There are many methods for achieving these kinds of layouts — see endless posts about ‘liquid CSS columns’.
In the most complicated cases, where CSS alone is incapable of giving you the combination of relative and absolute you want, there's always tables. Not ideal, but generally better than JavaScript-dependent layout.
If you are looking for more specific layout solutions, I would say a common practice these days is to use a pre-built grid layout. There are fixed width and fluid versions, both of which scale up with the user's font size. YUI also has one. No JS, no off-screen stuff.
But I also see reference to the user scaling the text from within their browser. This is not the problem it used to be. It used to be that you had to be fairly careful-- if you put text in % it would scale, but px wouldn't in some browsers. Now, all the browsers scale up the page as a whole, including text and images-- proportional to each other. The text size adjustments are really like you are "zooming in" on the page, as the images grow as well. You can simply measure text and column widths in px (or % or pt or whatever) in the "full size" mode, and browsers adjust nicely.