No, it will be available across a wide range of registrars, similar to .app. You can see the full list of participating registrars for our existing TLDs here: https://www.registry.google/register-a-domain/
Correct me if I'm wrong, but registries can't let single registrars have exclusive access to TLDs. If Alphabet/Google were to do this it would be antitrust, and they could lose their dual registry/registrar status.
Getting Chrome SSL warnings on both the OP link and https://get.dev/
Doesn't really evoke confidence, if this is a Google initiative. Can someone post a short precis as to what this is about for those of us who cannot visit the URLs?
UPDATE: Apologies - My bad, not Google's fault. I had a local Valet/NGINX redirect for local .dev domains setup for Laravel development projects that was causing the issue.
Ah, OK, I think I worked out what is happening. I have a valet service running for local Laravel development which is redirecting local .dev subdomains to Valet instances on my iMac!
Apologies for that - I will shut down the Valet service and try again.
Although that might only change the default for new installs; you might still need to change it for existing installs. I'm not sure; I've never used Laravel.
Perhaps your browser is being directed to a page not owned by google. I don't get an SSL warning in Chrome or Firefox (Windows 10).
From the site: "With actionable guidance and analysis, web.dev helps developers like you learn and apply the web's modern capabilities to your own sites and apps."
It includes a web version of the Lighthouse website measurement tool. It also has guides for various web dev topics.
The topics can be browsed normally, but I think most users will discover topics by the measurement tool showing the user guides to improve their website.
Heyo! One of the web.dev devs here. The new web.dev site is an experiment from our team to see if we can improve the interactivity of our docs. We link to developers.google.com/web in a number of places. Over time, if folks seem to enjoy the web.dev model, we may explore moving more of our docs over there. But for now it's just a fun experiment
Confused about the purpose of a "code freeze", I guess you're focused on monitoring for abuse, so don't want to go back to working on features/functionality yet?
I just ran their audit to https://mail.google.com, you guys (googlers) need to speed up your websites first, Gmail is terrible slow lately, just saying...
Google's pagespeed service is hot garbage. You can do things that make the page load significantly slower and get a perfect score than if you had a lower pagespeed score with a much faster page load.
I also find it strange how I can get an A on every other page speed service, including GTMetrix, but get an F on Google's tes(s). Totally useless.
I never pay attention to the "grades" only the data, especially the waterfall graph/data. The grades are ridiculous, and mostly meant to cause alarm. You can score 100/100 on almost every test, but get a "D" overall because you scored poorly on 1 or 2 tests. It's great tool for techs, but in the hands of a client almost every result/score appears terrible.
Meh, these tests are just good ways to find obvious problems with your site.
Fixating on the overall score seems like an indication of a different problem.
For example, you can't change the caching behavior of google-analytics.js, and it's usually intractable to split apart your CSS to optimize for above-the-fold content. Oh well, you didn't get a perfect score. Stay practical.
Try selling that to a client that keeps using the test against a site that is A rated everywhere else because Google's brand has fooled them into thinking a perfect score means better SEO.
This is a problem we run into, clients will run their site through a speed tester then give us a list of things to fix...without having a clue of what the ratings and results even mean.
Right, that would be an example of a "different problem."
I'd be hard pressed to let stupid things client/managers can do direct how this sort of tool should work. For example, it'd be silly to demand "score inflation" just because your client is unreasonable. Or rather, if a client is making your life hard, I don't think it's the world that needs to change.
What's your solution if your client measures your success by punching their website into https://www.worthofweb.com/calculator/? And doesn't take you seriously enough to listen to you in general?
Most performance profilers will penalize you for embedding Google Analytics and Google Fonts because they have poor caching settings. What's so important about those resources that they can't be cached for longer periods?
This is a complete guess but I suppose one request everyday would be enough to get atleast some idea of how popular any given font is. The page says its to keep them updated but I highly doubt that would be the reason.
I see no explanation given why an asset that never changes would need to be requested once a day, and they clearly state they do record it.
> We only [sic] see 1 CSS request per font family, per day, per browser. Google Fonts logs records of the CSS and the font file requests, and access to this data is kept secure.
I read that as what's written there. It's for tracking. Tracking popularity is still tracking.
They take and keep the tracking data. What they say they use it for doesn't change that. If they simply incremented a counter the bit about "keeping access to the data secure" would make no sense.
While I don't know anything about fonts stuff, successful execution of the ad tag leads to an ad request, and this happens on every page view which has the script and not just the ones where the file has fallen out of cache. So there's no additional useful information Google would get from a low cache lifetime for the script.
The script request is to a cookiless domain for performance, unlike the ad request, so there's not even much useful information on that request.
(Disclosure: I work at Google, on ads JS, and I previously worked on mod_pagespeed. Not speaking for Google, just myself.)
Easier bug fix presumably. Meaning if there is a bad release url is cached for little. If urls were versioned and were changable by google, it would have been done.
Google cannot bust this in case of a bug. They can mitigate this by having a loader with built in functionality that always looks out for "is there a newer version" but that has its limitations.
There are two main reasons why short caching is helpful on tag scripts:
* Faster iteration time for developers: the more often you release updates the faster you can move. If your script has a one week cache lifetime then there's not much point in daily releases and any experiments you run will be really skewed.
* Quicker response to problems: if we push out a bad update that gets past our testing, the TTL we serve it with determines how long that will stick around in browser caches.
(Disclosure: I work at Google, on ads JS, and I previously worked on mod_pagespeed. Not speaking for Google, just myself.)
I said this in reply to QUIC apparently ignoring hardware TLS offload...
Is this for real?
Even Quick Assist?
I am watching the internet be developed by the giants for the giants. In my memory, giants didn't act like giants. "At scale" wasn't a preprocessor. Browser developer tools were written to help you participate in conversation, not play unending catch up in translation, the meaning lost in acoustics of auditoria for the life of me I would think giants could make intelligible.
I agree it's not perfect! But my view is that if they(Google) did the effort todo pagespeed, then lighthouse, then integrate lighthouse in Chrome.. and now in a separate website... Some of the metrics must be import for your rankings/site - even if only indirectly (slow site etc)
When Gmail first came out I was amazed at how fast it was, so much faster than the native outlook client I used at the time, wow! How is that even possible in javascript!
Now gmail is slower than most any other website I use regularly. Can't even refresh the inbox in less than three seconds.
I've noticed the same slower by a bit every year pattern with google maps too. I'm afraid to click anything when I have a map open because I know it might trigger a repaint which will cause me to sigh and switch to another tab while it chugs for a few seconds to accomplish this.
The difference in performance between Fastmail and the new Gmail interface right now is freaking stunning. I still load Gmail every few days to see if I have email there, and it's like waiting for Windows 98 to boot.
This was actually an intentional choice not to do that. Setting up forwarding means you may have email continually passing through Google servers you didn't realize was still doing so. By having a hard cut between the two, I know for a fact that any email received at FastMail is not going through my Gmail account, and any email received at Gmail is, and needs to have the contact information updated.
I have a vacation auto-responder permanently on on Gmail as well to notify any individuals who hit my old address where my new address is.
Not web dev related, but related to Google not focusing on performance: the latest Android release of Google Maps is actually non-functional on my Galaxy S7 because of how slow it is. It completely overloads RAM and crashes. Every time. Hilarious.
I'm kind of disappointed that this isn't Go the programming language. I thought "that'd be really cool, porting android apps from Java to Go." But no, turns out there are only so many creative words you can come up with when "google" is your starting point.
Gosh, thanks for this note! I thought it was just me and my 2.5 years old HTC that can't keep up. It is totally unusable as you say, for a few weeks now (crashes, slow, markers/directions not show at all while the app thinks it does)...
Not really. Would you take webdev advice from a company where their own apps are memory hog/leaking garbage (Gmail)? At some point you need to call a square a square.
> Not really. Would you take webdev advice from a company where their own apps are memory hog/leaking garbage (Gmail)? At some point you need to call a square a square.
Wait, was web.dev built by the Gmail team? I always assumed Google was bigger and more complex than that?
Yup. It’s a company that routinely breaks the web, pursues its own standards at the detroment of others and and will prioritize things like AMP over any of its own tools.
Their advice isn't perfect but that doesn't mean I won't pay attention to it. Memory use and leaking isn't really covered in their page speed advice anyway, which is mostly about server side caching, image optimisation, css / js delivery.
If there's any other decent page speed assistance I'd love to see it.
If you disagree with the advice on web.dev then that's fine. Call that out. Saying that the advice is wrong because another team in another building, maybe in another city or another country, built an app you don't like, is just wrong. This sort of ad hominem is beneath HN.
Sorry, I'm not letting you get away with an illogical argument here. There's nothing hypocritical about the authors of web.dev making an auditing tool because some other people who work for the same company work on site that (may) do badly.
In fact, it wouldn't be hypocritical even if the authors of web.dev themselves worked on a site that did badly.
It is, after all, a tool. It's not a declaration of superior intellect. It's not an article of condescension. It's a tool.
The hypocritical statement is on the part of the company, not the specific authors. The efforts represent the company, as do their efforts in standards organizations, browser implementations, and email user interfaces. It is completely logical to question their inconsistencies especially as one of the primary drivers of standards. If the company cannot present a consistent front, we can ask ourselves whether their attempts to help others do so are accurate much less well intentioned. This should be obviously clear and not about individuals or their feelings.
Releasing a tool cannot be hypocritical. The existence of a tool to audit performance, accessibility, etc. is not a declaration of Google's moral or virtuous superiority. It's a tool.
Seriously! Every click feels like a chore, it's easily 3+ seconds before the page is interactive again. I've started using the mobile app for everyday tasks since it's so much more responsive, I just wish it supported better password resets.
That's kinda what it feels like to me. Does g suite already have so much technical debt that they can't make it better? It's been this way since I started using it, more than a year ago.
Oh man, I used to be on the team that built that. It's just enormous. If you're on Chrome, the optimizations are sometimes enough to make it smooth. If you're on any other browser, god help you. I used to see 30s(!) reflows in Firefox.
Recent Ad Words user here. It is quite possibly the worst application I've used in years. I get that they offer a LOT of products and that the nature of the business is complicated. But, man, was everything about that process awful. And the UI is unbearably slow.
They don't want users. They need the layer of apologists to obscure the grand systematic internalisation game. SI is subject to financial services law in the UK, at least...
I think it is in poor taste for Google to publish https://web.dev/ during the new desktop Gmail.
>Google's web platform team has spent over a decade learning about user needs. Now we want to make it as easy as possible for you to master the defining standards of web development today.
>Fast load times
>Guarantee your site loads quickly to avoid user drop off.
"Loading Gmail"
>Network resilience
>See consistent, reliable performance regardless of network quality.
"Loading..." (in yellow at the top, after clicking a search result. Indefinitely.)
A Gmail account has has 10+GB of data. Users for the most part don't want 10GB in browser local storage. Gmail's speed problems are in the backend, not the web UI.
That's not true. Pop open your console and watch the network tab for yourself. Slow websites are almost always due to frontend issues. Besides, Google has the ability to index the entire internet and return results in milliseconds. I'm guessing it's not my 10GB of email that's tripping them up.
what you've written is totally false. It worked fine on the old UI, and also still works fine in simple HTML mode.
You can see this yourself here: http://mail.google.com/mail/h/ (direct link to html view. you have to already be signed in for this link to work.)
Side note: I'm sure you would have mentioned it, but you don't happen to work at Google on the new Gmail front-end, do you? (Since I could see someone who is, trying to deflect blame for their current bugs by "blaming the back-end".) Just want to make sure...
I have a hard time believing this is "for web developers" when most web developers used `.dev` for local development, which was broken because Google decided they wanted to own `.dev` for themselves.
I think .test is the TLD is the one most likely to work as expected as for all use cases as .localhost might be expected to only ever point to the loopback IP address. If anyone does something more complicated (like using a vagrant private network ip address), you might find some tools break unexpectedly.
Edit: the newer version of the docs have more details (in section 6) on the differences to be expected between test, localhost, example and invalid domains. see: https://tools.ietf.org/html/rfc6761
how's this any different than devs using 123.123.123.123 for test purposes (instead of private network addresses), then getting upset when they found out it has been allocated to China Unicom?
I've switched all my stuff to .test, since that domain doesn't cause as many weird issues with some routers, proxies, OS networking bugs, dumb regex, etc.
Also, .test is reserved for testing/local forever, so it won't suffer the same fate as .dev.
This is powered by Google Lighthouse, with the benefit of it being done via a web UI instead of a Dev Tools Audit. Which is both good and bad.
Good because Lighthouse has some reasonable best practices to follow, and a few good performance timings, so lowering the barriers of entry is nice.
Bad because many of Lighthouses best practices aren't always applicable (our major media customers constantly say "stop telling me a need a #$%ing Service Worker!"). And while Speed Index and Start Render are great, Time-to-interactive, First CPU idle, and estimated keyboard latency are still fairly fluid/poorly defined, and of different value.
This all also overlooks the value that something like the Browser's User Timings provides (Stop trying to figure out what's a "contentful" or "meaningful" paint, and let me just use performance.mark to tell you "my hero image finished and the CTA click handler registered at X"), which Lighthouse doesn't surface up.
What is interesting is the monitoring side. WebPageTest, Lighthouse, Page Speed Insights, YSlow, etc are just point-in-time assessments that is largely commoditized. Tracking this stuff over time and extracting meaningful data is valuable, so that's pretty cool.
Disclaimer: I work in the web performance space. People replace homegrown Lighthouse, puppeteer, or WPT instances with our commercial software, so I'm biased. However I like a lot of the raising awareness and trail blazing about what Performance/UX means that Google is doing.
But I'm getting the impression that you want Lighthouse to surface up this information in a different way. Please feel free to elaborate.
Disclaimer: I write the docs for Lighthouse. I'm speaking from my general knowledge of the project but haven't vetted these comments with my team. So consider all comments my own.
FWIW, the official Twitter desktop app for Windows 10 is a PWA and it works great (well, as well as any official Twitter app has worked in my assessment; not as well as third-party apps from their hey-day, but that's a different story).
I also use the Starbucks PWA (app.starbucks.com) and it mostly works well. Again, it seems to work as well as their native apps.
This is what made me have another look at PWAs, start experimenting with them and starting to see, that for plain CRUD applications PWAs are probably the way to go.
The funny/sad thing about PWA and how broken it's on iOS right now, is that the first iPhone was supposed to work with PWA. I'm not sure if it was Jobs' vision or they didn't have something good to offer for native devs. Safari has been a joke for long time now.
> chrome right now is the only one which supports PWA as "native" app..
What do you mean with "'native' app" exactly? When I use my PWA with a Firefox on Android I can't see that it is a PWA. It just looks like any other Andoird app.
Granted that is only one more browser and on the desktop side Firefox still has a lot to do, but at least there is one more player in the race ;-)
It has been a common practice for devs to setup a local DNS server that points any *.dev domain to localhost. Maybe you did it (or installed some tool that did it) and forgot.
Yep that's our bad. We accidentally started prefixing all of the urls with https we've fixed the bug but haven't shipped it yet cuz we're in code freeze
Talk about breaking the back button! Do a measurement on a website. Then click one of the Guide links like "Links do not have a discernible name". Page navigates away from the report to some documentation. Click back, report is gone.
I get it, it's a single page webapp. But if you do that you need to make all the simple navigations open new tabs. There is a "open link in new button" icon next to each link, but that's really not good enough.
Ah yeah that's something we want to fix. If you're signed in it keeps the report around but if you're signed-out it's stateless. It's definitely on our to-do list to fix.
This is sort of representative of web.dev vs the rest of Google.
Read the rest of the comments, seriously. I would be very discouraged to release this web site when the rest of the company is vehemently opposed to any of the practices listed there.
Wow. From the people that have been botching the web for 20 years...
I mean it's only recently that they've started getting their things together. And arguably their flat design isn't always usable. Now let's talk speed....
Agreed! I love the text only sites. I would add text.npr.org to the list also. I am very tired of sites that spill media and JavaScript all over the place and add no real value, just to slow the site down or to make it completely unusable. A typical site of mine breaks all the rules of current UI design. [1]
263 comments
[ 3.1 ms ] story [ 260 ms ] threadDoesn't really evoke confidence, if this is a Google initiative. Can someone post a short precis as to what this is about for those of us who cannot visit the URLs?
UPDATE: Apologies - My bad, not Google's fault. I had a local Valet/NGINX redirect for local .dev domains setup for Laravel development projects that was causing the issue.
Oh, and this is definitely a valid Google initiative. Source: Work for Google, am involved in this.
Apologies for that - I will shut down the Valet service and try again.
Although that might only change the default for new installs; you might still need to change it for existing installs. I'm not sure; I've never used Laravel.
From the site: "With actionable guidance and analysis, web.dev helps developers like you learn and apply the web's modern capabilities to your own sites and apps."
It includes a web version of the Lighthouse website measurement tool. It also has guides for various web dev topics.
The topics can be browsed normally, but I think most users will discover topics by the measurement tool showing the user guides to improve their website.
* https://web.dev/
* https://developers.google.com/speed/
* https://developers.google.com/web/ (including https://developers.google.com/web/tools/lighthouse/)
web.dev^2
I also find it strange how I can get an A on every other page speed service, including GTMetrix, but get an F on Google's tes(s). Totally useless.
Fixating on the overall score seems like an indication of a different problem.
For example, you can't change the caching behavior of google-analytics.js, and it's usually intractable to split apart your CSS to optimize for above-the-fold content. Oh well, you didn't get a perfect score. Stay practical.
I'd be hard pressed to let stupid things client/managers can do direct how this sort of tool should work. For example, it'd be silly to demand "score inflation" just because your client is unreasonable. Or rather, if a client is making your life hard, I don't think it's the world that needs to change.
What's your solution if your client measures your success by punching their website into https://www.worthofweb.com/calculator/? And doesn't take you seriously enough to listen to you in general?
https://johnrockefeller.net/google-pagespeed-_/
I'm no lawyer, but I read that as it is not used for tracking users.
(full disclosure: I work at Google, on something unrelated)
Probably to allow for updates and estimate popularity, with low overhead assuming CSS files are small.
> We only [sic] see 1 CSS request per font family, per day, per browser. Google Fonts logs records of the CSS and the font file requests, and access to this data is kept secure.
I read that as what's written there. It's for tracking. Tracking popularity is still tracking.
Tracking usually refers to tracking users, which as I read the FAQ isn't what it's for.
The script request is to a cookiless domain for performance, unlike the ad request, so there's not even much useful information on that request.
(Disclosure: I work at Google, on ads JS, and I previously worked on mod_pagespeed. Not speaking for Google, just myself.)
https://www.google-analytics.com/analytics.js
Google cannot bust this in case of a bug. They can mitigate this by having a loader with built in functionality that always looks out for "is there a newer version" but that has its limitations.
* Faster iteration time for developers: the more often you release updates the faster you can move. If your script has a one week cache lifetime then there's not much point in daily releases and any experiments you run will be really skewed.
* Quicker response to problems: if we push out a bad update that gets past our testing, the TTL we serve it with determines how long that will stick around in browser caches.
(Disclosure: I work at Google, on ads JS, and I previously worked on mod_pagespeed. Not speaking for Google, just myself.)
"Error: 500 from Lighthouse API: Internal Server Error"
Is this for real?
Even Quick Assist?
I am watching the internet be developed by the giants for the giants. In my memory, giants didn't act like giants. "At scale" wasn't a preprocessor. Browser developer tools were written to help you participate in conversation, not play unending catch up in translation, the meaning lost in acoustics of auditoria for the life of me I would think giants could make intelligible.
Now gmail is slower than most any other website I use regularly. Can't even refresh the inbox in less than three seconds.
I've noticed the same slower by a bit every year pattern with google maps too. I'm afraid to click anything when I have a map open because I know it might trigger a repaint which will cause me to sigh and switch to another tab while it chugs for a few seconds to accomplish this.
I have a vacation auto-responder permanently on on Gmail as well to notify any individuals who hit my old address where my new address is.
edit: Last one because it supports keyboard shortcuts.
Wait, was web.dev built by the Gmail team? I always assumed Google was bigger and more complex than that?
If there's any other decent page speed assistance I'd love to see it.
In fact, it wouldn't be hypocritical even if the authors of web.dev themselves worked on a site that did badly.
It is, after all, a tool. It's not a declaration of superior intellect. It's not an article of condescension. It's a tool.
>Google's web platform team has spent over a decade learning about user needs. Now we want to make it as easy as possible for you to master the defining standards of web development today.
>Fast load times
>Guarantee your site loads quickly to avoid user drop off.
"Loading Gmail"
>Network resilience
>See consistent, reliable performance regardless of network quality.
"Loading..." (in yellow at the top, after clicking a search result. Indefinitely.)
(some other non-quoted parts are OK)
>Accessible to all
>[Build] a site that works for all of your users.
You can see this yourself here: http://mail.google.com/mail/h/ (direct link to html view. you have to already be signed in for this link to work.)
Side note: I'm sure you would have mentioned it, but you don't happen to work at Google on the new Gmail front-end, do you? (Since I could see someone who is, trying to deflect blame for their current bugs by "blaming the back-end".) Just want to make sure...
I dig google and its products but oh wow is this bug frustrating. Hope it’s fixed soon.
Recently I started using the html only version of Gmail because for my user case is faster than the web app.
I have a hard time believing this is "for web developers" when most web developers used `.dev` for local development, which was broken because Google decided they wanted to own `.dev` for themselves.
Bad taste in my mouth.
Most web developers were wrong. The reserved TLD for local development has been .localhost since 1999.
Edit: the newer version of the docs have more details (in section 6) on the differences to be expected between test, localhost, example and invalid domains. see: https://tools.ietf.org/html/rfc6761
how's this any different than devs using 123.123.123.123 for test purposes (instead of private network addresses), then getting upset when they found out it has been allocated to China Unicom?
Also, .test is reserved for testing/local forever, so it won't suffer the same fate as .dev.
Good because Lighthouse has some reasonable best practices to follow, and a few good performance timings, so lowering the barriers of entry is nice.
Bad because many of Lighthouses best practices aren't always applicable (our major media customers constantly say "stop telling me a need a #$%ing Service Worker!"). And while Speed Index and Start Render are great, Time-to-interactive, First CPU idle, and estimated keyboard latency are still fairly fluid/poorly defined, and of different value.
This all also overlooks the value that something like the Browser's User Timings provides (Stop trying to figure out what's a "contentful" or "meaningful" paint, and let me just use performance.mark to tell you "my hero image finished and the CTA click handler registered at X"), which Lighthouse doesn't surface up.
What is interesting is the monitoring side. WebPageTest, Lighthouse, Page Speed Insights, YSlow, etc are just point-in-time assessments that is largely commoditized. Tracking this stuff over time and extracting meaningful data is valuable, so that's pretty cool.
Disclaimer: I work in the web performance space. People replace homegrown Lighthouse, puppeteer, or WPT instances with our commercial software, so I'm biased. However I like a lot of the raising awareness and trail blazing about what Performance/UX means that Google is doing.
(ex: "Cache, falling back to network" for CDN'd libraries, "Cache then network" for content like news articles)
This is XMLHttpRequest all over again.
It's tough to create an auditing tool that caters to the web at large. See my other comment in this thread: https://news.ycombinator.com/item?id=18442686
> This all also overlooks the value that something like the Browser's User Timings provides... which Lighthouse doesn't surface up.
Lighthouse does surface up this info in the "User Timing Marks and Measures" audit: https://developers.google.com/web/tools/lighthouse/audits/us...
But I'm getting the impression that you want Lighthouse to surface up this information in a different way. Please feel free to elaborate.
Disclaimer: I write the docs for Lighthouse. I'm speaking from my general knowledge of the project but haven't vetted these comments with my team. So consider all comments my own.
My biggest concern is the support outside of chrome.
While other browsers tend to come on pair with chrome in terms of features , chrome right now is the only one which supports PWA as "native" app..
Windows announced support for PWA natively a while ago [0] but there has been no news since then.
On Apple side it's silence radio...iOS have some support but for Mac it seems unlikely to happen...
[0]https://blogs.windows.com/msedgedev/2018/02/06/welcoming-pro...
I also use the Starbucks PWA (app.starbucks.com) and it mostly works well. Again, it seems to work as well as their native apps.
There have been news since February.
UWP hosted apps got replaced with PWAs, including access to UWP APIs if signed, documentation and tooling support is now available.
https://developer.microsoft.com/en-us/windows/pwa
https://docs.microsoft.com/en-us/microsoft-edge/progressive-...
This is what made me have another look at PWAs, start experimenting with them and starting to see, that for plain CRUD applications PWAs are probably the way to go.
What do you mean with "'native' app" exactly? When I use my PWA with a Firefox on Android I can't see that it is a PWA. It just looks like any other Andoird app.
Granted that is only one more browser and on the desktop side Firefox still has a lot to do, but at least there is one more player in the race ;-)
https://en.wikipedia.org/wiki/Progressive_web_applications
I would love to see an example of this. Software-gore.
I get it, it's a single page webapp. But if you do that you need to make all the simple navigations open new tabs. There is a "open link in new button" icon next to each link, but that's really not good enough.
This is sort of representative of web.dev vs the rest of Google.
Read the rest of the comments, seriously. I would be very discouraged to release this web site when the rest of the company is vehemently opposed to any of the practices listed there.
A horrible excuse of a web site – but perhaps that still makes for a good web app. I couldn't tell and don't know if I'd want to.
* edit for clarification: this includes position on previous page
I mean it's only recently that they've started getting their things together. And arguably their flat design isn't always usable. Now let's talk speed....
[1] http://vqRN.com
> Error: 500 from Lighthouse API: Internal Server Error