Performance optimization for Web Checkout Experience

[manojradhakrishnan]

Context

The Hyperswitch Web Checkout plays a very important role in the user’s payment journey. It is an iFrame which provides an inclusive, consistent and a blended payment experience for the user. Learn more about it here or read the blog here

As we continue to support more and more features and payment methods across the world, it is very critical to keep the payment experience lightweight and fast. The faster the payment experience loads for the customer the higher the conversion rates.

Problem

The performance of the Hyperswitch Web Checkout for a smooth payment experience is measured by two metrics:

- First Render: The first render is the time taken from initiation of SDK to mounting of the iFrame. It depends upon download of JS file, fetching of assets and many more steps.

- Final Render: The final render is the time taken from initiation of SDK to display of all payment methods. It depends on multiple aspects such as number of payment methods to load, speed of internet on the client, number of API calls, API latencies and many more factors.

The target is to reduce the Final Render time by 30%

How to get started?

1. Setup Hyperswitch by following these instructions on your local machine and make a test payment. Ensure that your build runs within your local on production mode. This is a prerequisite.
2. Hunt and shortlist a tool to simulate a performance test. Will be great to understand if you had listed down specific criteria to choose the right tool
3. Run the checkout experience and plot a waterfall of the various events that takes pace for the until the final render of the web checkout
4. Simulate and establish TP90 (90th percentile) Final Render Time on your local machine

Expected Outcome

Find avenues to reduce Final Render Time by 30% and share your proposal as a Github issue under this discussion.

All the best !!!

[Kumar-Rishav-py]

Proposal: Performance Optimization for Web Checkout Experience #4102
Expected Outcome: To reduce the final render time by 30%.
Optimization:
• Compress and optimize images, loop video, and any other type of media forms.
• Utilize lazy loading techniques to load non-essential components.
• Compress and minify JavaScript files to reduce loading time.
• Split the bundle JavaScript into smaller files to avoid loading unnecessary code.
• Preload essential resources and dependencies to improve subsequent page loads.
• Utilize techniques such as server-side rendering (SSR) and client-side hydration to improve perceived performance.
• Optimize API endpoints and database queries to minimize response times.
• Consolidate multiple API calls into batch requests to reduce overhead and latency.
• Measure the current TP90 Final Render Time on local machines to establish a baseline for comparison using tools like Chrome
DevTools and Lighthouse.
• Leverage browser caching and CDN services to cache static assets and reduce server round-trips.
• Ensure scalability to simulate various traffic loads and reporting capabilities to analyze performance bottlenecks effectively.
Testing:
• Use load testing tools such as Apache JMeter, Gatling, or LoadRunner to generate concurrent user requests and measure response
times.
• Identify performance bottlenecks, server capacity limits, and potential scalability issues.
• For stress testing, gradually increase the number of concurrent users beyond normal levels.
• Implement real user monitoring tools such as Google Analytics, New Relic, or Datadog to capture and analyze performance metrics
from actual user interactions with the Hyperswitch Web Checkout.

[prafulkoppalkar]

hey @Kumar-Rishav-py consider our Hyperswitch SDK and its architecture ..with hyperloader.js which mounts an iframe whose behavior is dynamic and the sdk is interactive ..how would you propose to do SSR with hydration?

[Kumar-Rishav-py]

• On the server-side, utilize hyperloader.js to mount the Hyperswitch iframe. hyperloader.js will handle the initial rendering of the iframe content (app.css and app.js), incorporating the components and hooks provided by the SDK. Additionally, it will optimize the loading process.
• hyperloader.js is responsible for dynamically loading and mounting an iframe onto the webpage, encapsulating dynamic behavior such as user interactions, payment method selection, and processing. This approach ensures isolation and security.
• The server-rendered HTML will include the iframe content along with any necessary JavaScript code for hydration. On the client-side, JavaScript will take over and hydrate the iframe content, attaching event listeners to the iframe components and populating the DOM with data from the client-side. This process results in improved SEO and faster loading times.
• Utilize React components like UnifiedCheckout, CardWidget, and CardNumberWidget for seamless payment integration.
• Leverage hooks such as useHyper() and useElements() to access methods in the Hyperswitch API and Elements API for dynamic interaction and customization

[alpha951]

Why does this text seem to be AI generated?

[RaiVaibhav]

Hey @alpha951 (replying after seeing the notification on email), main problem is the architecture, both stripe and hyper uses an iframe for security reason, second use will have to load the iframe, but wait here, even if we stream the html and make the css inline using SSR in iframe, what about other assets? it still needs to load the resources to perform hydration with various actions, now while debugging I figure, in most of the cases the domain of the iframe will not be same as where it's getting used, means cross-domain assets issue, means it can't pre-fetch or pre-load the resources from the users' domain. (though @prafulkoppalkar don't agree here with me #4102 (reply in thread))

Now what can be the solution, using one version of SSR i.e., react RSC but this is unstable, and it came very recently unlike juspay, another is using qwik which also came very recently but the point, we need to see the from the fact that everything is inside cross domain iframe

And I also realized that the part of point -3 which is mentioned above, juspay is already doing it but it's not working because of the crossdomain thingy.

I feel like I should actually rewrite their elements in qwik

[RaiVaibhav]

At the end I am sure a thought on rewriting the component should be given, it quite an interesting topic to me, which take my interest whenever I see any notification on my email :P

[pavanrk123]

with hyperswitch app server installed locally I went ahead and followed instructions for web simulation but the UI elements would not load i have checked all dependencies and made sure i followed all commands i have attached the snapshot of localhost 9060

please point out the mistakes I made

[prafulkoppalkar]

