I've seen inconsistent load times for Google Apps Script gadgets on my Google Sites. There seem to be two visible phases to the gadget loading process - a "blank" period, and a period with a "loading" animation. Can anyone explain the relationship between these two phases? I suspect but have no way of knowing that my code does not begin to execute until the loading animation is complete. Is this true?
My scripts seem to perform relatively consistently once they reach the loading animation. I have reviewed the available documentation on optimizing performance for Google Apps Scripts, and I have been able to get reasonable load times for my requirements, but the gadget sometimes spends a long time - over 60 seconds - with no content prior to the loading animation appearing.
I have one page with three Google Apps Script gadgets on them, with three very different performance profiles. I am loading data from a spreadsheet in two of them, but I need to iterate through Google Contacts in another which takes quite a bit longer. It appears to me that once one of these scripts hits the "loading" animation, they all begin executing fairly quickly, but nothing I do as a developer influences the time prior to the loading animation.
Web browsers are single threaded when doing server calls in Javascript (or GAS) so it needs to complete all of your function calls to the server before it can return the values from the server and render your page. A workaround would be to create a simple button on the page to start your GAS processes then have a loading screen come up via a clienthandler when the button is pressed. The load screen will be visible as the processes are going on in the background and when you finally finish your processes, you can set the load screen (panel) visibility to false.
Not the most elegant solution, but your initial page will render quickly then you an set a panel (with an animated gif loading graphic if you prefer) to tell the user the page is loading.
Hope this helps!
Interesting question. But I'm afraid there's really nothing else that we can do.
Well, besides complaining with Google :)
I guess you should open an "Enhancement request" on the issue tracker.
Related
I have been putting out fires all day. Can't seem to make heads or tails of this error...
Today I started for the first time after months of using the same script. It is triggered when a new record is added to a google sheet.
It seems to work on and off but every few minutes I am getting a failure notice indicating "Service using too much computer time for one day".
Looking through the documentation and the post on Stack, it is clear I am not the first to deal with this issue, but there does not seem to be any concise answer to how to resolve. I looked for some way to reach some type of google assistance but am always directed back to stack overflow to submit my issue for consideration. Understand this could be an issue with my script, but cant seem to find what might be causing this issue. Also confusing the matter is that the script does seem to be firing 90% of the time.
My questions:
How do I check the "computer time" quota?
Should I turn off that script/trigger until 24 hours have passed?
Does anyone know how to get a hold of Google support directly?
I don't know of any way that the total script run time can be seen in a dashboard.
You can see duration times of individual script executions at:
https://script.google.com/home/executions
You could scroll through your executions to look for long durations times. That might indicate an endless loop in your code.
To calculate the total run time of all your running scripts, you'd need to use the Apps Script API.
https://developers.google.com/apps-script/api/how-tos/view-processes
https://developers.google.com/apps-script/api/concepts/processes
I don't have any code to list and compile all the durations.
If anyone does, that would be very interesting.
I don't know if deleting the trigger until the next day would gain you anything. I'm guessing that it shouldn't.
Google does not provide "on demand" support people to answer questions about Apps Script. Even G Suite customers don't get "on demand" support contacts for Apps Script. You can report bugs and request features through the Google Issue Tracker, but that won't get you direct contact with a Google support person. Even if you purchase a support plan, Google doesn't have people who are designated to support Apps Script. If you purchased a support plan, they might try to help you with an Apps Script question, but officially they aren't qualified to help, or obligated to provide Apps Script support. And even if a support person tries to help you with an Apps Script problem, the first thing they'll do is a search of Stack Overflow, and give you links to SO posts.
So, it's extremely unlikely that you're going to be able to talk with someone directly at Google.
The best thing to do is to review your code for performance issues. Avoid reading the writing data often. The ideal situation is to get all the data that you need just once, process it, and write it back once. Cache data if you can. Avoid lots of calls to Properties Service. Find what part of your code is taking the longest time, and try to improve it.
Preface: I am very new to programming. I am trying to make a google docs add-on that essentially records audio when the user hasn't been typing for some time (this is to allow the audio to be converted to speech later, its a "note taking helper" add on). Sorry if I am being vague, but I do not have much done on the project so I don't really have any code to show. If there is a way to do this using google apps script that would be preferable (ie javascript/html). Thanks for your help :)
Honestly, autohotkey is probably a better way to go. you could simply have a timer going that reset every time the user hit spacebar and after it hits 100 seconds it starts a recording app going.
I have been using navigation timing api to collect actual user data about my site performance. Basically, every time a user visits the site, I send this data back to server and store it in the db.
Now that I analyze this data, I am finding that domainLookupStart is abnormally high even when there are no redirects happening. On average, over 3 months of data, its as high as ~400ms. This is making up for majority of my "Time to first byte".
I was wondering if someone has a better understanding of what work happens before the browser fires the domainLookupStart navigation timing event. And is there something I can do to bring this time down?
It can sometimes be the unload event on the previous page. The unload event allow some JavaScript execution before the page is closed, and it's often used by tracking scripts to save the time spent on the page by users. I've even seen a script sending a synchronous ajax requests here!
It could be on your page or on a third party page that drives users to your website.
You can use Chrome DevTool's Performance tab (previously called "Timeline") to record what's going on during unload and maybe you'll find something.
I was testing a site which uses service worker,
I noticed that when clicked on the logo in the site, in Resource Tab in Chrome under Frames, scripts were getting duplicated. While it doesn't create any problems to the functionality, but i want to know whether this an issue?
Yes this is the issue, you should ask developer a reason for this.
If this keeps happening this will unnecessarily eat memory of end user, and will affect the performance.
I have an HTML5/jquery mobile web app at http://app.bluedot.mobi. It is used for long distance races to track competitors via SPOT satellite tracking. The issue I have not yet resolved is that when loading the app when no data connection exists, the browser throws a "no data connection" alert popup as it is attempting to fetch the manifest during the checking event. Even when a data connection is present, loading the app can take a very long time. There are ~ 500 files to check. The fastest way to load the app (from a phone) is to be in airplane mode and dismiss the browser's alert - not so elegant.
Rather than force an update on users who tend to be in the backcountry with a spotty connection, I want to use applicationCache.update() programmatically, giving the user control over the process and speeding up app load whether on or offline.
Is this currently possible with the HTML5 spec and respective browser implementations?
Sounds like you need the abort() method. Unfortunately it is very new, and it will probably be a while before it is implemented by the majority of mobile browsers.
There are ~ 500 files to check.
It sounds like you're implying that the browser checks each file to see if there's any of them which has changed. This is not correct. The browser only checks the manifest file if that has changed, and that is a simple byte check. If the manifest file has not changed, the browser believes nothing has changed.
So if your application is slow to start, it might be your because your application is complex and there's alot of HTML and Javascript to parse. I would advise you to take a look at the application and see if there's anything you can optimize. In that case, you might want to take a look at Yahoo's Best Practices for Speeding Up Your Web Site page.
For example, I noticed you have a lot of Javascript code in the HEAD section. The beforementioned article advices us to move all Javascript (To the extent of what's possible) to the bottom of the page, so that the browser can start rendering the page as soon as possible. And there's a lot of other sound advice in the article. So take a look, I'm sure you'll find it useful. :-)