Bug 534855 (RHQ-1610) - Improve apparent UI performance by precaching some images.
Summary: Improve apparent UI performance by precaching some images.
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: RHQ-1610
Product: RHQ Project
Classification: Other
Component: Core UI
Version: unspecified
Hardware: All
OS: All
low
medium
Target Milestone: ---
: ---
Assignee: RHQ Project Maintainer
QA Contact: Mike Foley
URL: http://jira.rhq-project.org/browse/RH...
Whiteboard:
Depends On:
Blocks: jon3
TreeView+ depends on / blocked
 
Reported: 2009-02-19 14:30 UTC by Corey Welton
Modified: 2014-05-02 17:48 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-05-02 17:48:29 UTC
Embargoed:


Attachments (Terms of Use)

Description Corey Welton 2009-02-19 14:30:00 UTC
In a modern, event-driven webui, there are a lot of times where new content does not render/appear until it is triggered by an event, or hovered, etc.  In these instances, and especially over slow connections, there are often apparent UI artifacts that appear while user is waiting for said content to render.  An example of this might be the ALT or TITLE text values of an image when the user is waiting for an 'on hover' image to appear.

One way to give the UI a more responsive appearance is to precache such images or content.  There are several ways to do it, but the easiest method in most modern browsers is to use a hidden div.

Using CSS to create a DIV with properties akin to :

div.cache {
                  position:absolute;
                  width: 1px;
                  height: 1px;
                  display: none;
                  visibility: hidden;
}
...and then storing said hover/event images in a div at the top of the page content helps to alleviate apparent 'lag' in image/content loading.

Note that "1px" above is necessary for cross-browser compat.. some browsers will not load the content at all if it is listed as "0px"

Considerations:
* Determine how much is going to be gained here -- you don't want to cache EVERYTHING at the expense of overall page load time.  Use the method on those areas that would provide quick wins and/or the greatest return.
* You may not need this on every single page with the content -- perhaps a root page or two -- for example, in RHQ, the main resources page, versus every single sub page.
* I have never used this with javascript, but I think this technique works here too.

Possible candidates for precache:
* The "favorites" on/off star images (I have actually noticed the lag on this image, even over fast connection)
* Images that make up the main menubar dropdowns.
* Icons in the left-nav
* ...probably others that haven't immediately come to mind.

If we decide to use this technique, perhaps turn this jira into a feature and create sub bugs  for all the different places that will feature content precaching.


Comment 1 Red Hat Bugzilla 2009-11-10 20:36:42 UTC
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-1610


Comment 2 wes hayutin 2010-02-16 17:08:30 UTC
mass add of key word FutureFeature to help track


Note You need to log in before you can comment on or make changes to this bug.