Hey @pavanrk123 did you follow the read me file or the gitbook documentation

[Ashmash100]

Hi @prafulkoppalkar
I'm facing the same issue with 404 errors in console

[prafulkoppalkar]

@pavanrk123 @Ashmash100 Once the installation is successful, you can try running the app with the following commands - npm run re:startthen npm run start on separate terminals...This will trigger a build of the project. On a successful build, you should see a message 'Compiled successfully' in your terminal. We have updated the docs since cmd npm run start:dev is having issues building the project intermittently.

Next step would be to run npm run start:playground or you an follow the updated docs

[Devanshudd]

@prafulkoppalkar ,which url did you write here in order run control center?
Update the .env file in the root directory.

apiBaseUrl = your-backend-url
sdkBaseUrl = your-sdk-url

[PritishBudhiraja]

Hey @Devanshudd for running Control Center Locally,

apiBaseUrl = If you are running backend locally, then http://localhost:8080 or if using our sandbox environment - https://sandbox.hyperswitch.io
sdkBaseUrl = If you are using our SDK locally, http://localhost:9060 or if using our sandbox environment - https://beta.hyperswitch.io/v1/HyperLoader.js

[varadkadtan]

• Optimize Assets: Compress images and minify CSS and JavaScript files. Tools like UglifyJS for JavaScript minification and OptiPNG for image compression can be used. This could potentially reduce the asset size by up to 60-70%.
• Reduce API Calls: Implement a caching mechanism to store the results of API calls. This could be done using Redis or Memcached. By storing the results of frequent API calls, you could reduce the number of API calls by up to 50%.
• Improve API Performance: Optimize the backend code to reduce the processing time. This could involve improving the database queries or using faster algorithms. Tools like New Relic or Datadog can help identify slow queries or bottlenecks in your code. Optimizing these areas could potentially improve API response times by 20%.
• Lazy Load Payment Methods: Implement lazy loading for payment methods. This means only loading the payment methods when they are needed, which can significantly reduce the Final Render Time. Lazy loading can be implemented using Intersection Observer API in JavaScript and could potentially reduce the initial load time by up to 40%.
• Use a Content Delivery Network (CDN): Using a CDN can improve the download speed of your assets. CDNs like Cloudflare or Akamai can be used to serve your assets from the server closest to the user, which can potentially improve asset download speed by up to 50%.
• Upgrade Internet Connection: If possible, upgrading to a faster internet connection can reduce the load time. This is more of a client-side improvement, but if the majority of your users are on a slow connection, providing a lite version of the checkout experience could potentially reduce the load time by up to 30%.
• After implementing these steps, you should measure the Final Render Time again to quantify the improvement

[Anandmohan7]

To achieve a 30% reduction in Final Render time for the Hyperswitch Web Checkout, you can consider the following strategies:

1. Optimize API Calls: Review and optimize the API calls made during the checkout process to reduce latency. This could involve batching requests, caching data where possible, or optimizing the server-side code to respond more efficiently.

2. Minimize Payment Methods Load Time: Evaluate the necessity of loading all payment methods simultaneously. Consider lazy loading or prioritizing the most commonly used payment methods to display initially, while asynchronously loading the rest.

3. Improve JS File Download: Optimize the JavaScript file download process by reducing its size through minification and compression techniques. Additionally, consider utilizing a content delivery network (CDN) to serve the JS file closer to the users for faster downloads.

4. Enhance Asset Fetching: Ensure efficient fetching of assets by minimizing the number of requests and leveraging caching mechanisms. Utilize HTTP/2 or newer protocols to improve asset retrieval speed.

5. Client-side Optimization: Implement client-side optimizations such as code splitting, lazy loading, and prefetching to improve the overall loading performance of the checkout page.

6. Monitor and Analyze: Continuously monitor and analyze the performance metrics using tools like Google PageSpeed Insights, Lighthouse, or browser developer tools. Identify bottlenecks and areas for further optimization.

7. Parallelize Processes: Where applicable, parallelize processes such as asset fetching and API calls to make better use of available resources and reduce overall rendering time.

By implementing these strategies, you can work towards achieving the targeted 30% reduction in Final Render time for the Hyperswitch Web Checkout, thereby improving the overall payment experience for users.

[Gyanesh101]

you will nedd to optimize various aspects:
1.optimization of code:
Review and optimize the JavaScript code to reduce execution time.
Minimize unnecessary API calls and optimize existing ones to reduce latency.
2.Optimization of assets:
Minify and compress CSS, JavaScript, and image assets to reduce their size and improve loading times.
Consider using content delivery networks (CDNs) for faster asset delivery, especially for global users.
3.Parallel Loading:
Explore parallel loading techniques to load resources concurrently, improving overall loading speed.
Utilize asynchronous loading for non-blocking resource fetching.
4.Server-Side Optimization:
Optimize server-side code and database queries to reduce response times.
Utilize caching mechanisms (e.g., Redis, Memcached) to cache frequently accessed data on the server side.
5.Iterative Improvement:
Continuously iterate and refine the optimization efforts based on performance data and user feedback.
Regularly review and update the optimization strategies to adapt to changing technologies and user behaviors.

[pavanrk123]

Setup Hyperswitch:
hyperSwitch was set up in 3 steps
1.App server initializtion using dockers
2.web client playground was initiated
initially the ui components weren't loading only the header showing HS unified checkouts was loading

3.control centre was cloned

4.tool to simulate a performance test: two main tools i chose were jmeter and locust, locust came up on top as python is used for scripting and it uses 70% lesser system resources compared to jmeter which reduce impact on results of rendering compared to jmeter
5.waterfall of events:
this chart shows UI components and buttons flow as UI renders

