DEV Community: Herat Dhruv

poEditor:- Workflow Automation

Herat Dhruv — Thu, 04 Sep 2025 06:27:55 +0000

Automation of PoEditor can save your lot of time

In my case, developers updated translations only in en.json since they lacked PoEditor access. New local translations had to be manually synced to PoEditor for stakeholders—a time-consuming and error-prone process.

Automation Details

// package.json
"update:translations:poeditor": "node ./locales/scripts/sync_translation.js",

Here is the list of API can be used , before using it you need to generate API token in poEditor using your login

// sync_translation.js
const LIST_TERMS_API = 'https://api.poeditor.com/v2/terms/list'
const ADD_TERMS_API = 'https://api.poeditor.com/v2/terms/add'
const UPDATE_TERMS_API = 'https://api.poeditor.com/v2/terms/update'
const UPDATE_TRANSLATIONS_API = 'https://api.poeditor.com/v2/translations/update'
const ADD_TRANSLATIONS_API = 'https://api.poeditor.com/v2/translations/add'

Here is my workflow for automation

const LANGUAGES = ['en'] // since all the developer updated the translation on local en.json file hence in my case i was targeting en.json as updated source / only source of truth.

// sync_translation.js
LANGUAGES.forEach(async (lang) => {
  await syncTranslations(lang)
})

Workflow Automation

Fetch translations from PoEditor.
Compare with en.json.
Log updates in a local backup file.
Add new terms to PoEditor via API with web reference.
Tag updated terms so stakeholders can easily review and update.

For automation we can use reference or context of poEditor

How Tagging will help everyone to filter terms based on certain criteria

Background
In my case, I was surprised by how much time my team spent managing locale files from poEditor. Every update required a manual process before sharing with stakeholders:

Download the locale file from poEditor
Sort translations using a third-party tool
Compare poEditor files with the repository (since devs also updated translations directly)
Merge changes between poEditor’s JSON and the repo’s JSON
Update the repository with the final merged file

This repetitive workflow made a simple task unnecessarily time-consuming.

This manual process took 2–4 days, demanded heavy focus, and often led to procrastination in pushing translations to production. As a result, it created a poor impression with operations and management—prompting me to pursue automation.

Conclusion

Within a couple of minutes, we can able upload the latest translation on poEditor. This saves time and efforts both.
Stakeholders also aware about what they needs to be updated by using tagged filter.

How did i choose e2e automation framework 🩺 for my ongoing web porject

Herat Dhruv — Sat, 04 Jan 2025 07:52:46 +0000

This page covers intention and approach to implement e2e automation framework in your ongoing project

Motivation
Approach for Selecting e2e framework
Cypress Vs Playwright POC Outcomes
Summary

Let's end Cypress vs Playwright , it will be obvious outcome once your requirements are clear

My Motivation for Implementing E2E Testing

As a web developer, my goal is to deliver changes to production as quickly as possible to evaluate their impact on end users. However, ensuring quality is crucial—I don’t want to release buggy updates. While I do write unit tests, their effectiveness often depends on tight feature deadlines, and they are limited to testing individual modules.

Currently, we rely on the QA team to manually perform end-to-end (E2E) and smoke testing in lower environments like UAT. However, when there’s a strict deadline for high-priority features, I often need to wait for QA resources to become available. This delays feedback and makes the process less efficient.

To address this, I discussed the situation with senior team members and began working on a proof of concept (POC) for implementing automated E2E test cases.

Key Considerations:

Budget and cost implications of the automation framework and CI/CD runners.
Maintaining the speed and efficiency of the CI/CD pipeline.
Most importantly, ensuring that the QA team supports writing and maintaining test cases in the future.

This approach aims to reduce dependency on manual testing, speed up feedback loops, and improve overall productivity.

Breaking Down My Approach

Research on Popular Frameworks and Their Costs

I focused on identifying frameworks that meet the following criteria:

Strong Community Support: To ensure availability of resources, troubleshooting help, and ongoing updates. Built-in Browser Support: Should include major browsers out of the box.
Reliability: Minimal flakiness to make the CI/CD pipeline more dependable. Support for Parallel Execution: To speed up testing and enable faster rollouts.
Debugging Features: Provides videos, screenshots, and analytical reports for quick debugging of failed or flaky E2E test cases. Third-Party Integration: Easily extendable to third-party providers for comprehensive testing on various devices, operating systems, and reporting capabilities.

