According to Google, up to 80% of the total factors that influence page speed and performance, are accessible to front end web developers. This suggests that properly optimized and condensed websites can lose almost half of excessive lag in load and response times.

This page details measures that San Diego Web Studio undertakes expedite site speed and responsiveness. We've listed some favorite tools and techniques for style sheet compression, enabling parallel loading of JavaScript, and keeping things lean.

• we optimize and minify css style sheets for optimal performance
• remove white space from markup and css and compress file for minimal size
• avoid use of css expressions, [patchy hack solution to ie 7's poor css support
• we compress certain files, when appropriate, to further reduce their kb overall size
• take all necessary measures to minimize the number of http requests on the server
• we reduce the size and scope of the Html Markup, where possible
• we minimize size & weight of graphics, implementing proper use of file types
• apply image compression when applicable
• specify height and width dimensions for inline graphics
• serve scaled down images by optimizing for web with adobe image ready
• further optimize image sizes by use of sprites for background images
• minimize and condense javascript files, often combining multiple scripts on one page
• avoid inline css styling wherever possible, unless it improves speed, in a certain instance
• remove unused css styles from style sheets, dusting them for unused attributes
• defer JavaScript loading until after CSS Style Sheets have downloaded
• eliminate duplicate files by using shared resources and scripts to reduce DNS lookups
• prudent use of css selectors, eliminating unnecessary reverse DOM node checks
• avoid in-body linking to external style sheets; ensure link placement in document head
• use header styles as substitute for inline style, where applicable
• avoid using the @import css style sheet format from another css file
• optimize the order stylesheets in document sequentially in relation to associated scripts
• limit number of style sheets to one per html document where possible
• necessary scripting in header follows after both css & js links
• avoid use of inefficient document.write script
• use ajax to facilitate asynchronous resource fetching
• upgrade google analytics scripts to most recent version, which is asynchronous
• arrange parallel downloading of resources by locating on more than one hostname ¹
• specify correct document content type & character code at top of header, sequentially ²
• measures to reduce the need for multiple or excessive DNS lookups
• reduce or eliminate file redirects from url to url ³
• eliminate "bad" server requests; frequent site wide internal & external dead link checks
• leverage browser and proxy caching for minimal number and length of RTT
• evaluate use of header http & cache expiration directives; adjust for optimal performance ⁴
• avoid cookie usage; substitute html5 storage features where applicable ⁵
• restrict URL lengths to a maximum of 200 bytes for host | get processes
• minimize payload size: an SEO latency penalty applies if crossing IP packet boundary limits
• remove unnecessary markup and style comments from html and css
• use of relative file paths vs. absolute urls for most internal links

1. Useful for pages that render more resources than concurrent connections allowed by host for specific domain. Spreading demand across hostnames reduces the RTT incidents. Where # equal number of resources queued for download, and MAX equals maximum number of concurrent connections allowed by one hostname for domain requesting the resources. If hostname allows for 5 concurrent connections for domain.com, and the page requires 20 resources, the browser will need to make 4 Round Trips. If resources are split between two hostnames, each with a 5 connection limit, the download clusters of 5 resources ea. can run parallel, thus cutting download time in half. Ideally, 2 to 4 hosts is the range for "tricking" browsers into parallel downloads of resources. More than 5 host connections, when coupled with necessary DNS lookups, can degrade optimization. There's a bell curve to aim for. If page calls for more than 10 resources from a single host, spreading requests to other hostnames will optimize performance. If less than 10 elements per page, overkill and unnecessary.

2.Identify appropriate character code [i.e. utf8] at the top, or earliest point, in document head. [browsers are programmed to search for character types within document's first 1024 bytes. When not found, latency is caused]

3.If redirects are essential/unavoidable, use the server side 301 and 302 mod rewrite method over the less desirable header meta tag redirect. I.e. [http-equiv="refresh" attribute in the meta tag or set the JavaScript window.location} object (with or without the replace() method) in the head of the HTML document. The latter is the inferior client side method. redirects slow down your website, avoid whenever possible.

4.Add an Expires or a Cache-Control Header tag: server There are two aspects to this rule: For static components: implement "Never expire" policy by setting far future Expires header For dynamic components: use an appropriate Cache-Control header to help the browser with conditional requests. Expires headers are most often used with images, but they should be used on all components including scripts, stylesheets, and Flash components.

5.Restrict cookie use and size to an absolute minimum. Google advises an average cookie size of no more than 400 bytes. G also warns against use of any cookie 1000 bytes or larger. Cookie use limited to server-side for both session and persist. Possible by specifying an expiration date and time w/cookie. Minimize size by applying only 1 unique ID to cookie, then associating the ID to remaining cookie info situated on server for efficiency and performance. Cookies not in use throughout, filter out; use same cookie across paths for identical function, but restrict cookie inclusion only where needed and in use. If cookie is used only in a subfolder's html file, do not store at top level domain directory. Localize and isolate for its solitary use. Don't duplicate cookies, share one for multiple requests/files.

• end-user's bandwidth speed
• Internet service provider,
• router, modem, and wi-fi components [except mobile, which can implement a detection switch]
• geographic, physical proximity, or distance, to peering exchange points
• computer hardware
• graphic acceleration devices or omission
• choice of browser
• security applications and proxies
• user style sheets
• plug ins
• javascript & java disablement
• compatibility aspects
• modern capabilities and support for emerging technology
• language preferences

• avoid multiple entries for descendant selectors
• combine rules to avoid multiple style declarations for shared style, [i.e, p, h2, h3 {color:black;}]
• avoid using universal key tags [*] as selector objects, i.e. *{color:red;}
• eliminate rule & style redundancy, i.e. [ul li] vs. [body ul li], as body parent is implied automatically
• avoid using major document parts selector parents of descendant selectors & rules
• avoid declaring rules that use universal attributes, such as *{color:blue}
• avoid child and descendant selectors that implement a ">", i.e.: body > * {color:pink;}

• arrange order of images on sprite w/ png & gif's first, always smallest to largest
• sprite groups of small graphics together
• limit area, or size, of sprite to smallest size necessary [cut off any unfilled/unused space on sprite]
• use sprites for groups of images or icons used repeatedly / template staples
• combine images within the same 256 color palette on same sprite
• avoid spriting dynamic images, graphics only used once, or for frequently changing pics

• Browser Scope: Web Development resource for current Browser features, Tools, Etc.
• Smush.it: Online Image Compression Tool by Yahoo Developer Network
• Closure Compiler by Google AppSpot: Multiple options and help info for file compression
• Google's List of Site Speed & Performance Tools: Comprehensive Resource List

ySlow
ySlow Download Page ydn
also available as a firefox add-on [requires firebug ]

PageSpeed
PageSpeed Download Page
also available as addon for chrome and firefox browsers

• RTT: Round Trip Time [time to travel by the browser to and from the server 1x]
• Friendly iFrame: an iFrame resource that resides on same domain as parent page
• CDN: Content Delivery Network
• CPM: Critical Path Method in Relation to the file url path location on directory
• DNS: Domain Name System, hierarchical naming system based on numbers

Great aesthetics, well written content, captivating presentation...if it doesn't hustle, it won't be seen. Big, fat, resource hogging webpages cause more abandoned visits and lost sales than fast sites that are butt ugly.

Websites built entirely in Flash are frequently ditched. Up to 80% of the wasted performance time can be recovered by integrating techniques similar to methods listed listed in above sections.

Bottom line, it's no different than a direct sales method. Both are number games, whether channeled online or in person, and little product is moved to market unless actual sales contacts and presentations are made. Imagine employing a sales person who no showed for every appointment. Same thing...websites no show when would be site visitors lose patience. One click is all it takes...one second a difference a makes.

Not only do web users have incredibly short attention spans, slow loading sites arouse suspicion of malware, phishing, popups, browser hijacking, sneaky redirects, and fairly bad practices, in general.

Abandoned visits cause more havoc and disadvantages, as Google gauges end user behavior cumulatively as either votes in favor, or votes against website quality, if they hit the road...Jack.