Simulate and establish TP90 (90th percentile) Final Render Time on your local machine:
Google chrome dev-tools develper options->developer options->performance insight
buffering log is shown in snapshot below

the UI did not load during web app simulation again

ways to improve render times for final rendering:
by observation

1. removal of "items to be checked out" from the payments page can result in resource allocation for only loading of payments interface for the web application
2. prefetch caching on client side
3. pre-monitoring of movement of user right before initiation of payments page loading using some AI models for prediction

[akash-c-k]

Hey @pavanrk123 The UI did not load up because there was a bug. We have fixed it now. If you take the latest pull, you should not face this problem. You can then get to the TP 90 for the final render time.
cc: @prafulkoppalkar

[pavanrk123]

@akash-c-k sure ill retry again with a new pull request

[vikas0kumar0sharma]

To address the problem of reducing the Final Render Time of the Hyperswitch Web Checkout by 30%, here is a proposed solution:

1. Performance Testing Tool Selection:

   • Identify and select a performance testing tool that can effectively simulate the load and measure the performance metrics of the Hyperswitch Web Checkout.
   • Criteria for tool selection should include:
     • Ability to simulate real-world scenarios and user behavior.
     • Support for measuring metrics such as load times, API latencies, and rendering times.
     • Compatibility with the technology stack of the Hyperswitch Web Checkout.
     • Scalability to handle the expected load.
     • Detailed reporting capabilities to analyze performance bottlenecks.

2. Performance Testing and Analysis:

   • Utilize the selected performance testing tool to simulate various scenarios and loads on the Hyperswitch Web Checkout.
   • Conduct performance tests to measure the First Render and Final Render times under different conditions (e.g., varying network speeds, number of payment methods, API latencies).
   • Analyze the performance test results to identify bottlenecks and areas for optimization.

3. Optimization Proposals:

   • Based on the analysis, propose optimization strategies to reduce the Final Render Time by 30%. Some potential avenues for optimization may include:
     • Optimizing the loading of JavaScript files and assets to improve the First Render Time.
     • Implementing caching mechanisms to reduce API call overhead and latency.
     • Minimizing the number of API calls or optimizing their payloads to decrease processing time.
     • Implementing lazy loading techniques to defer the loading of non-essential resources until they are needed.
     • Utilizing content delivery networks (CDNs) to distribute assets closer to users and improve loading speeds.
     • Implementing code optimizations and performance best practices.

4. Github Issue Proposal:

   • Create a Github issue documenting the findings from the performance analysis and proposing optimization strategies.
   • Include detailed descriptions of the proposed optimizations, along with any potential challenges or considerations.
   • Engage relevant stakeholders, such as developers, product managers, and QA engineers, to discuss and prioritize the proposed optimizations.

5. Implementation and Testing:

   • Implement the proposed optimizations based on the agreed-upon priorities.
   • Thoroughly test the changes to ensure they effectively reduce the Final Render Time without compromising functionality or user experience.
   • Conduct additional performance tests to validate the improvements and measure the achieved reduction in Final Render Time.

6. Monitoring and Iteration:

   • Implement monitoring tools to continuously monitor the performance of the Hyperswitch Web Checkout in production.
   • Monitor key performance metrics, including First Render and Final Render times, to ensure they meet the desired targets.
   • Iterate on the optimization strategies based on real-world performance data and user feedback to further improve the payment experience over time.

By following these steps, the goal of reducing the Final Render Time of the Hyperswitch Web Checkout by 30% can be achieved, leading to a faster and more efficient payment experience for users.

[Hemashree21]

To reduce the final render time by 30%, I came up with some suggestions.

• We can optimize the JS code in such a way that we can break down larger codes into smaller chunks and only run them when necessary so that they will load only when needed.
• We can implement lazy loading for images with larger sizes.
• We can also enhance the cache mechanism so that it avoids fetching the same data repetitively.

[Abhisht01]

Proposal: Performance Optimization for Web Checkout Experience #4102
Strategies:

Payload Trimming:

• Use techniques such as tree-shaking and dead code elimination to analyze and reduce the initial payload size.
• Module bundlers such as Webpack or Rollup can be utilized for efficient payload trimming.

Render Streaming:

• Load the components as they become ready don't wait for the entire application to load.

Resource Prioritization:

• Prioritize the loading of critical resources required for the initial render.
• Implement techniques like resource hints (prefetch, preload, preconnect) for critical assets.
• Explore options like HTTP/2 Server Push for pushing critical resources proactively.

Network Resilience:

• Set up service workers for caching and offline support.
• Use network fallbacks and stale-while-validating caching methods.

Payload Splitting:

• Split the application payload into smaller, granular chunks.
• Implement code splitting and lazy loading for non-critical components and resources.
• Utilize dynamic imports or library-specific lazy loading mechanisms.

My Resume-
resume.pdf

[neerajkumar-n]

@Abhisht01 - have you filled in the Google form? If not, request you to fill out the Google form.

You can find the details regarding the form here: https://github.com/juspay/hyperswitch/wiki/Hyperswitch-Hiring-Challenge

[RaiVaibhav]

Hey @pavanrk123 @Freak0802 I figured the info on the doc needs rewriting, setup worked for me when I looked at .env variables getting generated

STATIC_DIR=./dist
HYPERSWITCH_PUBLISHABLE_KEY=""
HYPERSWITCH_SECRET_KEY=""
HYPERSWITCH_SERVER_URL="http://localhost:8080"
HYPERSWITCH_CLIENT_URL="http://localhost:9050"
SELF_SERVER_URL="http://localhost:5252"

