34 Matching Annotations
  1. Mar 2021
  2. Feb 2021
    1. The alternative was to have multiple scripts or stylesheet links on one page, which would trigger multiple HTTP requests. Multiple requests mean multiple connection handshakes for each link “hey, I want some data”, “okay, I have the data”, “alright I heard that you have the data, give it to me” (SYN, ACK, SYNACK). Even once the connection is created there is a feature of TCP called TCP slow start that will throttle the speed of the data being sent at the beginning of a request to a slower speed than the end of the request. All of this means transferring one large request is faster than transferring the same data split up into several smaller requests.
  3. Dec 2020
    1. Because Jamstack projects don’t rely on server-side code, they can be distributed instead of living on a single server. Serving directly from a CDN unlocks speeds and performance that can’t be beat. The more of your app you can push to the edge, the better the user experience.
    1. Better PerformanceWhy wait for pages to build on the fly when you can generate them at deploy time? When it comes to minimizing the time to first byte, nothing beats pre-built files served over a CDN.
  4. Dec 2019
    1. when it comes to your web browsing experience, it turns out that latency, not bandwidth, is likely the constraining factor today.
    2. Figure 1-1. In this data from StatCounter Global Stats, we can see that the total percentage of Internet traffic coming from mobile devices is steadily increasing.
    3. 75% of online shoppers who experience an issue such as a site freezing, crashing, taking too long to load, or having a convoluted checkout process will not buy from that site. Gomez studied online shopper behavior and found that 88% of online consumers are less likely to return to a site after a bad experience. The same study found that “at peak traffic times, more than 75% of online consumers left for a competitor’s site rather than suffer delays.”
    4. users expect pages to load in two seconds, and after three seconds, up to 40% of users will abandon your site. Moreover, 85% of mobile users expect sites to load at least as fast or faster than sites on their desktop.
    5. components of its user experience: layout, hierarchy, intuitiveness, ease of use, and more.
  5. Oct 2019
  6. Sep 2019
  7. Aug 2019
    1. Centric web solution is the renowned best web development company.

      We have a very highly experienced and expert development team who are experts in web design & development.

      We provide various services like Wordpress web development, eCommerce web development, Wordpress theme design and plugin development, website maintenance & optimization.

      For more our services call us on +91 98587 58541 or visit our website https://www.centricwebsolution.com/.

      Our Services Are:-

      • Web Design & Development
      • WordPress Development
      • WooCommerce Development
      • Custom Web Application Development
      • Website Migration Services
      • Website Maintenance & Performance optimization
      • Website Plugin and API Development
      • Website Store Optimization
      • PHP Web Development
      • Enterprise Web Application Development
      • Laravel Development Services
      • Angularjs Development Services

  8. Jun 2019
    1. This is especially true for online gaming

      WASM is being used to run many demanding applications directly in the browser. Autocad is one important example where architects can use this application without installing a usually very heavy piece of software on their computers. They can access the Autocad suite from almost any computer only by logging into to a website. It is expected that a large part of the gaming industry will shift this way as well as many other services. One of the main advantages of this approach aside from a lack of a local installation is real-time software updates for any number of users. A new model of software building and execution will be based on WASM. WASM is also very good for blockchains. Search for the WASM section to learn more.

  9. Sep 2017
  10. Dec 2016
  11. Apr 2016
  12. Feb 2016
    1. This is a good short overview of how change detection works in Angular 2.

      It fixes the fundamental algorithmic complexity problem that change detection has in Angular 1.x by making it possible to prune parts of the component tree from change detection if the inputs have not changed.

      Unfortunately the zone.js implementation involves some horrifying monkey-patching of various DOM APIs.

  13. Dec 2015
  14. Nov 2015
    1. Join Darin Fisher, VP of Chrome as he talks the past, present and future of the web.

      RAIL - Reaction (<100ms), Animation (<16ms), Idle (<50ms), Load (<1000ms)

  15. Oct 2015
    1. It’s known that Angular becomes slower with around 2,000 bindings due to the process behind dirty-checking. The less we can add to this limit the better, as bindings can add up without us really noticing it!

      From some preliminary testing it looks like we get close to hitting the 2000 watch count on the /stream view - which explains the lag.

    1. Here are a few handy tips on measuring your project’s performance profile:

      In particular, see this section on recommendations for setting up tests that reasonably simulate "real world" conditions.

    2. Web performance article from a couple of the Chrome team developers / (developer advocates). Mentioned on Twitter - https://twitter.com/aerotwist/status/649877465079390209

  16. Sep 2015
    1. Some interesting slides on CSS styling performance on GitHub, particularly focusing on their diff pages.

      Several slides have direct references to WebKit internals explaining the impact on rule resolution performance.

      Mentions a useful tool for understanding CSS selector performance implications, css explain

    1. If your timeline graph is dominated with the color green after recording

      Green is used to denote time spent painting

    2. there does not seem to be a general rule for how many workers to spawn. Some developers claim that 8 is a good number, but use an online calculator and suit yourself

      Web workers are very heavy objects as they include an entire JS VM instance. 8 sounds like a lot.

    1. The $digest loop keeps iterating until the model stabilizes

      cf. React where an event triggers an event handler, which can trigger state changes and calls to React.render(). These are then batched together resulting in a single re-render, a DOM-diff and the application of the result to the DOM. Consequently you can't have an infinite state update loop. The exception is if a state change happens asynchronously, and that state change triggers another async state change (and so on...)

    1. The value function should return the value which is being watched. AngularJS can then check the value returned against the value the watch function returned the last time

      Ah, so since the input is a scope, this means that Angular needs to call every watch value fn that might be affected by a change. Should look into whether it has any optimizations to avoid that for common watch expressions.

    1. Both accessibility and performance are invisible aspects of an experience and should be considered even if they aren’t explicit goals of the project.
    1. So instead we introduced the loading spinner on each widget. Nothing is actually any faster, but the whole experience feels more responsive
    2. Simply reducing some CSS transition times from 500ms to 250ms, and cutting others out entirely, made the whole dashboard feel snappier and more responsive.
    3. This means content is served from the nearest possible geographic location to the user, cutting down request latency from as high as 2500ms (in places such as Singapore) to tens of milliseconds
    4. We eventually came up with a compromise solution based on Addy Osmani’s basket.js, using a combination of server-side script concatenation and localStorage for caching. In a nutshell, the page includes a lightweight loader script, which figures out which JS and CSS it has already cached and which needs to be fetched. The loader then requests all the resources it needs from the server in one request, and saves all the resources into localStorage under individual keys. This gives us a great compromise between cutting down the number of HTTP requests while still being able to maintain cacheability, and not re-downloading code unnecessarily when it hasn’t changed. Addtionally, after running a few benchmarks, we found that localStorage is (sometimes) actually faster than the native HTTP cache, especially on mobile browsers.