Performing a Proof of Concept (POC)

Based on the research, I shortlisted two frameworks: Cypress and Playwright. Other frameworks fell short due to their limitations:

Puppeteer: Lacks extensive built-in browser support, is less reliable, and has weaker community support compared to Cypress and Playwright. It also lacks native support for parallel execution.
Selenium: Although robust, it has a steeper learning curve and requires significant effort for initial setup and parallel execution, making it less efficient compared to the alternatives.

POC Outcomes

The analytical results of the POC highlight the strengths and weaknesses of the shortlisted frameworks and guide the decision for the most suitable E2E testing solution.

Summary

Based on the analysis above, there are significantly more negative outcomes (indicated by reds) with Cypress compared to Playwright. As a result, I chose Playwright as our E2E testing framework, tailored to meet our specific requirements.

One standout feature of Playwright is its native E2E code generation tool, which is a game-changer. This makes it incredibly easy for our QA team to generate E2E tests and integrate them into the production pipeline with minimal modifications. This reduces the learning curve for the QA team and fosters better collaboration between QA and developers—a true win-win situation.

While our QA team continues to play a vital role, adopting Playwright has significantly improved the reliability of our tests and the speed of rollouts in the production pipeline.

Respond to the interview question about React performance optimization. 🚀

Herat Dhruv — Mon, 21 Oct 2024 11:16:12 +0000

I have been involved in conducting and participating in React frontend interviews many times over recent years.

One observation I’ve made is that interviewers often ask about your experience with performance optimization. However, many candidates make the mistake of only discussing code-based optimizations, while interviewers are actually looking for your broader experience as a web developer, not just a React or framework-specific developer.

Consider performance optimization as a system design question and provide a holistic answer based on your web development expertise. I'll share with you the best possible response based on my experience, so you can be well-prepared if you're asked this in an interview. If you deliver the following points effectively, the interviewer will view you as a strong candidate for frontend or web development roles.

Let's break this answer down into six key segments:

👨🏻‍💻 Code Performance Optimization
🌎 Network / API Layer Performance Optimization
🌐⛁ Caching / CDN
🗄️ Server Optimization
🛠️ Tools to Use
📊 Metrics to Follow

1. Code Performance Optimization

Here, we can discuss coding techniques that can improve performance. For example:

Hooks like useCallback, useMemo, and React.memo can provide caching mechanisms. However, we should be cautious not to overuse them, as this can negatively impact performance.
Techniques like React.lazy and Suspense can definitely improve performance by reducing the size of the main chunk, allowing for lazy loading.
Lazy loading images on a webpage can help the HTML load faster in the browser.
Pagination can also reduce the page size, thus improving performance.
Using tools like Webpack/Vite bundle analyzers can be useful in identifying heavy JS files, allowing us to reduce the file size on initial load.Resource

2. Network / API Layer Performance Optimization

When navigating through the code, you should identify:
Which API is "costly" or heavy (e.g., if the response is more than 9-10 MB). Such an API needs optimization.
Which API is slow—consider adding server-side caching with tools like Redis or Memcached to get responses faster.
For example, if your product API response is too large and causes loading delays, this is unacceptable. You can reduce the response size by using pagination or lazy loading images.
A good practice would be to only send necessary data. For instance, in a "favourites" API, sending just the product_id to mark a product as a favourite is more efficient than sending the entire product object with all its properties.
Using GraphQL can also help adjust response sizes dynamically based on your needs.

3. Caching / CDN

As a frontend developer, we often serve assets like CSS, images, audio, or video, which can increase HTML page size and increase network retrieval times.
Rather than fetching these assets directly from the server, it’s always better to retrieve them via a CDN (Content Delivery Network), which can be provided by services like AWS, GCP, and other major players.

4. Server Optimization

React renders pages on the client side (i.e., in the browser), which uses client resources like CPU, processor, and network. While this may not be a big issue for desktop users, mobile users often have less computational power and slower network connections.
To improve performance for mobile users, Server-Side Rendering (SSR) can be a good solution. This allows major tasks like data fetching and HTML page generation to happen server-side, so the browser doesn’t have to wait for JavaScript files to load before rendering the HTML.
Other techniques include database optimization and applying ASG (Auto Scaling Group) policies on servers using load balancers during peak hours to distribute the load, enhancing web performance.