If for some reason HYPERSWITCH_SERVER_URL doesn't work with localhost:8080 we can directly use the sandbox url i.e., https://sandbox.hyperswitch.io/ because we are still in test mode, I have to say it's a very tightly coupled libraries.

One more issue I saw, prompt doesn't ask for values again, in case we enter the wrong value for the key.

[prafulkoppalkar]

npm run start:playground this cmd will install the dependencies for the demo app and ask for the prompts initially and will not prompt you once again if the values have already been entered..
the above cmd aims to quickly get you set up everything .. for subsequent changes you can directly directly modify the .env file and alternatively use cd Hyperswitch-React-Demo-App and npm run start to get the app running

[RaiVaibhav]

Hey @prafulkoppalkar thanks, I figured, you think it will be helpfull creating new command line argument to show the prompt again, something like
--init-variable

[shushantbk16]

To reduce the Final Render time of the Hyperswitch Web Checkout by 30%, we can focus on optimizing several aspects of the checkout process:

1. Code Splitting and Lazy Loading: Implement code splitting and lazy loading to load only the necessary code and payment methods when needed, reducing initial load times.
2. Optimize Asset Loading: Optimize the loading of assets such as images, CSS, and JavaScript to reduce their size and improve loading times.
3. Minify and Compress Assets: Minify and compress your JavaScript, CSS, and other assets to reduce their size, improving load times.
4. Reduce API Calls: Minimize the number of API calls and optimize their responses to reduce latency.
5. Implement Caching: Use caching mechanisms to store and reuse data that is frequently accessed, reducing the need for repeated API calls.
6. Reduce Render Blocking Resources: Identify and eliminate or defer render-blocking resources to improve initial render times.
7. Use a Content Delivery Network (CDN): Use a CDN to cache static assets and deliver them to users from servers closer to their location, reducing load times.
8. Server-Side Rendering (SSR): Implement SSR to generate the initial HTML on the server, which can reduce the time it takes for the page to become interactive.

[YashKamboj]

Proposal: Performance Optimization for Web Checkout Experience

Suggestions to achieve performance optimization:

1. Code Optimization:

• Review and optimize JavaScript code to reduce execution time.
• Minimize and optimize API calls to reduce latency.
• Compress and minify CSS, JavaScript, and image assets to reduce size.
• Implement caching on client side

2. Parallel Loading:

• Implement parallel loading techniques to load resources concurrently.
• Utilize asynchronous loading for non-blocking resource fetching.

3. Server-Side Optimization:

• Optimize backend code and database queries to reduce response times.
• Implement caching mechanisms to cache frequently accessed data.

Expected Outcome:
By implementing these proposals, we aim to achieve a 30% reduction in Final Render Time for the Hyperswitch Web Checkout.

[AakashDevilstar]

Hey @pavanrk123 @Freak0802 My Proposal for reduce the final render to 30%
Proposal: Performance optimization for Web Checkout Experience #4102

Below are the Some Suggestions to achieve the final render to 30% are:

1. Optimize Images: Compress images to reduce their file size without significantly affecting quality. Use modern image formats like WebP where supported, lazy loading to defer the loading of off-screen images, and srcset to serve different image sizes based on device resolution.

2. Code Splitting: Implement code splitting to split your JavaScript bundles into smaller chunks. Load only the necessary JavaScript for the current page or view, and lazy load additional bundles as needed. This can reduce the initial load time and improve performance.

3. Minify and Bundle CSS and JavaScript: Minify CSS and JavaScript files to remove unnecessary whitespace, comments, and redundant code. Bundle multiple files into a single file to reduce the number of requests and improve load times.

4. Implement Caching: Leverage browser caching by setting appropriate cache-control headers for static assets. Use caching strategies like server-side caching, browser caching, and CDN caching to reduce server load and improve load times for returning visitors.

5. Lazy Loading: Implement lazy loading for images, videos, and other non-critical resources to defer their loading until they are needed. This can improve initial load times and reduce bandwidth usage, especially for long-scrolling pages or pages with many images.

6. Content Delivery Network (CDN): Use a CDN to distribute static assets, such as images, CSS, and JavaScript files, to servers located closer to the user's geographic location. This reduces latency and improves load times by serving content from the nearest edge server.

[Devanshudd]

Proposal for #4102

1st Step: I set up Hyperswitch using points mentioned in the documentation

2nd Step: Based on the specific criteria outlined for selecting a performance testing tool, Apache JMeter stands out among performance testing tools for several reasons

• Open Source and Free : Apache JMeter is an open-source tool, which means it's free to use and can be easily accessed and modified by developers

• User-Friendly GUI: Performance test creation and configuration are made simpler using JMeter's intuitive graphical user interface.It offers a graphical environment for building test plans, defining user scenarios, and configuring test elements, making it accessible to both beginners and experienced testers.

• Rich Reporting and Analysis: JMeter provides extensive reporting and analysis capabilities to monitor key performance indicators (KPIs) such as response times, throughput, error rates, and resource utilization. It offers customizable graphs, tables, and listeners for visualizing test results and identifying performance bottlenecks.

• Active Community Support: JMeter benefits from a large and active community of users and contributors who provide support, documentation, tutorials, and plugins. Anyone can find extensive resources, forums, and user groups dedicated to JMeter, making it easy to find assistance, share knowledge, and stay updated on best practices.

• Versatility: JMeter is a versatile tool that supports a wide range of protocols and technologies, including HTTP, HTTPS, JDBC, FTP, SOAP, REST, JMS, and more. It can be used to test various types of applications, including web, mobile, and API-based applications.

