Optimising Google Apps Script Web Apps

This text is taken from a forum response on the Apps Script Google Group from Sandeep Kumar Vollala.

Key Reasons for Lag:

1. Client-Server Round Trip: Every call to google.script.run involves a network round trip between the client (browser) and the Apps Script server. This introduces inherent latency.
2. Apps Script Execution Overhead: Apps Script uses a shared infrastructure that isn’t optimized for low-latency responses, especially for small, frequent requests.
3. Script Deployment Environment: Scripts in the development mode (/dev) run slower than when published in a deployed state. This is because of additional logging and validation checks in the development mode.
4. Network Factors: Internet speed, geographic proximity to Google’s servers, and network congestion can all affect the perceived speed.

---

Optimization Suggestions:

Here are some ways to reduce or mitigate the lag:

1. Minimize the Number of Calls:

Batch Operations: Combine multiple operations into a single Apps Script call where possible. For example, instead of calling testServerFunction multiple times, you can pass an array of parameters and handle them all in one server-side function.

Caching Results: Cache frequently used data on the client side using localStorage, session variables, or custom caching mechanisms.

2. Optimize Deployment:

Publish as a Web App: Published web apps generally run faster than scripts accessed in /dev mode. Ensure the script is deployed using the “execute as the user accessing the web app” mode for better performance.

Use Simple Functions: If the function doesn’t require Apps Script features, consider handling it directly on the client side.

3. Asynchronous Design: Use asynchronous code on the client-side (as you’ve done with async/await). This ensures that other parts of your application remain responsive while waiting for the server call.

4. Reduce Payload: Keep the data sent between the client and server minimal. Avoid unnecessary data in parameters or responses.

5. Use a CDN for Static Resources: Offload the hosting of static resources (like CSS, JS) to a Content Delivery Network (CDN) to reduce initial load times.

---

Example: Improving Your Test Script

Here’s an updated you can try test script to measure performance more reliably and minimize unnecessary overhead:

Code.gs FILE:

const testServerFunction = (params) =>  params.map(param => `Server processed: ${param}`);

HTML FILE:

<script>
  async function testServerPerformance() {
    const iterations = 5;
    const results = [];
    const params = Array.from({ length: iterations }, (_, i) => `Test ${i + 1}`);
    const start = performance.now();
    try {
      await google.script.run
        .withSuccessHandler((response) => {
          const end = performance.now();
          const timeMs = end - start;
          console.log(`Batch call took ${timeMs.toFixed(2)}ms`, response);
        })
        .withFailureHandler((error) => {
          console.error("Error:", error);
        })
        .testServerFunction(params);
    } catch (error) {
      console.error("Error in test:", error);
    }
  }
  window.addEventListener("DOMContentLoaded", function () {
    testServerPerformance();
  });
</script>

---

Results and Expectations

1. Average Latency: In a published web app, expect latency to range between 400–1500ms for each google.script.run call, depending on payload and function complexity.
2. Batching: Sending multiple requests in a single call reduces the overhead and improves overall performance.
3. Published Environment: After publishing as a web app, you should see slightly better performance compared to the /dev mode.

---

If you still find the latency unacceptable, consider transitioning critical parts of your project to platforms like Firebase or using Google Cloud Functions for server-side processing. These options provide more control and lower latency compared to Google Apps Script.I hope it helps!!!