5. Tools to Use

Here are some tools you can use to analyze and enhance your website’s performance:

Lighthouse
Sitespeed
Pagespeed Insights
Webpage Test

These tools generate reports that provide actionable insights for improving the performance score of your website.

6. Metrics to Follow

Performance metrics to focus on include:

FCP (First Contentful Paint)
LCP (Largest Contentful Paint)
CLS (Cumulative Layout Shift)

It’s important to note that LCP, CLS, and TBT (Total Blocking Time) carry significant weight in performance scoring. Prioritize optimizing these metrics to eliminate performance bottlenecks on your site.

Here’s how the weightage typically breaks down:

Metrics	Weights
Largest Contentful Paint (LCP)	25%
Total Blocking Time (TBT)	30%
Cumulative Layout Shift (CLS)	25%

Please make sure to cover all of these points, as each one holds weight in showcasing your overall experience.

Feel free to share your comments and feedback!

is it necessary to use lazy 😴 and suspense 🕵 everywhere in the repo? 👨‍💻 this could cause CLS 📊 issue in web performance.

Herat Dhruv — Thu, 03 Oct 2024 18:21:35 +0000

Recently i am working on web performance optimisation in my new organization. where i found one of the classic case which was causing a performance issue and impacting CLS webvital metric.

Due to which i am excited to share this with you guys. So everyone should get benefited using this way of approaching a problem.

One of the classic example when react suspense will no use.

Parent component

fetching data for child component lets say carousel
passing carousel list to carousel component

Child component [Carousel component]

display placeholder
display list of carousel
in case of no data it should not display placeholder as well as list of carousel and return null

// Pseudocode
import { lazy } from "react";
const CarouselComponent = lazy(() => import("../pages/CarouselComponent"));

function ParentComponent(){

const {carouselData} = getCarousel();// carousel data fetching hook

return (
   <Suspense fallback={<CarouselPlaceholder />}>
    <CarouselComponent carouselData={carouselData}>
   </Suspense>
)};

function CarouselComponent({carouselData}){
// undefined can be received from API
if(!carouselData) return null; 

return (
  {carouselData.length > 0? <CarouselList /> : <CarouselPlaceholder />})
}

What could be wrong in the above code?

Fallback will not work CarouselComponent is wrapped with Suspense but CarouselComponent does not have any promises inside it due to which fallback ie. <CarouselPlaceholder /> will never work.

by the time carouselData is undefined or null the component will not render anything. and once the data is available it will render component with data. This will sudden shift in layout.

This problem will introduce a CLS issue in your web application.

for such a small file of CarouselComponent, which was not more than 2Kb gzip file it is necessary to use Lazy for code splitting? IMO we should not.

please fill free to share your experience for such a weird issues while dealing with web performance.

How did i approached for web performance optimisation at my new workplace 🚀

Herat Dhruv — Fri, 13 Sep 2024 10:13:29 +0000

Have you used React.Lazy and suspense but still not able to boost performance of your website in mobile devices.....Than.you are on right page to move forward

The purpose of this page is to offer more advice on how to handle the problem of performance optimization for production websites.

It appears that you attempted to divide the bundle chunks on the react production website using `React.lazy} and `suspense} in React; however, this did not result in the anticipated improvement in your web performance score.

But why is it the case that lazy and suspense is not improving performance as expected for Mobile devices in 3G and 4G network Speed?

Given that something extra was needed for your production website.....

I was recently assigned a task to enhance the performance 🚀 of the production website for mobile users 📱. I initially thought 🤔 that we should load each route more lazily...💤💤💤, but I soon realised that this had already been done.

I had also begun to wonder ✨ what might come next.

First thing first that please install bundle analyzer plugin to give complete picture of bundles in repository.

