About two years ago, Wingify had introduced the new generation of our Visual Website Optimizer to the world. Boasting a modern visual interface, it also had many new features. We’ve come a long way since then. We’ve added even more features to it while improving the previous ones. But with continuous development, it becomes imperative to keep the app lean and fast as well. New features, unless proactively attended to, usually make apps slower. This effect is especially prominent in SPAs(Single Page Applications) which have to be downloaded first on the browser before they can execute. Thus, performance management is an iterative and continuous process. This post is largely a collection of our learnings and implementations done on/to our app to keep it lean and slick.

There are several types of performances when it comes to modern web applications. This blog post chiefly deals with our efforts in improving the app load time. This was also the first phase of the plan since the first things users notice is how soon can they start using the app.

Performance Monitoring Tools

To measure performance, we’ve installed monitoring tools which help us visualize the improvement or deterioration of the app with every release made to production. The chief ones among them are:

  1. Speedcurve — Speedcurve generates a detailed report of the key metrics required to measure network performance. Speedcurve ensures that the each release is monitored. It has a detailed dashboard which shows the health of the app over a period of time. If there’s any negative impact in performance it sends a mail with details of the key performance parameters (like the content size of the page, content requests made by the page, page load time, rendering time etc.).

  2. Web Page Test Charts API — We’ve also installed a custom flavour of Trulia’s open source Webpage Test Charts API . Since both Speedcurve and Web Page Test Charts API essentially get the test results from webpagetest.org the benchmarking source is same. Web Page Test Charts API allows us to view other parameters which Speedcurve doesn’t show.

Performance Improvement Measures

Apart from the tools placed to measure performance, we’d also been busy shipping the following boosts to the app: 

  1. Upgrade to AngularJS 1.5 — While making the VWO App, two years back, the most stable version of AngularJS present was 1.2. Since then several versions have released with the latest one being 1.5. The features and performance benefits of 1.5 over 1.2 were convincing enough to make the move. But there were plenty of breaking changes which kept the Dev team as well as the QA team busy for quite some time in making sure that the upgraded code was bug free and the customers had a seamless transition. I’m glad to share that we’ve finally made the transition.

  2. Move to HTTP/2 Protocol — HTTP/2 protocol, the successor of the HTTP 1.1 protocol and based loosely on the SPDY protocol provides several benefits. It enables multiplexing of resources across single TCP connection, compressing and reducing HTTP headers and also supports Server Push (The server can optimistically push resources to the browser which it understands that the browser might require). HTTP/2 has good browser support and is backward compatible with HTTP 1.1 which means browsers not supporting it can fallback to the older protocol.

    HTTP/2 support

    HTTP/2 browser support information on Can I Use
  3. Move to HTTPS — HTTPS is a precondition for HTTP/2. So, yay!

  4. Reduce the initial app content on bootstrap — We’ve reduced the initial app loading size by more than a 100 KBs (and more… or should I say less… to come). This has been achieved due to the combined result of:
    • Removing heavy libraries with their lighter counterparts - We’ve completely removed libraries like Angular Bootstrap and Chosen from our app dependency. These have been replaced by in-house implementations of the respective libraries.
    • Loading only the modules critical to bootstrap, on bootstrap - On analyzing, our app’s bootstrap process, we realized that several modules which weren’t critical to it were still loaded. After some code refactor these modules have been eliminated from the process.
    • Splitting of vendor files into primary and secondary files - More on that later in the post.
  5. Implement better cache-bust mechanism — We’ve moved to naming our files based on MD5 checksum of their content instead of naming them based on their timestamp of generation, which was the case earlier. This has resulted in generation of fewer unique files on every build. Only the files which are modified get renamed. 

  6. ETags for the index page — The ETag or entity tag based on the HTTP protocol allows the client to make conditional requests. This enhances the caching mechanism and saves bandwidth since the browser only makes the request when the file has changed. Ergo, better loading time!

  7. Split vendor files into primary and secondary — It is a common practice in web development to combine all the libraries, required by the app, into a single file. Usually, this is called the vendor file and it gets downloaded entirely in the beginning. Often, several components of the vendor file aren’t required in the usual app usage, but they still get downloaded since it is a single bundle. We’ve divided the vendor file into two and split their content based on the frequency of usage. The first vendor file contains all the libraries which are absolutely necessary for the application to load. For example, AngularJS and its dependencies. The second vendor file is loaded on demand, based on modules which require less frequently required libraries, for example, Graph libraries to show graphs. By doing so we’ve cut a good chunk of approximately 200 KBs from the original monolithic vendor file, a considerable amount by any standard.

  8. Implement login page in vanilla JS — The VWO app is written in AngularJS framework. AngularJS is a heavy framework. To add to the woe it has tons of dependencies. The benefit of moving the login page out of AngularJS context, and keeping it in plain JS has a two-fold benefit. Firstly, the login page becomes lighter since it isn’t dependant on the framework anymore. Secondly, by utilising the time that the user takes in filling his credentials we can load, as much of the app, in the background, as possible. Thus, when the user is done signing in, a major portion of the app, if not all, would’ve already been downloaded.

  9. Optimize images - Though we used to optimize images earlier, it required the developers to manually run the task and commit those images to the repository. This was cumbersome and often developers would miss doing it. This has now been incorporated into our build process. Each image that now reaches the browser is optimized.