• Integration with CI/CD: JMeter seamlessly integrates with popular CI/CD tools like Jenkins, TeamCity, and Bamboo, allowing you to automate performance tests as part of your continuous integration and delivery pipelines. It also supports integration with third-party plugins and extensions for extending functionality and integrating with other tools and frameworks.

3rd Step:Upon UI rendering, waterfall events emerge.

4th Step:Simulate and establish TP90 (90th percentile)
As you see here UI is not rendering but we try to use lighthouse in order to get some analysis data

To increase rendering speed, focus on optimizing the following key areas highlighted by Lighthouse:

• Enable Text Compression : Implement text compression techniques such as gzip or Brotli to reduce the size of text-based resources like HTML, CSS, and JavaScript, leading to faster download times

• Eliminate Render-Blocking Resources: Reduce the amount and effect of render-blocking resources by loading non-essential JavaScript and CSS asynchronously, which will speed up the browser's ability to render content

• Reduce Unused JavaScript : Identify and remove unused or unnecessary JavaScript code to streamline execution and reduce the overall payload size, improving parsing and execution times.

• Minify CSS and JavaScript : Minify CSS and JavaScript files by removing unnecessary whitespace, comments, and redundant code, reducing file sizes and speeding up download and parsing times.

• Optimize Largest Contentful Paint (LCP) : To improve perceived performance and user experience, give priority to loading and optimizing the largest contentful items on the website to ensure they render rapidly.

Some of my suggestions to reduce the Final Render time by 30%

• Minimize API Calls : Reduce the number of API calls by consolidating requests where possible. Combine multiple requests into one to decrease overhead.

• Optimize API Response Time : Improve response times by analyzing API latencies and streamlining server-side operations. When it makes sense, use caching techniques to lighten the burden on backend systems.

• Code Splitting : Use code splitting strategies to load the JavaScript code that is required for each individual page or component. This accelerates the rendering process and minimizes the size of the initial download.

• Prioritize Loading: Implement intelligent loading strategies to prioritize essential payment methods and assets. Load critical components first to provide users with a faster initial experience.

• Continuous Monitoring and Optimization: Implement robust monitoring and analytics to track performance metrics continuously. Use tools like Real User Monitoring (RUM) to gather insights into user experience and identify areas for further optimization.

[prafulkoppalkar]

Parsing is done by the browsers, when the assets/scripts that are needed by iframe are preloaded on the parent dom the browser fetches the content from the domain localhost:9050.. while the iframe will still request for the assets again but the browser will use the cached version from the browser cache resulting is faster loading time and reduced load on the server

[RaiVaibhav]

Hey @prafulkoppalkar I think this part is not working, if you check the proposal, then I am mentioned about this case.

if my webapp is running at abc.com and there is an iframe which is
coming from def.com and needed a scipt test.js, so, if I preload the script i.e., test.js on
abc.com then will this script be cached for the iframe
coming from def.com, will the browser cache the preloaded script i.e,, test.js and
let the iframe execute it on initial render?

NO

Reasons:

• Separate HTTP requests: When a script is loaded on a webpage, the browser makes an HTTP request to the server hosting the script. This request is separate from the request made to load the webpage itself. Therefore, even if abc.com and the iframe from def.com both reference test.js, two separate HTTP requests will be made.

• Browser caching: When a browser loads a script, it may cache the script to improve performance. However, this cache is typically only used when the same script is requested again from the same origin. If test.js is loaded from abc.com, the browser will not use the cached script for def.com.

And we already know about the Same origin policy.

[RaiVaibhav]

Hey @prafulkoppalkar sorry for disturbing you on Monday, saying it with my curiosity, but kindly have a look at above reply and let me know, if I miss something.

[prafulkoppalkar]

@RaiVaibhav the script is being preloaded by the def.com domain ... so it will preload and cache it but appreciate the interest here if possible will get back to you with a recording

[RaiVaibhav]

Thanks for your time, but I am not going to agree here, because I tried with production build and feed it over lighthouse to see the performance and behavior difference

[RaiVaibhav]

Proposal

Objective:

To ensure seamless integration both now and in the future, reducing the final render time by 30% will enhance the user experience.

Key Results:

• Keep the integration seamless and improve user experience.
• Improve the final render time by 30%.

Scope:

Considering the timeline and purpose of this improvement i.e., to check candidate capabilities and further using this proposal to implement to make an actual change, this will need a local setup and research on how binding between client and server is actually working.

We are going to measure the success of the project with metric as a render time and its value will be 30%.

Debugging Tool:

Chrome dev tools: Network, Lighthouse and Profiling.

Researched steps: 

Step 1:

• Follow the step mentioned in doc here to make a local Local setup | Hyperswitch
• Generating a publish and secret key from Hyperswitch dashboard.
• Providing env variables to run the setup locally (I tweaked the variable SERVER_URL value as per my need)

HYPERSWITCH_SERVER_URL="https://sandbox.hyperswitch.io"

Step 2:

After the project was served at port 9060, I decided to create the production build to examine the bundle size and various assets in the network tab. To do this, I ran the command npm run build:playground and npm run build:prod instead of npm run start:dev and navigated to the dist directory and executed node server.js and serve the client using npm serve over the port 9050. This started the backend and also served the client, now the demo app is running on port 5252. I took this step because the production build usually includes many optimizations, and the values here are the same as in the production app, making this the new entry point for further debugging.

Step 3:

This is now the time to understand how things are working or say how module was working and how coupling was happening internally.
Looking into the package json I reaslised client needs three dependencies.

    "@juspay-tech/hyper-js": "^1.6.0",
    "@juspay-tech/hyperswitch-node": "^1.0.1",
    "@juspay-tech/react-hyper-js": "^1.0.2",

