MatrixAdapt | Logiciel de gestion d'Entreprise, Création et référencement des sites web

Seo Master present to you: On April 7th, Google launched a new version of Gmail for mobile for iPhone and Android-powered devices. We shared the behind-the-scenes story through this blog and decided to share more of what we've learned in a brief series of follow-up blog posts. This week, I'll talk about how modularization can be used to greatly reduce the startup latency of a web app.

To a user, the startup latency of an HTML 5 based application is critical. It is their first impression of the application's performance. If it's really slow, they might not even bother to wait for the app to load before navigating away. Even if your application is blazing fast after it loads, the user may never get the chance to experience it.

There are several aspects of an HTML 5 based application that contribute to startup latency:

1. Network time to fetch the application (JavaScript + HTML)
2. JavaScript parse time
3. Code execution time to fetch the data and render the home page of your application

The third issue is up to you! The first two issues, however, are directly correlated with the size of the application. This is a tricky problem since as your application matures, it will have more features and the code size will get bigger. So, what to do? Modularize your application! Split up your code into independent, standalone modules. Consider splitting each view/screen of your application and implement each new feature as its own module. This is only half the story. Now that you have your code modularized, you need to decide which subset of these modules are critical to load your application's home page. All the non-core modules should be downloaded and parsed at a later time. With a consistent code size for your startup code, you can maintain a consistent startup time. Now, let's go into some nitty gritty details of how we built an application with lazy-loaded modules.

How to Split Your Code into Modules

Splitting an application into individual modules might not be as simple as you think. Code that serves a common purpose/functionality should be grouped together and form a module (comparable to a library). As mentioned earlier, we selected which modules are critical to the home page of the app and which modules can be lazy-loaded at a later time. Let's use a Weather application as an example:

High Level Functionality:

• A "Weather in my Favourite Cities" home page
• Click on a city to view the cities entire week forecast
• Weather data comes from an external web service

Possible Module Separation:

• Weather data model
• Weather web service API
• Common UI widgets (buttons, toolbars, navigation, etc)
• Favourite Cities page
• City Weather Forecast page

Now let's say your users want a "breaking news" feature. No problem: just put the page, the news data API and the data model into a new module.

One thing to keep in mind is the dependency order of your modules. For modules that have many downstream dependencies, it might make sense to include them as part of the core modules.

How to Lazy Load the Modules

Option 1: Script as DOM

This method uses JavaScript to insert SCRIPT tags into the HEAD's DOM.

<script type="text/JavaScript">
  function loadFile(url) {
    var script = document.createElement('SCRIPT');
    script.src = url;
    document.getElementsByTagName('HEAD')[0].appendChild(script);
  }
</script>

Option 2: XmlHttpRequest (XHR)

This method sets up XmlHttpRequests to retrieve the JavaScript . The returned string should be evaluated in the XHR callbacks (using the eval(string) method). This method is a little more complicated but it gives you more control over error handling.

<script type="text/JavaScript">
  function loadFile(url) {
     function callback() {
      if (req.readyState == 4) { // 4 = Loaded
        if (req.status == 200) {
          eval(req.responseText);
        } else {
          // Error
        }
      }
    };
    var req = new XMLHttpRequest();
    req.onreadystatechange = callback;
    req.open("GET", url, true);
    req.send("");
  }
</script>

The next question is, when to lazy load the modules? One strategy is to lazy load the modules in the background once the home page has been loaded. This approach has some drawbacks. First, JavaScript execution in the browser is single threaded. So while you are loading the modules in the background, the rest of your app becomes non-responsive to user actions while the modules load. Second, it's very difficult to decide when, and in what order, to load the modules. What if a user tries to access a feature/page you have yet to lazy load in the background? A better strategy is to associate the loading of a module with a user's action. Typically, user actions are associated with an invocation of an asynchronous function (for example, an onclick handler). This is the perfect time for you to lazy load the module since the code will have to be fetched over the network. If mobile networks are slow, you can adopt a strategy where you prefetch the code of the modules in advance and keep them stored in the javascript heap. Only then parse and load the corresponding module on user action. One word of caution is that you should make sure your prefetching strategy doesn't impact the user's experience - for example, don't prefetch all the modules while you are fetching user data. Remember, dividing up the latency has far better for users than bunching it all together during startup.

For an HTML 5 application that takes advantage of the application cache to reduce startup latency and to serve the application offline, there are a few caveats one should be aware of. Mobile networks have decent bandwidth, but poor round trip latency, so listing each module as a separate resource in the manifest incurs quite a bit of extra startup latency when the application cache is empty. Also, if one of the module resources fails to be downloaded by the application cache (e.g. disconnected from network), additional error handling code needs to be written to handle such a case. Finally, applications today have no control when the application cache decides to download the resources in the manifest (such a feature is not defined in the current specification of the draft standard). Typically, resources are downloaded once the main page is loaded, but that's not an ideal time since that's when the application requests user data.