We’ve come a long way from the initial VWO app that was made two years back. And we still have a lot to cover. As we see it, this is just the tip of the iceberg. We’ll be publishing more posts on the improvements that we push to the app. If you have any suggestions, queries or concerns feel free to drop a comment.

Recently, I spoke about securing Web Applications at JSChannel Conference ’16. The conference venue was The Ritz-Carlton, Bangalore. JSChannel is a great conference to attend and to connect with some great people. And when I say great, I literally mean it. We met with Yehuda Katz (one of the creators of Ember.js), Lea Verou (Expert in the W3C CSS Working Group) & Christian Lilley (Father of SVG) and experts from McKinsey.

Three Wingifighters flew to attend and listen to this amazing conference and here we are, showing off some swag.🤘

Day 1 was amazing. Rachit, having attended almost all the sessions, has shared his learning experience at the conference on the Team Wingify’s Space.

Before The Talk

Speaking at a conference involves a lot of work before getting on stage. Preparation is crucial. I spent a good number of hours to jot down a list of security vulnerabilities to talk about and steps to mitigate them. I had to make sure none of my demonstrations exposed the vulnerabilities of the websites I chose to talk about.

And guess what, in my preparation for the demo, I actually found another way to bypass a previously reported vulnerability in time just before the conference. Keeping in mind the JavaScript conference and the audience, I made sure everything was related to Browser level and Node.js application attacks.

The Talk

For the video, scroll down to the end of the post.

It all started with a humorous introduction and a show of my prowess!

Security is like the elephant in the room where everyone agrees that it’s very important but only a few take it very seriously.

I touched upon the recent Github reused password attack and why we should follow a good password hygiene and move towards multi-factor authentication (MFA).


Rule of thumb: Validate input and escape output


XSS + CSRF = Game Over!

I’ve developed a sample web application using Node.js, Express and Angular that is vulnerable to common security vulnerabilities were demonstrated. Click here to see the code.

What could possibly go wrong?

The talk ended with a live demonstration of an interesting and serious vulnerability found on a popular hiring platform, RecruiterBox. A JavaScript injection using which an attacker can upload a maliciously crafted resume and can perform Cross-site Scripting attacks. I used Burp Suite, an interceptor proxy to bypass the fix deployed by Recruiterbox, for demonstration purposes.

To know more about the vulnerability, click here.


After the talk, it was rewarding to see a good response and interesting queries from the audience. One comment I received from audience was “We have just realized that our services are vulnerable to one of the attacks you have demonstrated and we never gave a thought to it. Thank you!”.

My 2 cents for attending any tech conference

More than the talks themselves, it is the people that you should attend the conference for. You should meet the other attendees! If a particular talk is interesting and useful then you can and should talk to the speaker.

Key takeaways:

  1. Never blindly trust user input.
  2. Always use proven sanitizers and tools.
  3. Perform security audits.
  4. Keep discussing vulnerabilities because the Internet has a bunch of weird old stuff that, not necessarily, every software developer knows about.


As a first-time speaker, I wasn’t sure what to expect. It turned out to be a great experience and received very positive feedback.

There were just two hours left to catch a flight for an exciting opportunity to present at the biggest Selenium conference, SeleniumConf 2016, and we were still waiting for our cab to the airport. Our driver was lost within 350 meters of our Wingify office, finding his way around the vicinity. Eventually, we boarded the flight at the final call!

A cool breeze welcomed us at Bengaluru airport, and the next morning we were at The Chancery Pavillion Hotel with our passes:

Day 1 was about keynotes, new tools and sponsor stands. HP launches lean UFT, introducing Selenium inbuilt with the tool. There were a lot of talks that explored more areas Selenium could be used in, thereby widening its scope.

D day: Demo day

There was no hurry to reach the venue today as the streets were all mapped a day before, suits and boots were tied up. It was the day to present, world’s first ever open source automation tool for push notifications - PushKnot

Push notifications let users to opt into timely updates from sites they love and allow you to effectively re-engage them with customized, engaging content. As per recent surveys, push notifications are turning out to be better than email notifications.

Since it’s a relatively new technology which is booming, the SDLC flows goes like this specs written, functionality developed, unit tests written, how about testing it end to end? Do it manually or automate it like a boss!

PushKnot helps you do the latter part well.

“PushKnot is a specialized open-source proxy tool for modifying, parsing and fetching desktop push notifications.”

How PushKnot works:

