TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Why is the Google Cloud UI so slow?

492 pointsby mostlystaticover 4 years ago

71 comments

shadowgovtover 4 years ago
There&#x27;s a meta-answer, which is Google is shipping its org chart.<p>Google Cloud UI is one giant Angular app with components written by sub-teams across wildly disparate timezones, much less offices. Their ability to consolidate resources is poor. They came late-to-the-game on tooling up an infrastructure team to provide both standardized libraries and rigor on how the architecture is used. The duplication of component logic is a direct consequence of this, as those components are ending up in the codebase as a side-effect of different segments of code, worked on by different teams, probably in different offices, &quot;reusing&quot; the same component---but not really, since they might be skewed on the version they&#x27;re depending on. It&#x27;s DLL hell in Javascript client form, basically.<p>And the product as a whole is chasing feature parity, not speed of UI.<p>The simplest way to not end up like Google Cloud UI is to not try to build a whole-product cloud solution. The second simplest way, if you&#x27;re Amazon and you&#x27;ve already gone that road, is to have different sub-parts of your mega-architecture be different &quot;apps&quot; (really, different websites), each of which need pull in only the pieces it cares about, and be willing to take a whole-page refresh when the user transitions from one page to another.
评论 #25363811 未加载
评论 #25362939 未加载
评论 #25361965 未加载
评论 #25362532 未加载
评论 #25362302 未加载
评论 #25367086 未加载
评论 #25361770 未加载
评论 #25361643 未加载
评论 #25362975 未加载
评论 #25366961 未加载
评论 #25363403 未加载
pradnover 4 years ago
Googler who doesn&#x27;t work in front end here, so take my opinion with a grain of salt:<p>1) A &quot;footsoldier&quot; dev has no choice in frameworks, and heavy frameworks with heavy reusable components are the norm. Frameworks are used to improve dev velocity and ensure consistency among the 100 teams that contribute to the web UI.<p>2) Devs care about performance but might not have time to do much about it given competing priorities. Cloud is a fast-moving area, so new features are being added all the time. Even if they want to improve performance, they&#x27;re limited by the frameworks you have to use.<p>3) For folks that are saying Google controls the browser, framework, and component library, and so should be able to do better than this, you are right. But the different divisions don&#x27;t talk to each other as much as you&#x27;d think. Why should they? Angular devs shouldn&#x27;t get special access compared to React, no? Whether this is an organizational failure or an enforcement of separation of concerns is up to you. I imagine critics will complain if Chrome did something special for Google properties, and they&#x27;d be justified.
评论 #25362907 未加载
评论 #25360595 未加载
_Microftover 4 years ago
<i>User to Dev: the memory usage is excessive. Dev with 256 GB RAM to User: WFM</i><p>I would not be surprised if a lot of these problems could be traced back to developers having above-average network connections and super beefy computers. Combine that with fresh or minimal installs while testing the software, without lots of data that accumulated over month or years of use and in consequence they experience their products as super snappy.<p>Summary: they maybe never experience their products as a normal user would.
评论 #25358706 未加载
评论 #25358786 未加载
评论 #25358752 未加载
评论 #25359252 未加载
评论 #25360700 未加载
评论 #25358743 未加载
评论 #25358670 未加载
评论 #25359777 未加载
评论 #25358733 未加载
评论 #25358859 未加载
评论 #25365367 未加载
评论 #25359853 未加载
评论 #25359656 未加载
评论 #25361398 未加载
GhostVIIover 4 years ago
Google&#x27;s UI&#x27;s in general are shockingly slow. I don&#x27;t understand why my Google Drive and Gmail have input lag and choppy animations on my 5 year old xps13, it&#x27;s not that hard to make navigating a filesystem or list of emails fast. Actually I do understand, it&#x27;s because they want everything they build to be made in a massive javascript framework with shared components, which looks nice but runs like garbage on anything not modern.
评论 #25359162 未加载
评论 #25359967 未加载
评论 #25359071 未加载
评论 #25360204 未加载
brundolfover 4 years ago
Here&#x27;s an anecdote: my partner used to work at PayPal, and they had a <i>entire team</i> dedicated to just the &quot;wallet&quot; portion of the web UI. There were reasons for this: that piece of the UI had to work in all nationalities, for all languages and currencies, in every browser on every device under the sun.<p>But here&#x27;s what I&#x27;m thinking: I wouldn&#x27;t be surprised if every single tab in the Google Cloud UI had its own team, with their own practices, dependencies, resources that need to be loaded, etc. And I wouldn&#x27;t be surprised if there&#x27;s nobody in the organization whose job it is to consider the Google Cloud Dashboard as a whole product, in terms of making it a cohesive experience, eliminating redundancies between independent pieces, doing cross-cutting optimizations, getting everybody on the same page. Given how many different things are stuffed into the interface (just look at the navigation menu), that would certainly lead to some bloat.
评论 #25360979 未加载
dochtmanover 4 years ago
My pet peeve is that a lot of the GCP console doesn&#x27;t even seem to work in Firefox. For example:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;webcompat&#x2F;web-bugs&#x2F;issues&#x2F;61522" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;webcompat&#x2F;web-bugs&#x2F;issues&#x2F;61522</a>
评论 #25359066 未加载
评论 #25360916 未加载
评论 #25366038 未加载
评论 #25359633 未加载
chubotover 4 years ago
The real answer is that Google&#x27;s promotion and hiring processes don&#x27;t respect front end developers. Systems programming and distributed systems are considered &quot;hard&quot; and worthy of reward. This explains why Google&#x27;s front ends are bad, and it also explains why there&#x27;s a proliferation of non-composable distributed systems inside Google. As a second order effect, the design of those back ends also make it harder to make fast front ends.<p>And front end devs are often using tools designed for back end devs, like the Bazel build system. (Compare that to FB having online &#x2F; incremental compilers for Hack, as far as I understand.)<p>So they either don&#x27;t get the best people working on front ends, or the people they have aren&#x27;t doing their best work because they&#x27;re looking to move into a role that may be more respected or rewarded.<p>Before 2005, Google built two of the most innovative AJAX apps ever: GMail and Maps. People may not remember how awesome they were. When GMail came out, it was faster than Microsoft Outlook on desktop, which I was using at the time. You would click and your message would appear instantly, which was not true of desktop apps. The app startup time was also better than desktop! (i.e. seeing all your messages from a cold start)<p>When Maps came out, people didn&#x27;t believe that the scrolling and zooming could be done without a Flash app. It also had incredibly low latency.<p>But somewhere along the way the company lost its leadership and expertise in the web front end, which I find very sad. (I worked there for many years, but not on front ends.) The slow Google+ app circa 2011 was a great example of that, although I believe the structural problem had set in before that project.<p>I don&#x27;t think there&#x27;s any question that FB and even MS are significantly more accomplished in these areas. They&#x27;re the &quot;thought leaders&quot; (React, Reason, TypeScript, etc.)<p>---<p>edit: Also, if you want to remember what Google UI looked like circa 2005, look at sourcehut: <a href="https:&#x2F;&#x2F;man.sr.ht&#x2F;" rel="nofollow">https:&#x2F;&#x2F;man.sr.ht&#x2F;</a><p>It was fast, simple, and had a minimalist style (though some people mistake that for no style). There is probably a generation of people who are scratching their heads at that claim, but yes that&#x27;s pretty much what Google used to look like: the home page, which lacked JS; News; Groups; Webmaster Tools; Ads front end to some extent, etc.
评论 #25362677 未加载
评论 #25362453 未加载
评论 #25365009 未加载
评论 #25362446 未加载
solarkraftover 4 years ago
Many people here seem to think this is due to incompetence, I don&#x27;t. It&#x27;s due to a lack of focus on speed as an indicator of quality.<p>I think Google devs are perfectly capable of building fast frontends, maybe they even want to, but if they&#x27;re not rewarded for it (but are rewarded for &quot;getting things done&quot;) they won&#x27;t.<p>It&#x27;s management&#x27;s fault.
评论 #25362159 未加载
评论 #25362182 未加载
geekster777over 4 years ago
Former front-end dev of this UI here. This article makes the assumption that Google&#x27;s primary goal is performance&#x2F;page load. It&#x27;s not. Feature parity and dev speed is. With a gigantic app like Cloud with hundreds of developers, there are massive technical hurdles surrounding things like independent releases, split bundles, and technical debt.<p>Google&#x27;s business model for Cloud is b2b. The bottom line for getting b2b contracts normally comes down to requested features (among other things). Page load time doesn&#x27;t factor as much comparatively, so these priorities do make sense. Not to say performance isn&#x27;t on everyone&#x27;s roadmap, but Google has and will continue to make strategic decisions that sacrifice performance over things like dev speed.
评论 #25368898 未加载
pimlottcover 4 years ago
The G Suite (now Google Workplace) admin console GUI is also pretty slow. What makes it worse is that you have no other choice - it&#x27;s the only complete tool for administrating G Suite. There are APIs for some things, but quite a lot is only available in the GUI, and new features always show up there first (if they ever make it to the API at all).<p>There isn&#x27;t even a way to import&#x2F;export settings, so you have to painstakingly document everything and reconfigure it manually if you need to create a new instance. It makes things pretty painful from a compliance point of view.
评论 #25362299 未加载
评论 #25360832 未加载
graderjsover 4 years ago
The medium is the message. In some domains, slow and clunky feels like gravitas and reliability. Enterprise software. Enterprise <i>recruiting</i> software. AWS has a pretty slow, and clunky dashboard. AdSense is clunky. A lot of the biggest companies&#x27; flagship apps have a very bland &quot;bureaucratic&quot; look and feel. You may find it hard to believe, but Zuck wanted facebook to look like a government database for a long time, where you type in someone&#x27;s name and see details about them. Engineers will probably scoff at these notions, because it seems to suggest that underlying their &quot;real&quot; engineering concerns, are implicit aesthetics they would neither say they agree with nor be aware of, but it&#x27;s real. If you&#x27;re deep in the medium, maybe you don&#x27;t even see it as a medium anymore, and you don&#x27;t realize its quirks.
评论 #25359112 未加载
评论 #25362355 未加载
评论 #25359838 未加载
hobbescotchover 4 years ago
It’s a real pain how slow it is. I’ve resorted to adding quick links to my bookmark bar for GCP products that I use often to get around the slowness.
评论 #25358787 未加载
dubover 4 years ago
Google Cloud wanted to &quot;eat its own dogfood&quot;, so they originally built the console with Angular v1 and App Engine instead of using more scalable and mature frameworks that would typically be used for those kinds of products within Google.<p>App Engine didn&#x27;t support chunked transfer encoding so progressive data loading becomes impossible, and Angular v1 is a pathological performance and maintenance nightmare to the point where AngularJS &#x2F; Angular v2 ended up being an incompatible rewrite.<p>The problem is, if you have hundreds of people contributing to a tool with deadlines to meet and lots of UI components you need an incremental approach if there&#x27;s going to be any hope of replacing the whole architecture. Without an incremental path forward, rearchitecting is dead in the water. Management isn&#x27;t going to want hundreds of people stop working on new features for months while the whole UI gets written from scratch.
评论 #25366547 未加载
rubyist5evaover 4 years ago
One thing that I&#x27;ve started doing for my own personal projects is deliberately working on underpowered hardware. I got a Rasberry PI 400 and that seems to be the perfect dev environment for me. It also has the side effect of making me much more conscious of the technology and dependencies that I use to create a product with.<p>I use my own beefy server for creating builds and have a decent dev-build-test setup for myself where the dev experience is still pretty fast despite the hardware I&#x27;m using as a client - but when it comes to actually testing out my work I love using it on the PI because I know that most users will have an experience very similar to what I get on the PI.
luordover 4 years ago
Knowing that the target audience for this is developers (for the most part), the decision to make it a javascript application in the first place instead of rendering from the server seems like overkill, at least IMO.<p>Maybe it&#x27;s just me, but I don&#x27;t really care about fewer page reloads or having multiple animations and interactivity. I understand why those can have an impact on end users and so I do think that SPAs have their place, but I&#x27;d much rather the interface was rendered from the server and worked through links if it means it&#x27;ll work faster. In fact, half the time I&#x27;m not even using the web interface; I&#x27;m using the SDKs.
评论 #25365640 未加载
dvhover 4 years ago
In Google play developer console there is simple table with list of apps and installs count. The cells are 34 levels deep in the DOM. Insane.
neyaover 4 years ago
Blame the new hipster driven development with Javascript where it&#x27;s ok to shove down a 100s of mb worth of assets into your user&#x27;s browser whether they consent to it or not, all because you can load some fancy animations and write a blog post on your cool new JS stack.<p>An average react JS app built using create react app actually costs you in megabytes, not kilobytes, which has somehow become the new normal.<p>But hey, I&#x27;m not complaining. I make money turning these slow sites fast by bringing them down to a 50-100kb total. Not complaining!
runawaybottleover 4 years ago
I’ll just say as a meta comment that this thread is some of the most beginning-to-end Google frontend development ingenuity and organizational imperatives bashing I’ve ever read here.<p>There’s not a single poster here that didn’t throw a rock.<p>In defense of large orgs, faangs and non faangs, from my experience I can tell you that some talented developers on teams will notice exactly what is wrong with a product (frontend or backend). They might know parts of the UI need to be trimmed and made performant, api calls need to be restructured to be made performant, and so on, but don’t speak up.<p>There’s a variety of reasons here and it mostly has to do with the old adage ‘no good deed goes unpunished’. On teams there are egos, and you will bring out unwanted peer pushback (who do you think you are with your fancy ideas all the time, you don’t think the rest of us thought of this too?) when you take up some of these mantles. This is a dynamic that is coupled with general management issues that come from the product&#x2F;project management, where your great idea might not be seen as worthwhile. On a team, socially and professionally, it’s better to not rock the boat here because the reward is not fair, and if it were outsized, it could be taken bad by coworkers as grandstanding.<p>Why bother? Which leads to the manifestation of the phenomenon: death-by-a-thousand-cuts. This is where professionally team members look like people with a self absorbed agenda. Now no one ever takes up reducing the bleeding, and finally, a world class company, with world class talent, builds laughably bad end results.<p>The only solution to this is for the egos to restructure the direction of their energy into a monomaniacal focus on ‘the final product is all there is’, where a good idea is a good idea. The ego has to be abstracted into the final output, where everyone involved derives their self worth from how good the thing they shipped is, and nothing else matters.
picodguyoover 4 years ago
Maybe they tapped the same developers who built the Google Ads web app, a UI so slow they have time to display tutorials while everything loads.
评论 #25359405 未加载
madroxover 4 years ago
This is a hard problem for any sufficiently large application...web or otherwise. Solving it, in my experience, requires a strongly supported central body focused on managing code quality across teams. I know this is a relatively straightforward exercise with large React apps. I&#x27;ve never seen it done with Angular to know how difficult that is. Doing this all comes with a cost of maintaining that team and possibly slower development, of course.<p>However, I assert that no cloud provider has won or lost significant cloud deals based on the speed of their UI, and most engineers who live in the cloud do so through CLI tools. While people may not like it, and perhaps it&#x27;s caused some engineers to do something different for personal projects, this is rightly not a KPI for Google Cloud, hence the state of of the cloud console.
endymi0nover 4 years ago
Playing the devil’s advocate here, I think it‘s just very hard to build a dashboard for this scale of resources, services and users that‘s all of very (!) secure, flexible (as in terms of policies) as well as fast.<p>Having had to use the Microsoft Admin dashboard for creating five new PowerBI users (which took me the better part of an hour), going back to Google‘s Cloud Console felt like a godsend of UX, Comfort, Sensibility and Speed.
dabeeeensterover 4 years ago
When you start implementing a <i>second</i> loading spinner. That&#x27;s the time to stop and think about what you&#x27;re doing. Surely.
评论 #25359832 未加载
ape4over 4 years ago
And of course, Google gives demerit points to websites that load slowly. (Or whatever they are called)
评论 #25360182 未加载
cpcallenover 4 years ago
I think the big-picture answer is that they held a &quot;Latency Code Yellow&quot; back in ca. 2007, and apparently stopped inculcating the same latency-sensitivity in people hired since that finished a year or so later.
Fiveplusover 4 years ago
Can a googler chime in to explain why Gmail is so slow at loading even on the most robust PCs with high speed internet?
评论 #25358885 未加载
评论 #25359107 未加载
landerwustover 4 years ago
Yikes, didn&#x27;t realize they had the indecency to drink their own kool-aid. Angular, really? No wonder! Come to think of it, it&#x27;s maybe been around a year since I last saw one of those tell-tale &quot;page finishes loading to a blank page for 20 seconds before finally rendering&quot; Angular sites
评论 #25363069 未加载
cube00over 4 years ago
The way my machine fan fires up when I use it I just assumed I was mining bitcoins to help offset my bill.
msoadover 4 years ago
I used to work on Google Cloud UI. Short answer is: Google Cloud org is very unlike Google. It&#x27;s more like IBM or Oracle. A lot of managers and engineers are from those companies.
leesalminenover 4 years ago
I spent a couple years on a 5&#x2F;2 mbps connection and GCP console was always the slowest thing to load out. 15MB of JS is crazy.
jeffbeeover 4 years ago
Perfect counterexample for the person who was telling me that single-threaded performance isn&#x27;t visible to users any more. On the M1 mac mini the Google Cloud console is fully loaded in 5.1s (2.6s when cached), not 8.1s. As an enthusiast of software efficiency I don&#x27;t think either of these is great, and there&#x27;s obviously a lot they can do to make it faster, but it just shows how users still greatly benefit from throwing hardware at the problem.
option_greekover 4 years ago
I guess stuff like amp is good only to preach others. This garbage has been slow for ages. Also they keep throwing links to new stuff in their side bar without any rhyme or rhythm making navigation as annoying as possible.
评论 #25370719 未加载
kordlessagainover 4 years ago
In Firefox, <a href="https:&#x2F;&#x2F;console.cloud.google.com&#x2F;compute&#x2F;instances" rel="nofollow">https:&#x2F;&#x2F;console.cloud.google.com&#x2F;compute&#x2F;instances</a> never loads.
pabl0rgover 4 years ago
Meanwhile AWS uses google’s GWT to great effect
评论 #25359324 未加载
评论 #25358677 未加载
评论 #25361225 未加载
评论 #25358685 未加载
评论 #25358624 未加载
apiover 4 years ago
Atlassian Jira is dog slow too. Drives me nuts.
评论 #25358526 未加载
评论 #25358763 未加载
asquabventuredover 4 years ago
youtube is the same slowwwwwwwwwwwwwwww loading experience, it really shows when you try to use it on an underpowered chromebook.<p>It&#x27;s strange to me that google devs don&#x27;t dogfood their own google branded products! They just assume everyone is using the same dev workstation they are?
makecheckover 4 years ago
I continue to advocate for <i>hard</i> download limits on the browser side that can only be overridden by scary user prompts. The defaults can be slightly larger for pages classified as “apps”, or certain file formats (e.g. when a link’s purpose is to download an entire app) but generally pages should be constrained to sizes on the order of <i>kilobytes</i>.<p>As long as the floodgates can simply stay open and pages can download whatever they want, coders will remain lazy. This isn’t surprising at all.
raszover 4 years ago
&gt;JavaScript 15.7 MB<p>Some time ago Google moved away from rendering pages server side. Youtube right now downloads 1MB of mostly json packed data for client side rendering. Irony of this is old Youtube layout (pre Polymer, their client side YT rendering engine) downloaded ~30KB of pre rendered html. The difference to users is Youtube website visibly slowly appearing in front of your eyes (while one CPU core is pegged at 100%) instead of Old YT just loading instantly and working.
dijitover 4 years ago
The gcloud command line is also abysmally slow.<p>The memory usage of the webpage often exceeds 1GiB.<p>But otherwise the platform is good. So I suffer through.<p>But I agree it’s annoying.
turtlebitsover 4 years ago
The AWS console isn&#x27;t fast either (just shy of 1 MB of data transferred). I chalk it up to -<p>1. So many services all living in the same place with a variety of UI components 2. The complexity of turning all the knobs and dials of building infrastructure (or multiple pieces) into a UI. 3. Being an ancillary service (admin UI).
评论 #25360998 未加载
whalesaladover 4 years ago
Every Google SPA is slow. It’s compounded by poor animations that are all a little too long, and Material UI.
jameslkover 4 years ago
There&#x27;s something poetic about using Google&#x27;s own tools to demonstrate why their own frontend code is slow. Maybe the author can suggest they use Lighthouse CI next to track which commits improve&#x2F;degrade UX (but I&#x27;m guessing that&#x27;s a competing product with their own).
lukemanover 4 years ago
I can only imagine how many battery cycles I&#x27;ve lost to the BigQuery web console, especially the jobs detail views. Safari tends to be pretty great with battery life, but it&#x27;s no match for that thing.
ernsheongover 4 years ago
Personally, the Google Cloud Console UI is an engineering marvel. The amount of complexity is, to my imagination, mind-boggling. That is just works most of the time is amazing. Complex workflows that other require you to visit 10 pages to complete a thing is seamlessly executed for you with sidebar UIs, etc.<p>I&#x27;m sure the performance bit of it would catch up soon. But who is using it anyway, and surely these people have pretty good internet. Not vindicating, but I&#x27;m sure the optimization will come later.
ProAmover 4 years ago
Probably the same reason why the gmail web interface is so slow too.
markbnjover 4 years ago
Is it slower than the AWS console? We use both and my subjective sense is that it isn&#x27;t, but I regularly visit just a couple of specific sections in the AWS console whereas we use the Google console for a lot of things daily. I&#x27;m sure front end engineers could find a lot to complain about in the GCP console&#x27;s design and implementation, but the tl;dr for me is that it works and it&#x27;s fast enough for the things I need to do. In areas where the console is limiting I am probably working off the CLI anyway (daily operations within our k8s clusters for example).<p>Probably worth noting as well that for both consoles the underlying APIs are broad, complex, and evolving at a dizzying pace. I can only imagine the technical and organizational challenges around keeping these consoles up to date and improving them where possible.
wg0over 4 years ago
I use AWS and GCP regularly and Azure sometimes as well. GCP is too damn slow by comparison not that others too would win any industry awards for speed but they are usable. On GCP however, the GKE screens are damn slow with spinner spinning for so long that I started to doubt my internet connection.<p>UI of a IaaS (or PaaS) certainly is a complex matter and I guess few iterations down the road, GCP might perform better. May be load lazy load the UI functionality (JS) on demand or something.
评论 #25366181 未加载
jeffrallenover 4 years ago
&gt; The initial HTML request is very fast and only takes about 150ms.<p>Umm, Houston, we have a problem. That&#x27;s way way way too long for a first page load of HTML only. It should be 30 ms.
samfisher83over 4 years ago
Maybe its time to move from webapps back to desktop apps? Angular, React etc. all this JavaScript seems to slow everything down.<p>Everything in tech is so cyclical.
评论 #25359816 未加载
nojvekover 4 years ago
Google controls the chrome browser, angularjs and google cloud UI. With the smartest engineers, we still see a shitty user experience.<p>Just goes to say hiring engineers doesn’t solve problems. Focusing relentlessly on user experience, having performance and reliability as an org goal gets things done.<p>As you add more people, each of them has less autonomy on the customer experience.
aloukissasover 4 years ago
Hey, at least you can easily find what you want in GCP. In AWS, you&#x27;re left with Googling anything you want to do.
phendrenad2over 4 years ago
I keep waiting for some company to remember how fast desktop apps are and wake us all from our collective webapp delusion. I imagine native Swift on MacOS and C# on Windows desktop GUI frontends for Google Cloud wouldn&#x27;t be hard to build or maintain. How often does Google Cloud change their webapp&#x27;s UI?
aequitasover 4 years ago
I&#x27;ve come to the conclusion it&#x27;s their way of telling me to use the API or the CLI. As in, why am I throwing all these meabytes of the line just to perform a single command that could be done with the API as well. If only their API wasn&#x27;t as slow as well.
sleepy_keitaover 4 years ago
I originally didn&#x27;t like AWS&#x27;s console because it wasn&#x27;t &quot;consistent&quot;, but when I opened up GCP&#x27;s console the first time, I immediately preferred AWS. Fast and usable is better than inconsistent.
lowdoseover 4 years ago
I can find my way easier in Google Cloud than in AWS. The services are also more polished and seem more mature compared to AWS. I&#x27;m about to give Google Colab Pro a try because the free version has been deteriorating.
secondcomingover 4 years ago
GCP&#x27;s UI controls for adding&#x2F;removing instances from instance groups is appalling. It&#x27;s unbelievably slow and can even lie to you (i.e. telling you an instance has been removed when it actually hasn&#x27;t).
Ono-Sendaiover 4 years ago
Reminds me of the MS azure page taking 17 seconds to load: <a href="http:&#x2F;&#x2F;forwardscattering.org&#x2F;post&#x2F;41" rel="nofollow">http:&#x2F;&#x2F;forwardscattering.org&#x2F;post&#x2F;41</a>
pavelevstover 4 years ago
Because more js and less html is always better. Also rendering html on server is very expensive for backend apps<p>Also if your company has many js and backend libraries, you need to use them, at least on one place
bjornsingover 4 years ago
&gt; We can see that each page loads over 15 MB of JavaScript code.<p>It’s rumored that the compute Google sells is actually performed by that JavaScript code, running in customers browsers. :P
StillBoredover 4 years ago
Actually, looking at this I&#x27;m surprised that the mainstream browsers are still caching javascript, but not some pre-parsed&#x2F;compiled version of the code.
评论 #25360896 未加载
评论 #25361200 未加载
divanover 4 years ago
Why would anyone think that hypertext browser and typesetting tools would be a good platform for modern, fast and rich UI apps?
SoSoRoCoCoover 4 years ago
20% of OPs analysis could be solved by tree shaking, something we&#x27;ve had in webpack and its competitors for some time now.
jbirerover 4 years ago
Ah yes, Angular.
评论 #25363140 未加载
monkeybuttonover 4 years ago
I&#x27;m surprised no one has mentioned the new AdWords UI yet, the load times are agonizingly painful.
joeblauover 4 years ago
Is there something Angular can do to help improve the performance before creating the page?
评论 #25360676 未加载
评论 #25366169 未加载
zomgwatover 4 years ago
The slow UI is one (of many) reasons why I moved away from Google Cloud Monitoring.
beastman82over 4 years ago
because it&#x27;s the web, and thus loading everything every time, instead of a desktop application.
prodtorokover 4 years ago
I think its fine at enterprise scale... has anyone experienced AWS console at enterprise scale? in 2015-17 it was awful.
dsignover 4 years ago
That&#x27;s what happens when you employ over-enthusiastic developers obsessed with their Javascript-framework-legacy. Things worked fast when HTML was the UI, and the logic was in the server.
评论 #25358578 未加载
评论 #25360050 未加载
评论 #25358629 未加载
评论 #25359378 未加载
xystover 4 years ago
just goes to show that working at google is overrated.
Traubenfuchsover 4 years ago
I think the answer is: This is the best the richest and best companies in the world, with their best paid 100x rockstar developers can do. Google is literally both the creator of the browser (Chrome), the framework (Angular) and the web-app (GCP) we use and still, this mess is the best they can give us. They have direct access to the creators of Chrome and Angular, in some sense they are the owners of the internet and the owners of the way we access the internet.<p>And yet, that&#x27;s the best they can do. It&#x27;s just that hard and impossible to get it right. Sorry guys!
评论 #25359925 未加载
评论 #25359753 未加载
评论 #25360533 未加载
评论 #25360263 未加载
评论 #25359797 未加载
评论 #25360396 未加载
评论 #25360524 未加载
评论 #25359989 未加载
评论 #25360809 未加载
评论 #25360853 未加载
评论 #25361122 未加载
评论 #25361879 未加载
评论 #25360371 未加载
评论 #25361365 未加载
评论 #25359901 未加载
评论 #25361581 未加载
评论 #25360089 未加载
评论 #25359802 未加载
评论 #25360753 未加载
评论 #25359947 未加载
评论 #25360106 未加载
johncena33over 4 years ago
I haven&#x27;t used GCP for a long time. I regularly use AWS though. I also find AWS UI to be very slow. It always surprises me why.