In first part we defined that what is situational performance optimization and taking that further we will evaluate the traits of the situational performance optimization.
Sometimes web developers can’t be enumerating by every possible variable but we can try to identify the primary ones. To get us started down this path below is a list of common traits that can truly affect performance. I tried to give an example for each of those of what Situational Performance Optimization could mean for it.
The most important thing to remember is that no all the sites are same. Some of the sites are visually light, while some are extremely complicate. Some websites regularly keeps on updating and changing while some are just static. Some of the sites out there have independent pages, while the rest of the other just use self-modifying page.
Every 6 weeks Firefox & Chrome ship new versions while some old browsers retain for somewhat long. Let’s take a very common example; most still support IE 7 while some sites deprecated IE 6 support and the 6-years-old IE 8 still accounts for over 15% of web traffic. Mainly the older versions of the browsers lame web developers’ ability to use data URIs, CSS media queries and the like, resulting in less optimized pages for all clients. It has been seen that some browsers introduce new capabilities and that we want to tap into. With recent examples in case of Chrome such as pre-render and WebP image format, what it is good if all rest of the browsers follow these trends!
It’s an undeniable fact that is never going away is that some networks are awesome, and others make web developers want to pull your hairs out. Treating a new Google Fiber link same as a poor reception cellular connection or a congested Starbucks Wi-Fi network makes no sense. Reduce image quality when the latency of the connection is bad. High quality images improve the user experience. Sometimes under certain conditions even your designers would agree they hurt more that it can be bearable.
Today most of the web developers are optimizing for a clean cache scenario. For the vast majority of measurement tools today cache is the default option – and sometime you have only one as simulating a “correct” cache state is really very tough. There’s little advice around how to optimize your cache, particularly when cache is not scriptable and this is become awkward when you are using your cached performance. I believe there’s a lot that can be done if we put our minds to it while browser cache is not scriptable. At the least move all uncacheable at the bottom of the page or make them sync.
Since 2003 we've been dedicated to creating website for businesses small and large, that are beautiful to look at, and help turn visitors into customers.