Consider hyper-js is same as stripe-js stripe-js/src/index.ts at master · stripe/stripe-js (github.com) i.e., it loads the main script.

Now this script can be loaded in two ways"

• loadHyper : promise basis
• HyperElements : React wrapper elements
  Both serve the same purpose load the main script.

One issue I found in the loadHyper doesn't give user an option to support customBackendUrl unlike HyperElements.

Now can I use SSR here to render the intial element and then hydrate it, answer is no, it does support SSR but not the main functionality.
In both stripe and hyperswitch we have loadStripe or say loadHyper but both are relying on document object, so to support main SSR inside node we need to use something like jsdom but not right now as this is like changing the base class of any architecture and it is out of scope for now.

                var scriptURL;
                switch (match) {
                  case "PROD" :
                      scriptURL = "https://checkout.hyperswitch.io/v0/HyperLoader.js";
                      break;
                  case "SANDBOX" :
                      scriptURL = "https://beta.hyperswitch.io/v1/HyperLoader.js";
                      break;
                  default:
                    scriptURL = str.startsWith("pk_prd_") ? "https://checkout.hyperswitch.io/v0/HyperLoader.js" : "https://beta.hyperswitch.io/v1/HyperLoader.js";
                }
                if (document.querySelectorAll("script[src=\"" + scriptURL + "\"]").length === 0) {
                  var script = document.createElement("script");
                  script.src = scriptURL;
                  script.onload = (function (param) {
                      var instance = window.Hyper;
                      if (!(instance == null)) {
                        return resolve(Curry._3(instance, str, option, analyticsObj));
                      }
                      
                    });
                  script.onerror = (function (err) {
                      reject(err);
                    });
                  document.body.appendChild(script);
                  return ;
                }

Step 4:

My question now was, if we have a dependency on react-hyper-js which gives us various elements then what was the point of running the app with npn run start:dev over localhost:9050 (this is same as HYPERSWITCH_CLIENT_URL )

I figured react-hyper-js job is to simply create few divs and call the hyper switch client and request the different resources on an element basis or render it accordingly.

Findings:

From the step 4 of research, I started fiddling with lighthouse and network tab to understand the workflow and few of the findings were.

• The first render relies on preloading Hyperloader.js which calls app.js app.css orca.svg and paypal-checkout.min.js and then rest of the elements load accordingly on demand and for that it already shows the loading placeholder, but I didn't understand why we need to call these preload scripts, because in the step 4, I realized resources are loading on demand basis so why we need this, why hyper.js have to call app.js, app.css, orca.svg and preload it and add it into DOM for react based application or outside the iframe ? (I wasn't able to come to any conclusion)
  

• Then put the debugger on preloadFile inside hyper.js and set all the link.href='' to see the behavior on the app and how does it will respond, and nothing changed, it rendered without any issue.

  function preloadFile(type_, hrefOpt, param) {
    var href = hrefOpt !== undefined ? hrefOpt : "";
    var link = document.createElement("link");
    link.href = href;
    link.as = type_;
    link.rel = "preload";
    link.crossorigin = "anonymous";
    checkAndAppend("link[href=\"" + href + "\"]", link);
  }
  

  
  You can see that there is no network call after calling HyperLoader.js or simpler way to do this to set isPreloadEnabled to false inside window.Hyper

    new Promise((resolve, _) => {
            resolve(
              window.Hyper(publishableKey, {
                customBackendUrl: serverUrl,
                isPreloadEnabled: false,
              })
            );
          })
  

  And it solved not only the First render time but also the Final render time, it fulfilled the goal, but is this enough?
  NO

• There is a lot more to do here including: text compression of app.js, minifying the CSS checkout.hyperswitch.io/0.34.2/v0/app.css, minifying CSS in theming styles, minifying the scripts like https://checkout.hyperswitch.io/0.34.2/v0/app.js, code splitting, accessibility, layout shift on intial load and layout shift on selecting different methos and many more
  
  

Big Change

For code splitting, we can use indexing-based framework like qwik for different payment elements React | Integrations 📚 Qwik Documentation

Outcome:

Considering scope of the goal included improving the user experience based on making the webapp performant, I was able to reduce the final render time by 30% and hoping this would be useful but there is a lot to learn and a lot to improve.

[shreyanshsing]

Basic UI Improvements -

• use lazy loading with prefetching, something like this -

const CheckoutForm = React.lazy(() => import("./CheckoutForm" /* webpackPrefetch: true */));
//The webpackPrefetch: true comment is a hint to Webpack, the module bundler used by Create React App, to prefetch the module during idle time. 
//This can help improve performance by loading the module in the background before it's needed.

• the API calls in component seem to be static with non-changing responses, so their values can be cached on the client side to avoid the same API calls again. The same can be done at other places also.
• not an improvement, error handling was missing for API calls.
• move the data-fetching logic to useCallback to with proper dependencies and call this callback with either useEffect(only if deps are primitive) or useDeepCompareEffect(if any deps is non-primitive).
• use styled-components to avoid heavy CSS loading and also improve code reusability.
• Compress and minify CSS, JavaScript, and image assets to reduce size.
• use useMemo() for calculation purposes.
• using typescript would make it safe and will reduce unexpected bugs and redundant code.
• we can use development time libraries like ‘why-did-you-render’ to further optimize the performance.

Webpack Improvements -

• configuring caching in Webpack will improve the performance.
• use optimization in Webpack to minimize & split the chunks effectively.

The current architecture seems good to migrate to NextJs to leverage server-side components and route-caching.

Measuring Performance -

I would prefer to use Locust, because of its high configurability and user-friendly interface. And for automation Robot(Selenium-based) framework.

Web App Flow -

