Error: 500 from Lighthouse API: Internal Server Error
Is all get when I try to test my website.
Web.dev by Google
181–190 of 264 posts
Re: Web.dev by Google
#182Has anyone viewed the report? It's full of elements never used on the sites I checked.
While it is still in beta (like all Google products are) don't take this serious.
Re: Web.dev by Google
#183This is useless to me because I have a website, not a web application. I got a 46/100 on PWA which is astonishing because the site being tested is not a progressive web application at all. Imagine vim getting a 40/100 score in the category of web browsers. Weirdly good score. The accessibility audit is garbage as well. Apparently I should add an image to the site just so I can put an alt attribute in it. I should inc…
This, so much this.
The skew to web applications rather than websites for tooling has been very disappointin and myopic view of what a 'website' is.
It would make sense if I could give it a root URL and then a robot progressively ran tests over a month and then reported back, but one URL is a drop in a vast ocean for most of us.
Re: Web.dev by Google
#184Earlier quoted context omitted.
This is a bad take. By releasing tools like this it helps all websites, including Gmail, have the data on how to speed up their website.
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.
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.
Re: Web.dev by Google
#185The results are significantly different from the lighthouse audit in chrome's web developer tools, the latter shows my site as PWA compatible with great performance whereas this tool shows that my site is not PWA ready and has medium performance.
Re: Web.dev by Google
#186Earlier quoted context omitted.
tracking
https://developers.google.com/fonts/faq#what_does_using_the_... 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)
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.
Re: Web.dev by Google
#187I 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.
On our website Google's pagespeed mainly complained about the Google Analytics snippets.
Re: Web.dev by Google
#188This 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…
Why don't you want to implement a basic service worker? A couple of cache strategies among these ones seem like a net positive? https://developers.google.com/web/fundamentals/instant-and-o... (ex: "Cache, falling back to network" for CDN'd libraries, "Cache then network" for content like news articles)
Because for a normal website, it should be taken care by the browser, and not my custom service worker.
This is XMLHttpRequest all over again.
Re: Web.dev by Google
#189Re: Web.dev by Google
#190This is useless to me because I have a website, not a web application. I got a 46/100 on PWA which is astonishing because the site being tested is not a progressive web application at all. Imagine vim getting a 40/100 score in the category of web browsers. Weirdly good score. The accessibility audit is garbage as well. Apparently I should add an image to the site just so I can put an alt attribute in it. I should inc…
This, so much this. The skew to web applications rather than websites for tooling has been very disappointin and myopic view of what a 'website' is. It would make sense if I could give it a root URL and then a robot progressively ran tests over a month and then reported back, but one URL is a drop in a vast ocean for most of us.
Properly made "web application" doesn't have to break the web. It can be curled, links work, back button works, etc. You just don't get any interactivity (besides links) without javascript, but it still works as browseable site (rendered server-side). You can have the cake & eat it.
(I'm not saying that every application should behave like that. Often the extra work is not worth it. But a public, content-heavy site should behave like that, whether it was single-page app or tradiotionally implemented.)