11–20 of 39 posts
https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?ur... web.dev says 66 though
https://developers.google.com/speed/pagespeed/insights/?url=... shows 99-100 every time I load it ¯\_(ツ)_/¯ Our mobile score is lower (86 according to PageSpeed), but I mention that in a blog post.
I am not sure whether 20 development days invested for a postmark score is a good time investment.
Google Analytics offers many site speed metrics that are tied to real-world visits and can be correlated with other metrics, behaviors, and conversions on the site itself. These numbers also give you visibility on the entire site and not just a single page that you've run through the Lighthouse tool.
I don't want to discourage people from making the web faster but Lighthouse scores are about as helpful as domain authority and Alexa rank when you can take a detailed look at your users through Google Analytics and get more granular performance analysis from WebPageTest.org (which also provides Lighthouse scores, can be run privately, simulates various devices and locations, and much more).
The problem with being a slave to these Lighthouse scores is the test is only concerned with the one page you are testing. If you assume your visitor will only visit a single page on your site that's fine, but even if they visit a second page, nearly everything it suggests you do will make that second page load slower than if you had developed the page using the traditional methods- external CSS/JS files that apply t…
1. Have your initial landing page load and render as fast as possible, and cut stuff out to make this happen.
2. That initial page will usually take the user at least a couple seconds to read. While they are doing that, you can load stuff in the background that is needed for other parts of your site, like larger JS bundles. There are a number of ways to do this.
Earlier quoted context omitted.
It looks like the accessibility score went down , too.
Hi, author here. Accessibility score went from 87 to 96. The second screenshot with a score of 86 was a preliminary result after introducing the fake widget. (Best Practices went from 86 to 100.)
If you're interested in this sort of optimization then Zach Leatherman's "Speedlify" is a good tool for doing continuous monitoring - https://www.zachleat.com/web/speedlify/
The problem with being a slave to these Lighthouse scores is the test is only concerned with the one page you are testing. If you assume your visitor will only visit a single page on your site that's fine, but even if they visit a second page, nearly everything it suggests you do will make that second page load slower than if you had developed the page using the traditional methods- external CSS/JS files that apply t…
Also you always have to remember that users won't necessarily hit the homepage first. If they click a link from a search or a social media post they might end up on any page in the site. Everything that you do to optimize the homepage should be done for every page. You end up with cacheable assets that are shared between pages and everything else is only downloaded when the user hits a page that actually needs it. That's the way to a fast site.
With HTTP2 request parallelisation having lots of small files is not a bad thing. You can also add prefetch headers for big things like fonts. There's lots of ways to make sites load better.
I am not sure whether 20 development days invested for a postmark score is a good time investment.
I've worked on a number of these projects where clients were chasing Lighthouse scores without any actual measure of effort, reward, or impact. Google Analytics offers many site speed metrics that are tied to real-world visits and can be correlated with other metrics, behaviors, and conversions on the site itself. These numbers also give you visibility on the entire site and not just a single page that you've run thr…
I am not sure whether 20 development days invested for a postmark score is a good time investment.
I've worked on a number of these projects where clients were chasing Lighthouse scores without any actual measure of effort, reward, or impact. Google Analytics offers many site speed metrics that are tied to real-world visits and can be correlated with other metrics, behaviors, and conversions on the site itself. These numbers also give you visibility on the entire site and not just a single page that you've run thr…
I have seen improvements from speeding up pages particular in mobile postmark is unusual in having so much many desktop viewers.
The problem with being a slave to these Lighthouse scores is the test is only concerned with the one page you are testing. If you assume your visitor will only visit a single page on your site that's fine, but even if they visit a second page, nearly everything it suggests you do will make that second page load slower than if you had developed the page using the traditional methods- external CSS/JS files that apply t…
I use a Lighthouse score for troubleshooting, but at the end of the article there is a chart of the change in Core Web Vitals, which tracks performance of _all_ pages indexed by Google over time.
> "…nearly everything it suggests you do will make that second page load slower…"
This is just not true for _any_ of the suggestions in the article. I guess you can make this argument for breaking down one CSS bundle into four, but their content was picked based on analytics of where people go more often. We make 1 extra request but load much less cruft, and it applies to any page of the website.
The problem with being a slave to these Lighthouse scores is the test is only concerned with the one page you are testing. If you assume your visitor will only visit a single page on your site that's fine, but even if they visit a second page, nearly everything it suggests you do will make that second page load slower than if you had developed the page using the traditional methods- external CSS/JS files that apply t…
The only reason the second page loads slower is because the user hasn't downloaded all the things they need to display it yet - in other words, you're suggesting downloading unused data on the first page in order to make the second page load faster. I'd argue that's not optimal because what you're gaining on the second page you're losing on the first page. Also you always have to remember that users won't necessarily…
Also you're not just gaining for the second page, you're gaining for all pages visited on the site going forward.