TP90 calculation -

We can use Lighthouse / Performance insight tools from dev tools provided by Chrome to benchmark our SDK loading time and operations response time, (with different parameters like network latency, high usage, etc.) and also some extensions like Page Load Time will help.

[neerajkumar-n]

@shreyanshsing - can you fill the google form with the details you have shared here?

You can find the details of the form here: https://github.com/juspay/hyperswitch/wiki/Hyperswitch-Hiring-Challenge

[shreyanshsing]

have already filled the form.

[bprajeeth]

Diagnostics

Potential reasons for slower rendering and its corresponding solutions

• First Contentful Paint and Largest Contentful paint

  • FCP and LCP elements are significant contributors for pulling down the performance of the site, as seen in the diagnostics.
  • Solution: Prioritizing the loading of critical resources ensures that essential elements for rendering above-the-fold content are delivered swiftly(can enable lazy loading). Enabling Browser Caching wherever possible enhances loading speed by reducing the time it takes for the server to respond to requests. We should perform async loading for appropriate resources which improves the rendering time of resources and hence improves performance.

• Javascript

  • Represents the Javascript code used for the application. All the parts of the Javascript code need not be necessarily rendered at the same time. This can also affect the performance of the website.
  • Solution: One of the solution is to improvise the existing javascript code by reducing time complexity. Another method is to use code splitting, by this mean we can split code based on necessity and load them whenever we need them. Reducing DOM operation to the maximum extent, i.e, wherever possible also improves the loading time of the page.

• Enable text compression

  • Larger chunks of text and resources can reduce take more time to transport over the network, reducing the page render time
  • Solution: We can use text compression resources like Gzip to compress and decompress text resources, hence improving the page load time.

• Minify Javascript and CSS

  • Unwanted lines of javascript and CSS may not be the biggest cause of low performance but removing them gives cleaner and more efficient code hence slightly improving the performance of the application.
  • Solution: As mentioned above we can use popular minification tools like UglifyJS, CSSNano to minify the javascript and CSS resources. Updating and cleaning small things like this could also give a slight improvement to the performance of the application and also as a extra benefit produces very professional-looking, clean code.

Conclusion

The above are the major possible reasons for slowing the performance of the site and the suggested solution has been delivered with an overview of the code and simulation of the checkout experience. Implementing the above suggested solutions would improve the performance of the site hence improving the overall speed index of the site, thus improving the performance over 30% !!

Know more about me: Prajeeth's Portfolio 😎

[neerajkumar-n]

@bprajeeth - I see that you haven't filled our Google form yet, can you please do this?

You can find the google form details here: https://github.com/juspay/hyperswitch/wiki/Hyperswitch-Hiring-Challenge

[bprajeeth]

@neerajkumar-n Filled in the forms, Done !!

[ArchanaM1610]

To address the challenge of optimizing the Final Render time of the Hyperswitch Web Checkout, we can follow a systematic approach. Here's how we can tackle it:

Setup Hyperswitch Locally:
Follow the provided instructions to set up Hyperswitch on your local machine and ensure that it runs in production mode.
Select Performance Testing Tool:
Identify and select a performance testing tool that meets the requirements for simulating performance tests. Look for criteria such as realistic load generation, support for scripting, compatibility with web technologies, and comprehensive reporting capabilities.
Run Performance Tests:
Use the selected performance testing tool to simulate performance tests on the Hyperswitch Web Checkout. Ensure that the tests cover various scenarios and usage patterns to accurately assess performance.
Plot Waterfall Chart:
Generate a waterfall chart to visualize the sequence and timing of events that occur during the loading and rendering process of the web checkout. This will help identify any bottlenecks or inefficiencies in the process.
Establish TP90 Final Render Time:
Simulate and establish the TP90 (90th percentile) Final Render Time on your local machine. This metric represents the time at which 90% of users experience the final render of the web checkout, allowing us to identify areas for improvement.
Optimization Strategies:
Implement optimization strategies based on the findings from the performance tests and waterfall analysis. This may include techniques such as:
Minification and compression of JavaScript and CSS files.
Caching of static assets to reduce server load and improve load times.
Lazy loading of non-critical resources to prioritize essential content.
Optimizing API calls to reduce latency and improve response times.
Utilizing Content Delivery Networks (CDNs) to distribute assets closer to users.
Measure Performance Impact:
After implementing optimization strategies, re-run performance tests to measure the impact on Final Render time. Ensure that the target reduction of 30% is achieved or exceeded.
Documentation and Proposal:
Document the optimization process, including the tools used, performance test results, optimization strategies implemented, and their impact on Final Render time. Prepare a detailed proposal outlining the findings and recommendations as a GitHub issue under the discussion.
Here's a sample code snippet to demonstrate how we can approach the optimization process:

python
Copy code

Sample code to simulate performance tests and measure Final Render time

import performance_testing_tool

Set up performance testing tool

tool = performance_testing_tool.PerformanceTestingTool()

Simulate performance tests

test_results = tool.run_tests(hyperswitch_web_checkout)

Generate waterfall chart

waterfall_chart = tool.generate_waterfall_chart(test_results)

Calculate TP90 Final Render Time

tp90_final_render_time = tool.calculate_tp90_final_render_time(test_results)

Implement optimization strategies

optimization_results = optimize_final_render_time(hyperswitch_web_checkout)

Measure performance impact

optimized_test_results = tool.run_tests(hyperswitch_web_checkout)

Check if target reduction of 30% is achieved

if optimized_test_results.final_render_time < (test_results.final_render_time * 0.7):
print("Final Render time reduced by 30% or more. Optimization successful!")
else:
print("Final Render time reduction target not achieved. Further optimization may be needed.")

