Chrome Developer Tools are tools that comes with Google Chrome Browser that allows web developers and programmers deep access into the internals of the browser and their web application.
In this post I will only write about using Chrome Dev Tools for detecting performance problems, auditing problems (Chrome also suggests you how to fix them), and a possible implementation for fixing them.
For this purpose I have developed a web application with Spring Roo. It is defined by a simple Entity called Person that has only two attributes, name and age. Spring Roo is a next-generation rapid application development tool for Java developers. With Roo you can easily build full Java applications in minutes. In this case will create a website with CRUD operations for Person entity.
// Spring Roo 1.1.0.RELEASE [rev 793f2b0]project --topLevelPackage org.chrome.devtools.example --projectName ChromeDevTools --java 6persistence setup --database HYPERSONIC_IN_MEMORY --provider HIBERNATEentity --class ~.domain.Personfield string --fieldName name --notNullfield number --fieldName age --type java.lang.Integercontroller scaffold ~.web.PersonControllersecurity setupweb flowjson all
The action is starting right now:
For accessing to Developer Tools, you should open Google Chrome Browser, and then go to Tool Icon -> Tools -> Developer Tools or Ctrl+Shift+I.
When you access to Developer Tools an split menu appears, with eight options:
- Elements: In this tab you can inspect HTML code and CSS code. When you select an element, this element is highlighted in the browser, and its CSS properties are shown. These CSS properties can be modified on-the-fly and see immediately how change is affected.
- Resources: In this tab, you can watch, which resources are loaded, and internal resources like cookies, sessions, HTML5 local databases, application cache, ...
- Network: In this tab, you see for each resource how much time is took between is requested and is sent. Each request is summarized in a time-line graph, and ordering by time you can see which resources are slowest to be received.
- Script: This tab shows you scripts executed in current page. Also acts as a debugger, you can set breakpoints, and debug your Javascript code as Eclipse does with Java.
- Timeline: Is the next tab that is really interesting to making a performance diagnostic. Time-line tab is more or less like Network tab, but instead of showing networking time, it shows time spent by browser like sending requests, evaluating scripts, painting components, ... Also has a sub-tab for watching memory consumption.
- Profile: This tab is a typical profiler but for browsers.
- Audit: And finally the last tab. This tab audits current page finding points of improvement. For example in "Show Person" page, Chrome has found:
- Enable Gzip compression: browser has the feature of decompressing data encoded with gzip. If you are using Rest application with Spring check out this blog: http://www.oudmaijer.com/2011/02/23/spring-resttemplate-and-gzip-compression-continued/ if not, and you are using Spring MVC you can try implementing a HandlerInterceptor. The most global solution is showed in http://tim.oreilly.com/pub/a/onjava/2003/11/19/filters.html where a Filter is used for compressing output. In summary what all solutions do is checking if request header (generated by browser) supports gzip Accept-Encoding: gzip, deflate and if it is the case compress response stream and modifies response header to notify to web client that content is encoded in gzip Content-Encoding: gzip.
- Leverage browse caching: static resources should be interesting to be cached by the browser, so only first time that are requested are sent. In Spring 3 there is a <mvc:resources> that works perfect for this porpoise. http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/mvc.html#mvc-static-resources or using an interceptor:
<mvc:interceptors><mvc:interceptor><mapping path="/static/*"/><bean id="webContentInterceptor"class="org.springframework.web.servlet.mvc.WebContentInterceptor"><property name="cacheSeconds" value="31556926"/><property name="useExpiresHeader" value="true"/><property name="useCacheControlHeader" value="true"/><property name="useCacheControlNoStore" value="true"/></bean></mvc:interceptor></mvc:interceptors>
For a more generic way see how ETag header works http://blog.bcarlso.net/2007/10/19/tomcat-weak-etags-and-javascript-css-caching. - Optimize the order of styles and scripts: always define first external CSS and then external Javascript files, this ensures a better downloading performance. Also defining CSS into HEAD section makes page to be rendered progressively. In this case there is no server side effects, you should only keep in mind that rule when you define these kind of static resources.
If you have any performance problem in your web application, thanks of Google Chrome you can make an initial diagnostic and see where time is lost (client or server side). Also you can take a look of what Google Chrome Audit suggests you for making your application loading faster.
0 comentarios:
Publicar un comentario