To work-around these caveats, we found a trick that allows you to bundle all of your modules into a single resource without having to parse any of the JavaScript. Of course, with this strategy, there is greater latency with the initial download of the single resource (since it has all your JavaScript modules), but once the resource is stored in the browser's application cache, this issue becomes much less of a factor.

To combine all modules into a single resource, we wrote each module into a separate script tag and hid the code inside a comment block (/* */). When the resource first loads, none of the code is parsed since it is commented out. To load a module, find the DOM element for the corresponding script tag, strip out the comment block, and eval() the code. If the web app supports XHTML, this trick is even more elegant as the modules can be hidden inside a CDATA tag instead of a script tag. An added bonus is the ability to lazy load your modules synchronously since there's no longer a need to fetch the modules asynchronously over the network.

On an iPhone 2.2 device, 200k of JavaScript held within a block comment adds 240ms during page load, whereas 200k of JavaScript that is parsed during page load added 2600 ms. That's more than a 10x reduction in startup latency by eliminating 200k of unneeded JavaScript during page load! Take a look at the code sample below to see how this is done.

<html>
...
<script id="lazy">
// Make sure you strip out (or replace) comment blocks in your JavaScript first.
/*
JavaScript of lazy module
*/
</script>

<script>
  function lazyLoad() {
    var lazyElement = document.getElementById('lazy');
    var lazyElementBody = lazyElement.innerHTML;
    var jsCode = stripOutCommentBlock(lazyElementBody);
    eval(jsCode);
  }
</script>

<div onclick=lazyLoad()> Lazy Load </div>
</html>

In the future, we hope that the HTML5 standard will allow more control over when the application cache should download resources in the manifest, since using comments to pass along code is not elegant but worked nicely for us. In addition, the snippets of code are not meant to be a reference implementation and one should consider many additional optimizations such as stripping white space and compiling the JavaScript to make its parsing and execution faster. To learn more about web performance, get tips and tricks to improve the speed of your web applications and to download tools, please visit http://code.google.com/speed.

Previous posts from Gmail for Mobile HTML5 Series

HTML5 and Webkit pave the way for mobile web applications
Using AppCache to launch offline - Part 1
Using AppCache to launch offline - Part 2
Using AppCache to launch offline - Part 3
A Common API for Web Storage
Suggestions for better performance
Cache pattern for offline HTML5 web application

By Bikin Chiu, Software Engineer, Google Mobile2013, By: Seo Master

Seo Master present to you: From building data centers in different parts of the world to designing highly efficient user interfaces, we at Google always strive to make our services faster. We focus on speed as a key requirement in product and infrastructure development, because our research indicates that people prefer faster, more responsive apps. Over the years, through continuous experimentation, we've identified some performance best practices that we'd like to share with the web community on code.google.com/speed, a new site for web developers, with tutorials, tips and performance tools.

We are excited to discuss what we've learned about web performance with the Internet community. However, to optimize the speed of web applications and make browsing the web as fast as turning the pages of a magazine, we need to work together as a community, to tackle some larger challenges that keep the web slow and prevent it from delivering its full potential:

• Many protocols that power the Internet and the web were developed when broadband and rich interactive web apps were in their infancy. Networks have become much faster in the past 20 years, and by collaborating to update protocols such as HTML and TCP/IP we can create a better web experience for everyone. A great example of the community working together is HTML5. With HTML5 features such as AppCache, developers are now able to write JavaScript-heavy web apps that run instantly and work and feel like desktop applications.


• In the last decade, we have seen close to a 100x improvement in JavaScript speed. Browser developers and the communities around them need to maintain this recent focus on performance improvement in order for the browser to become the platform of choice for more feature-rich and computationally-complex applications.


• Many websites can become faster with little effort, and collective attention to performance can speed up the entire web. Tools such as Yahoo!'s YSlow and our own recently launched Page Speed help web developers create faster, more responsive web apps. As a community, we need to invest further in developing a new generation of tools for performance measurement, diagnostics, and optimization that work at the click of a button.


• While there are now more than 400 million broadband subscribers worldwide, broadband penetration is still relatively low in many areas of the world. Steps have been taken to bring the benefits of broadband to more people, such as the FCC's decision to open up the white spaces spectrum, for which the Internet community, including Google, was a strong champion. Bringing the benefits of cheap reliable broadband access around the world should be one of the primary goals of our industry.

To find out what Googlers think about making the web faster, see the video below. If you have ideas on how to speed up the web, please share them with the rest of the community. Let's all work together to make the web faster!



Posted by Urs Hoelzle, SVP, Operations and Bill Coughran, SVP, Engineering

(Cross-posted on the Official Google Blog, and the Google Webmaster Central Blog)2013, By: Seo Master

Seo Master present to you: 2013, By: Seo Master

Seo Master present to you: At Google, we focus constantly on speed; we believe that making our websites load and display faster improves the user's experience and helps them become more productive. Today, we want to share with the web community some of the best practices we've used and developed over the years, by open-sourcing Page Speed.