It works as a proxy server which intercepts the service-worker registration request’s response. It adds a specific payload and the new modified service-worker is registered with the browser.

This payload has specialized code which intercepts and captures the push notification received. Once it has intercepted the push notifications, it saves the notification data in JSON format in a file, and forwards the notification back to the browser so that it can be seen there.

Once the response is stored in a JSON file it can be easily read and verified.


  1. The service is available at https://github.com/Ankitagupta2309/pushKnot

  2. After cloning the repo and running npm install, you can start it by running

    node start.js —domain=<yourdomain>

  3. By default it will run on port 9002, if you want to change it, you can do so by using the flag —port=9003

  4. Set up https system proxy to point to

    setup proxy push

  5. When you are launching your browser you need to set 2 flags:

    • Start a chrome browser with --ignore-certificate-errors flag
    • Set browser preference 'profile.default_content_setting_values.notifications': 1
chromeOptions: {
	'args': ['--ignore-certificate-errors'],
	prefs: {
		'profile.default_content_setting_values.notifications': 1

Slides deck from the talk.

Demo from the talk.

Video of the talk.

It was a great learning experience. Received good feedback on our tool, some of which have already been implemented. Write back to us if you have any feedback or queries.

At Wingify, we recently began an initiative by the name Engineering Talkies where our engineering teams share their experiences, repertoire of best practices, and learnings. Think of it as a knowledge sharing session between people within and across teams.

The last talk was about Web Application Security where I spoke about the best practices to follow for tightening the security of our web applications.

It started with a little introduction to my infosec journey and how companies deal with security researchers. Along the way I also touched upon why startups, specifically, should care about security.

Information Security is not just about following some best practices checklist, it’s all about lateral thinking.

We explored OWASP’s Top 10 Vulnerabilities considering possible attacks and techniques to shore up our defense against them. Next we went through some real world examples of common security threats and how the risks can be mitigated and flaws addressed.

In my preparation for the talk, I had conducted an internal security audit of our product application and the security measures we have put in place for VWO that should be followed for other products under the Wingify umbrella. Yes, we are coming up with some cool new products other than VWO, the beloved A/B Testing Tool, Stay tuned.

Slides from the talk on security at Wingify Engineering Talkies:

It’s very useful for companies to perform internal security audits and today we understand a little better about why we sometimes need to slow down feature development and clean up a bit.

We take security very seriously at Wingify. If you find any security vulnerability, please report it to [email protected]. We will respond as quickly as we can to any security issues identified.

Coding is always fun at Wingify, be it a Wingify Camp or a Fun Friday. And to add to the fun, in a Fun Friday Code In the Dark was organized by Wingify on 15th April 2016 in both Wingify’s Delhi and Pune office. The event is a front-end (HTML, CSS) competition created by the folks at Tictail, where each contestant compete to implement a website design given only a screenshot. The catch is, no previews of the results are allowed during the implementation, and no measuring tools can be used. There are some simple rules of the event:

  • Duration: 15 min
  • Technology: HTML/CSS
  • No previews
  • One champion

The event started at 5 o’clock in the evening and was divided into two slots, each slot having 9 participants. The rule was to choose two from each slot so that final four compete in the final round. Along with that, to add to the fun and frolic, a loud music was played to motivate the contestants to write the code as fast as they can. The lights were turned off to create an awesome atmosphere to complement the theme of the event. The only light flashing was that of TV and Laptop screens which added a magical appearance to the room.

Ankit Jain and Kushagra Gour starting the event
Contestants coding in the dark

After the completion of the allotted time, two participants from each team were selected based on the audience voting.

A final round was organized between selected “Fantastic Four” participants from the 2 slots which were Sparsh Gupta, Hemkaran Raghav, Ashish Bardhan, Dheeraj Joshi.

Meanwhile, some people were busy in eating delicious sandwiches and having some beer to quench their thirst.

Meanwhile in Wingify’s Pune office… /

Next was to decide the winner, and after voting by everyone finally we had the winners.

  1. Sparsh Gupta (Our CTO) - Winner
  2. Hemkaran Raghav - Runner Up

Also, The winners from Pune office were:

  1. Paras Chopra (Our CEO) - Winner
  2. Rachit Gulati - Runner Up

Yeah, our CEO & CTO are code-in-dark experts :) Checkout the awesome prizes that winners got:

Sparsh Gupta and Hemkaran Raghav getting his prize

It was a great experience to participate in the event. Thanks to Kushagra Gour for organizing the awesome blossom event. We hope that this type of events will continue to happen in the time to come.

You can watch a glimpse of the event here:

If you want to know more about the events and happenings at Wingify, follow us on (Twitter, or Facebook). If you have any suggestions for different type of events that we can organize, go ahead and leave comments and we will get back to you. If you like what we do at Wingify and want to join the force, we will be more than happy to work with you. As always, we are looking for talented people to work with us!