Code Splitting Tag

Optimize the performance of your frontend application using Vue JS

Performance optimization of frontend applications plays an important role in the application architecture. A higher-performing application will ensure an increase in user retention, improved user experience, and higher conversion rates.

According to Google, 53% of mobile phone users leave the site if it takes more than 3 seconds to load. At the same time, more than half of the pages tested are heavy in terms of bandwidth it utilizes to download the required assets. Don’t forget your frontend application performance directly affects its search ranking and conversion rates.

We use the Vue JS framework for our frontend applications. The challenge we had with our frontend application was with the landing page, which was taking around 3.8 secs to load with 4.2 MB of resources to be downloaded. As the response time was quite high, it was challenging to retain the users.

This article would share some of the implementation changes which we did to improve the performance of our frontend application.

Image Compression

Image compression is really important when optimizing frontend applications. Lighter images get downloaded faster and load with less time as compared to larger images. By compressing the images, we can make our site much lighter and hence results in slower page load times.

WebP is a modern image format that provides superior lossless and lossy compression for images on the web. Using WebP, webmasters and web developers can create smaller, richer images that make the web faster.

WebP lossless images are 26% smaller in size compared to PNGs. WebP lossy images are 25–34% smaller than comparable JPEG images at equivalent SSIM quality index.

WebP is supported by Chrome, Firefox, Edge, and Safari from version 14 and above. Please feel free to read more about WebP.

Pic courtesy: medium.com

It is evident that download time has reduced on applying webp compression.

Synchronous Components Loading

Synchronous components loading is the process of loading the components with the import statement which is the basic way of loading the component.

Components loaded with a static import statement will be added to the existing application bundle. If code splitting is not used then the application core will become huge in size, hence affects the overall performance of the application.

The below code snippet is an example of static component loading of store and locale components.

import store from '@common/src/store'
import locale from '@common/src/util/locale'

Asynchronous Components Loading

Asynchronous components loading is the process where we load chunks of our application in a lazy manner. It ensures that components are only loaded when they are needed.

Lazy loading ensures that the bundle is split and serves only the needed parts so users are not waiting to download and parse the code that will not be used.

In the below code snippet, the image of YouTube is loaded asynchronously when it’s needed.

<template>
  <lazy-image
    :lazy-src="require('@/assets/images/icon/youtube.png')"
    alt="YouTube" draggable="false" />
</template>
<template>
  <img v-if="lazySrc" ref="lazy"
    :src="defaultImage" :data-src="lazySrc"
    :alt="alt" class="lazyImage"
    @error="handleError">
  <img v-else :src="defaultImage">
</template>

Dynamic Components Loading

To dynamically load a component, we declare a const and append an arrow function followed by the default static import statement.

We can also add a web pack magic comment. The comment will tell webpack to assign our chunk the name we provided otherwise webpack will auto-generate a name by itself.

const MainBanner = () => import(/* webpackChunkName: "c-main-banner" */ '@/components/MainBanner')

If we go to our developer tools and open the Network tab we can see that our chunk has been assigned the name we provided in the webpack’s chunk name comment.

Pic courtesy: medium.com

Code Splitting

According to Dev Mozilla, code splitting is the process of splitting the application code into various bundles or components which can then be loaded on-demand or in parallel.

As an application is used extensively, it will have a lot of changes and new requirements with time it would have increased in terms of complexity, CSS and JavaScripts files or bundles grow in size, and also don’t forget the third-party libraries which we use.

We don’t have much control in terms of third party libraries downloads as they are required for our application to work. At least we should make sure our code is split into multiple smaller files. The features required at page load can be downloaded quickly with smaller files and with additional scripts being lazy-loaded after the page or application is interactive, thus improves the performance.

we have seen some of the frontend developers’ arguments, it will increase the number of files but the code remains the same. We completely agree with them but the main thing over here is the amount of code needed during the initial load can be reduced.

Code splitting is a feature supported by bundlers like Webpack and Browserify which can create multiple bundles that can be dynamically loaded at runtime or we can do the old school way where we can split the code required for individual vue files can be separated and loaded on demand.

Preconnect

Basically, third-party requests can slow down page loads for several reasons like slow networks, long DNS lookups, multiple redirects, slow servers, poor performing CDN, etc.

As third-party resources (e.g., Facebook or Twitter, or MoEngage) do not originate from your domain, their behavior is sometimes difficult to predict and they may negatively affect page experience for your users.

Using preconnect helps the browser prioritize important third-party connections and speeds up your page load as third-party requests may take a long time to process. Establishing early connections to these third-party origins by using a resource hint like preconnect can help reduce the time delay usually associated with these requests.

preconnect is useful when you know the origin of the third-party request but don’t know what the actual resource itself is. It informs your browser that the page intends to connect to another origin and that you would like this process to start as soon as possible. The browser closes any connection that isn’t used within 15 seconds, so preconnect should only be used for the most critical third-party domains.

Unused CSS/JS

As a part of best practices, we need to make sure we don’t have any commented code in JS or CSS files. It’s commented because we don’t want to use them, so better get rid of them as the commented code contributes to an increase in the size of the file.

As part of frontend application development, we might use some CSS frameworks but you will only use a small set of the framework styles, and a lot of unused CSS styles will be included.

According to PurgeCSS, it’s a tool to remove unused CSS. It can be part of your development workflow. PurgeCSS analyzes your content and your CSS files then it matches the selectors used in your files with the ones in your content files. It removes unused selectors from your CSS, resulting in smaller CSS files.

Also while importing anything from 3rd party libraries to run the application, we can use the tree-shaking mechanism that can avoid the unused CSS and JS code included in our 3rd party bundles. To analyze this kind of unwanted JS and CSS items from 3rd party libraries there is a tool called webpack bundle analyzer.