In my case it was webpack bundle anlyzer(https://www.npmjs.com/package/webpack-bundle-analyzer) and i installed it to existing project `` plugin and attempted to analyze each piece after that. Following that, I had a lot of suggestions about how to enhance the performance.

What needs to be analyze once you install webpack bundle analyzer

analyze all the larger bundles
- in my case main.js bundle was too large around 6 MB of Gzip size
analyze any duplication of bundle is there or not?
- for me it was lodash.clonedeep and lodash both were available in main.js
Are your vendor and polyfill package / chunks are separate? if not try to make it as separate chunks

Main.bundle.js
main bundle size was too big [around 6-7 MB Gzip] which is causing increasing downloading time along with parsing time.

That means in browser, js main thread was too busy in downloading and parsing the main js file. now i am started thinking about offloading some work from main thread so one obvious approach is that we should reduce main bundle size.

How to break the main bundle js file?

in my case mine main bundle has lot of json files, which is related to translations / localization which was increasing 1.5 MB of main bundle size.

Now, I did took away translations using lazy import from main.js bundle. This gives 40% performance score optimisation 🚀. but this not done yet since we hardly reached from lighthouse performance score 25 to 35 only.

then i started looking 👀 at other potential big files.

One of them is moment js, which has numerous locales json files. not all of those locales was used in our website. due to which we thought of replacing moment js with a lightweight library, but doing so will require more code modifications and increase my workload in testing the entire website and lead to more errors.

fortunately, a webpack plugin was already available. I was able to minimize the size of the moment.js file by utilizing that plugin [[ContextReplacementPlugin](https://webpack.js.org/plugins/context-replacement-plugin/ )]. this plugin removed a lot of unnecessary locales json files from final bundle. this reduce bundle gzip size by 0.5 MB

Reference Resources:

Stay tuned many more will about to come... Thank you

NX Playwright integration as a package in mono repo

Herat Dhruv — Thu, 01 Aug 2024 19:22:40 +0000

This post is intended for people who are having trouble integrating Playwright e2e as a separate package within the NX mono repository.

Naturally, one way to handle this is to have a playwright in its own package and package.json file and node_modules inside that specific folder, but doing so eliminates the node_modules centralization within a mono repository. ... a few more benefits that the NX mono repository offers.

Version

NX <= 17
Playwright <= 1.45

Context

NX provide a plugin called as @nx/playwright using it commands we can create a e2e app automatically, unfortunately This is not a case for NX-17

Here is the solution which worked for me

Setting up playwright E2E as NX mono repo package
We took the following actions to integrate playwright as an NX package because the @nx/playwright plugin, which is available to set the e2e folder within an NX mono repository, did not function well with the way the project was currently built up.

Final Folder structure : /apps/<e2e-package-name>

STEP -1 Run command below commands

npm install playwright --save-dev
npx playwright install
npm i -D @playwright/test

STEP -2 create a folder and files

create a folder apps/<e2e-package-name>
create apps/<e2e-package-name>/tests folder and add below file as example.spec.ts

import { test, expect } from '@playwright/test';

test('page has title', async ({ page }) => {
  await page.goto('http://goolee.com');
  await expect(page).toHaveTitle(/Google/);
});

create <e2e-package-name>/playwright.config.ts

import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  testDir: './tests', // Directory for test files
  fullyParallel: true,
  projects: [
    {
      name: 'chromium',
      use: { ...devices['Desktop Chrome'] },
    },
    {
      name: 'firefox',
      use: { ...devices['Desktop Firefox'] },
    },
    {
      name: 'webkit',
      use: { ...devices['Desktop Safari'] },
    },
  ],
//  webServer: {
//    command: 'npx nx serve my-app', // Command to start the app
//    url: 'http://localhost:8765',
//    timeout: 120 * 1000,
//    reuseExistingServer: !process.env.CI,
//  },
});

STEP -3 setup command to execute

create a <e2e-package-name>/project.json

{
    "name": "`<e2e-package-name>`",
    "root": "apps/`<e2e-package-name>`",
    "sourceRoot": "apps/`<e2e-package-name>`/src",
    "projectType": "application",
    "targets": {
      "e2e": {
        "executor": "nx:run-commands",
        "options": {
          "command": "npx playwright test",
          "forwardAllArgs": true
        }
      }
    }
  }

STEP - 4 Run the command to execute e2e from Root directory

npx nx run :e2e OR
npx nx run :e2e --headed

Please note

Replace the URL in example.spec.ts it will work on local / eternal website.
Also replace <e2e-package-name> with your package name to make all the step executable.