Page Speed is a tool we've been using internally to improve the performance of our web pages -- it's a Firefox Add-on integrated with Firebug. When you run Page Speed, you get immediate suggestions on how you can change your web pages to improve their speed. For example, Page Speed automatically optimizes images for you, giving you a compressed image that you can use immediately on your web site. It also identifies issues such as JavaScript and CSS loaded by your page that wasn't actually used to display the page, which can help reduce time your users spend waiting for the page to download and display.

Page Speed's suggestions are based on a set of commonly accepted best practices that we and other websites implement. To help you understand the suggestions and rules, we have created detailed documentation to describe the rationale behind each of the rules. We look forward to your feedback on the Webmaster Help Forum.

We hope you give Page Speed a try.

By Richard Rabbat and Bryan McQuade, Page Speed Team2013, By: Seo Master

Seo Master present to you: The sixth Web E^xponents tech talk features Rob Campbell's presentation on Firebug. Rob works at Mozilla. He's one of the developers that Mozilla dedicated to the Firebug effort last July. Rob is one of the main drivers of the Firebug project, starting and heading up the weekly concalls, and closely tracking bugs and releases. As one of the founders of the Firebug Working Group, I'm excited to see Mozilla taking a more active role in Firebug. The benefits are clear as we see more features and greater stability with each Firebug release. Here's the video of Rob's presentation as well as a link to his slides.



Rob starts by highlighting what's new in Firebug 1.4 alpha. It's a joy for me to see that activation (enabling and disabling) has been simplified. Rob points out that the firebug icon serves also as a menu. One of the menu items is "Open With Editor", which developers will find useful for saving changes to their pages. A much needed UI change is flipping the tabs and buttons. The tabs used to be below the buttons. Putting them at the top is closer to what users expect from working with other tabbed UIs.

The new "pause" button will be useful for anyone debugging JavaScript. This implements "break on next" functionality, making it easier to stop when event handlers are called. Firebug's Net Panel has had significant improvements. The UI is better (colors!), but there's even more. The underlying timing information has been improved to give more accurate results. There are also markers for DOMContentLoaded and OnLoad, to show where those fire in relation to network requests.

Firebug Extensions provide a way for developers to add functionality that can be shared with others. Rob mentions several extensions including:

• Firediff - tracker for changes made to DOM and CSS
• FireCookie - cookie manager
• FirePHP - console logging from PHP
• YSlow - performance tips
• FireRainbow - JavaScript syntax highlighting

Writing an extension is a great way to explore future directions for Firebug.

Rob talks about future roadmap. Firebug 1.5 will focus on extensions - making them easier to build and use. Firebug 1.6 will change the underlying JavaScript debugging mechanism in Firefox to support new features. Add Rob's blog to your RSS reader to find out about these future releases and other improvements to Firebug.

By Steve Souders, Performance Evangelist2013, By: Seo Master

Seo Master present to you: Over the last few months, I've started inviting web gurus I know to give tech talks at Google. It's been great to kick off this speaker series with such luminaries as John Resig, Doug Crockford, and PPK. (I snuck in there, too.) The biggest benefit from these talks is the release of the videos and slides. The videos are popular, with thousands of viewers. The videos make it possible to share these insights with a wider audience who might not be at the next tech conference or workshop.

For various reasons (t-shirts, YouTube playlist), it's beneficial to give this speaker series a name. I've decided to call it Web E^xponents. I use "exponents" in the sense of "a person who actively supports or favors a cause". The cause, in this case, is evangelizing innovation and best practices in web development. And now, thanks to fellow Googler Mark Chow, we have the Web Exponents playlist on YouTube. You can find all the past and future videos there.

Web E^xponents speakers coming up next include Rob Campbell (Firebug) and Nicholas Zakas (Yahoo! JavaScript expert). I'll write a blog post for these and other future talks, and you can subscribe to the playlist to make sure you catch all the videos.

And now for the mandatory cheesy tagline: Web E^xponents - raising web technology to a higher power.

By Steve Souders, Performance Evangelist2013, By: Seo Master

Seo Master present to you: By Dion Almaer, Google Developer Programs

Steve Souders, member of the performance group at Google, has released a new open source tool called Cuzillion. Steve was constantly creating sample test web pages that he used to test out theories on Web site performance. He realized that he was repeating a lot of the same steps, so why not create a tool that would enable him to build the samples quickly. Thus, Cuzillion was born.



If you take a look at the UI above, you will see that it is mimicking a Web page, with a <HEAD> and <BODY>. On the left hand side you select types of elements; such as images, scripts, CSS, and other resources. You add these elements to the mini page on the right, and then you can select that element to set more properties on it. For example, you can quickly set the domain that it is running on, which allows you to test splitting our content on domains.

We sat down with Steve and produced the video below in two parts. It starts off with him discussing the project, and then delves into a screencast of the product itself. He gives us an introduction, and then shows how he used it to solve an issue with Orkut.

2013, By: Seo Master