For more information and to develop website using Vue.js, Hire Vue.js Developer from us as we give you a high-quality product by utilizing all the latest tools and advanced technology. E-mail us any clock at – hello@hkinfosoft.com or Skype us: “hkinfosoft”. To develop Website using Vue.js, please visit our technology page.

Content Source:

1. medium.com

3 easy ways to boost up the performance of your web application

When building a web application, there’s something you absolutely need to take account: performance. Your app may be greatly designed or have some killer features, nobody will use it if it’s not performant. Here are some important aspects which will make an app more performant.

Optimize your images

This is the most easiest thing and one of the most common mistakes you can find out there. When integrating images on an app, you’ve been told to use the pictures with the highest resolution to have the best quality images. That’s great. What you haven’t been told is that the images you use from Unsplash or Pexels often have huge dimensions and are not meant to be displayed on smaller screens.

It’s like watching a 10GB 4K movie on an old tiny computer. 4K or not, you won’t see many differences. That’s the same for images on a website. Thus, you must reduce the quality and resize the images in order to make them smaller.

There are plenty of apps that allows you to do so like squoosh.app. For example, you can find below an example of an image whose size was reduced on squoosh:

pic courtesy : medium.com

Sure the image on the right is a little bit blurry and less detailed than the one of the left but at this zoom level, it’s still looking good to me and it’s also 96% smaller which means your browser loads 5.2MB less.

Code Splitting

If you’re building single-page applications (SPA) with client-side rendering (as with create-react-app or Vue CLI for example), this tip will also boost your app with little efforts.

In fact, client-side rendering means you are basically fetching on the server a bare bons HTML document with a JavaScript file (called a bundle) containing your whole application logic. This approach makes your app longer to load initially but more rich in terms of interaction and route changes. It’s a problem since a long initial load will be perceived badly by your users.

In fact, you will ship to the client this big JavaScript file even if your users don’t need to use every features of the application (typically a settings page when you can change your name or modify your password).

To solve this problem, you can use code splitting: “lazy-load” just the things that are currently needed by the user.

One common strategy is to split your code based on your different routes. Let’s take the example of a fake store app:

import { BrowserRouter as Router, Route, Switch } from "react-router-dom"
import React, { Suspense, lazy } from "react"
const Products = lazy(() => import("./Products"))
const Cart = lazy(() => import("./Cart"))
const Settings = lazy(() => import("./Settings"))
const App = () => (
  <Router>
    <Suspense fallback={<div>Loading...</div>}>
      <Switch>
        <Route exact path="/" component={Products} />
        <Route path="/cart" component={Cart} />
        <Route path="/settings" component={Settings} />
      </Switch>
    </Suspense>
  </Router>
)

With that approach, if the users want to browse your products, they won’t need to load the code associated to the Cart or the Settings page.

It can make your initial load way faster by saving hundreds and hundreds of KB, especially if your other pages use heavy third party libraries, which bring us to the third and last point.

Reduce the bundle size

We saw how to reduce the bundle size at the initial load. Here we will see how to reduce it but globally this time.

A great tool to do so is webpack-bundle-analyzer or source-map-explorer for Create React App users. We’ll show you an example with CRA here. There are few steps to follow:

• Install source-map-explorer:

npm install --save source-map-explorer

• Add an analyze script to your package.json file:

{
  "scripts": {
    "analyze": "source-map-explorer 'build/static/js/*.js'"
  }
}

This will run source-map-explorer on the JS files generated by npm run build.

npm run build
npm run analyze

By running the script on one of your projects, you should get something similar to that:

pic courtesy : medium.com

You can see in the results that the bigger a dependency is, the more it takes up place visually. That’s a great way to spot the heaviest dependencies.

We ran source-map-explorer on a small project so you can see the bundle is not that big in our case. You’ll likely get a heavier bundle and more dependencies on bigger projects.

Then, get rid of heavy dependencies

Once you have the results, it’s up to you to see which dependencies are the heaviest and decide if you must find alternatives for them. To find the cost of a package in your bundle, We recommend bundlephobia. It’s great for comparing packages cost and making you wonder if you really need to install that dependency.

For example, we used to use moment.js for date manipulation. But it has a pretty big cost on your package:

pic courtesy : medium.com

In fact, moment is not modular. If you need to manipulate dates, then you need to create a Moment instance that gives you access to a lot of methods even if you use just one or two of them.

Now, We use date-fns which is way more modular and lighter too:

pic courtesy : medium.com

You can follow the same logic for a lot of dependencies. However, be pragmatic when making these choices:

• If you use a package that seems to be both useless and heavy, it may be a good idea to get rid of it.
• If it’s useful and heavy, then you can start searching for lighter alternatives.

these three tips gave you the will to optimize your apps (and create more stellar experiences for your users!). Of course, there are plenty of other performance tips like:

• Avoiding unnecessary re-renders if you use React or Vue or something similar
• Removing unused CSS with purgecss
• Making use of caching
• Using CDNs
• Choosing the right type of databases and optimizing them
• Reducing HTTP requests
• Prefetching assets

We highly encourage you to explore all these options and see what they can bring to you performance-wise. However, don’t be obsessed with that. When it comes to building apps, there are always trade-offs.

For more information and to develop web application using Front-End technology, Hire Front-End Developer from us as we give you a high-quality product by utilizing all the latest tools and advanced technology. E-mail us any clock at – hello@hkinfosoft.com or Skype us: “hkinfosoft”. To develop any custom web apps using Js, please visit our technology page.

Content Source:

1. medium.com