Thanks for the test. The holes were set to cut first, which is why they were set to a different color from the squares.
When you say there was a lot of shaking, was that with a speed setting that you had used before that did not cause such a ruckus? Was the rapid shaking movement during the cut or the translation between cuts?
It was the head movement while travelling from cut to cut. We canāt do anything to affect that, itās something in their algorithm, but it looks like something impacted it somehow. Iāve never seen it before, and itās not doing it now on another file that Iām running, so I have to think thereās something in that particular file that it doesnāt like.
Itās just very odd. (And a puzzle.) 
Something weird in this file for sure. Maybe the Inkscape SVG step? I think it is recommended to use Plain SVG from inkscape. Not sure if thatās the problem though.
I opened the file in AI CC2018 and saw this,
Set it to a black stroke and no fill, saw this,
48 circles on top of each other in the upper left corner.
I erased the corner circles and the lower two rows of shapes, replicated the top row two times, and saved that back as an SVG.
I have an hour left on a three-hour engrave, which I will then have to flip for a second three-hour engrave on the back, so I wonāt be able to test my version until this evening. Feel free to try my version below in the meantime.
(I also added lines for the top row, so they would cut out completely as well, but made them a different color so that they could be ignored if they were left out for a specific reason.)
That is odd - I donāt get the 48 circles opening it in CS5. Something very funky going on.
I ran the original shared SVG file same as Jules without any edits other than scaling down to fit a piece of paper.
Had zero issues with it running.
Iām actually surprised how efficient the motion plan/head movement is on this one. Yes, it zips 'round those circles like a neurotic dog chasing its tail, but nothing out of the ordinary that I can see.
I shot a video which is currently uploading, itās got about 10 minutes to go so Iām gonna grab lunch and will share the vid once itās done. 
Consistancy, Consistency, Consistincy.
Iām laughing out loud watching thatā¦ yes, itās amazing the machine we have at out disposal but, what amused me most, was the number of times the head traveled across an uncut area that it could have just cut along the wayā¦
Nope! I could have sworn it had a different motion plan when I ran it, and it was rocketing around to get to the circles. It didnāt just follow along doing them all in a row like that.
Butā¦Iām seeing your plan now when I preview it.
Thatās itā¦Iāve finally slipped over the edge. 
Have anotherā¦ hicā¦ 
Insanity is doing the same exact thing twice and expecting the same results each time.
no, waitā¦
Thanks for reaching out. Iām sorry Iām so slow to respond.
Iām taking a look at this and will update the topic when I have more information.
Thanks for your patience. Iāve researched quite a bit and believe that your Glowforge is working properly. Iām moving this discussion to Beyond the Manual in case youād like to continue to talk about settings or other solutions.
So variable travel speed for identical objects (the circles) is normal? Some cuts are slow enough to cut all the way through the material and some speed up by various amounts, delivering variable amounts of cutting power to the material. For objects that are all the same color and in the same object grouping in the GFUI, this does not sound like expected behaviorā¦ can you provide more information on how to get consistent power delivered to the target material if all cut lines are in the same grouping?
Vee may not see your reply now that itās been moved to BtM. You may need to make a new post in Problems and Support. Have you run across a simpler file of circles that reproduces the different speeds? If so, that may help the quickly diagnose what is going on.
GF seems to use very low acceleration so it may well do small circles more slowly.
As some of the others have stated, my gut is that it was something with your file, or the cut settings causing the issue.
When you look at the picture the exact same holes arenāt cut in each of the three. The only way thatās going to happen is if itās in the file, or the settings set for the features/how the GFUI is interpreting the file.
IF it was an issue with the laser hardware, (alignment or power delivery) you would notice an issue on the left vs the right as the head changes distance from the 90* mirror.
Poke around and look into Cut Sequencing. For example: Increasing Cutting Efficiency
Itād be nice if the GF post-processor would figure this out on itsā own by default and give the option for User Override (relying on the user set path direction) perhaps they can āAdd it to the Hopper.ā
If there were two identical circles in the exact same place, it would travel around the circle 2x and thus cut all the way through more reliably? It is interesting that the laser isnāt modulated for sharp direction changes like a right angle moving from x-travel to y-travel. The mechanism for change of direction seems to necessitate the head slowing down then speeding back up but the laser score function over-burns in the tight corner during that transition. Itās definitely a software thingā¦