Create proposal and document findings

proposal = create_optimization_proposal(optimization_results)
This code snippet demonstrates a high-level approach to optimizing the Final Render time of the Hyperswitch Web Checkout and documenting the optimization process. Actual implementation may vary based on specific tools and technologies used.

[Abhisheksur123]

GitHub Issue Proposal: Reduce Final Render Time of Hyperswitch Web Checkout by 30% #4102

Proposal Summary:
We have identified performance bottlenecks in the Hyperswitch Web Checkout, leading to longer Final Render Times. Below are proposed optimization strategies along with code snippets to achieve a 30% reduction in Final Render Time.

1. Asynchronous Loading for Non-Critical Resources
   Code Example:

javascript

// Asynchronously load non-critical script
function loadScriptAsync(url) {
var script = document.createElement('script');
script.src = url;
script.async = true;
document.head.appendChild(script);
}

loadScriptAsync('https://analytics.example.com/analytics.js');
2. Asset Optimization and Minification
Code Example (CSS Minification):

html

Code Example (JS Minification):

html

<script src="script.js"></script> <script src="script.min.js"></script>

3. API Optimization and Batch Requests
   Code Example (Batch API Requests):

javascript

// Batch API requests using fetch
async function batchFetch(urls) {
const responses = await Promise.all(
urls.map(url => fetch(url))
);
const data = await Promise.all(
responses.map(response => response.json())
);
return data;
}

const urlsToFetch = ['https://api.example.com/data1', 'https://api.example.com/data2'];
batchFetch(urlsToFetch).then(data => console.log(data));
4. Caching Strategies for Static Assets
Code Example (Server-side Cache Control):

javascript
// Set cache control headers on server response
app.use(express.static('public', { maxAge: 86400000 }));
5. Lazy Loading for Images and Media
Code Example (Lazy Loading Images):

html

6. Server-Side Rendering (SSR) for Critical Content Code Example (React SSR):

javascript
// Server-side rendering with React
const html = ReactDOMServer.renderToString(

);
res.send(html);
Estimated Impact:
Asynchronous loading: Expected to reduce initial load time by 10%.
Asset optimization: Expected to reduce asset size and load time by 15%.
API optimization: Expected to reduce API latency by 10%.
Caching strategies: Expected to reduce server response time by 5%.
Lazy loading: Expected to reduce image load time by 5%.
Server-side rendering: Expected to improve perceived performance by 20%.

[shashank7753]

Proposal to reduce the rendering to 30%#4102

Objective:

To guarantee smooth integration presently and in the future, achieving a 30% reduction in the final render time will be paramount for enhancing user experience.

Key Results:

Maintain seamless integration while simultaneously boosting user experience with a targeted 30% enhancement in final render time.

Scope:
In order to achieve our objectives, we propose implementing the following strategies:

Utilize Chrome dev tools such as Network, Lighthouse, and Profiling for debugging and performance monitoring.

Researched Steps:

Step 1:

Set up a local environment following the documented instructions provided by Hyperswitch.
Generate publish and secret keys from the Hyperswitch dashboard.
Adjust environment variables to suit local requirements, including modifying the SERVER_URL.
Step 2:

Execute production builds to assess bundle size and network assets using npm commands such as npm run build:playground and npm run build:prod.
Serve the project locally by running node server.js and utilizing npm serve for client hosting.
Analyze the client-side application running on port 5252 for further debugging and optimization.
Step 3:

Examine the dependencies required by the client application, including "@juspay-tech/hyper-js", "@juspay-tech/hyperswitch-node", and "@juspay-tech/react-hyper-js".
Explore loading strategies such as loadHyper and HyperElements, noting their impact on performance and customization options.
Identify opportunities for server-side rendering (SSR) to improve initial load times and enhance user experience.
Step 4:

Optimize the client-side application using various techniques:
Implement lazy loading with prefetching to enhance resource loading efficiency.
Cache static API responses on the client-side to reduce redundant calls.
Refactor data-fetching logic using useCallback and appropriate dependencies.
Utilize styled-components for improved CSS management and code reusability.
Apply compression and minification to CSS, JavaScript, and image assets to reduce file sizes and improve load times.
Leverage useMemo() for efficient calculation handling.
Integrate TypeScript to enhance code safety and reduce bugs.
Implement development-time libraries like 'why-did-you-render' for performance optimization.
Address Potential Performance Bottlenecks:

Prioritize loading of critical resources to improve First Contentful Paint (FCP) and Largest Contentful Paint (LCP) metrics.

Enable browser caching and async loading of resources to enhance rendering speed.
Optimize JavaScript code through code splitting and reduction of DOM operations.
Implement text compression using Gzip to reduce network transfer times.
Minify JavaScript and CSS resources to improve load times and code efficiency.http://127.0.0.1:5500/hyperswitch-web/Hyperswitch-React-Demo-App/src/App.css
http://127.0.0.1:5500/hyperswitch-web/Hyperswitch-React-Demo-App/src/index.css
Conclusion:

By implementing the proposed strategies and optimizations, we aim to achieve a significant improvement in the render time of our application, thereby enhancing the user experience and ensuring seamless integration. Through diligent testing and monitoring using Chrome dev tools, we will continuously refine our approach to meet the defined objectives and deliver a high-performance application.

[7479519511]

well keep going!

[rahulsainlll]

Great approach ✨

[dhruv-bhardwaj]

Well Done

[Amit-0905]

great

[AmanPandey08]

well done

[omkarkulkarni2704]

I would like to work on this.

[itskishankumar]

why does it look like most people just Copy Pasted from ChatGPT lmao?