I found out my water usage is ~10x higher than expected. So I'm doing what any normal human would do, point a Nest cam at the meter and periodically log usage in a spreadsheet.
I even created an activity zone over the ones digit in Nest so it annotates the timeline whenever usage changes 😂
My back of the envelope expected usage is 160 gallons/day, but actual usage is coming out to 1600 gallons/day. The difference is as if I have a leak somewhere losing 1 gallon per minute, every minute!
I'd actually be more relieved if it's a leak and not my gluttonous water usage
BREAKING: Meter readings as billed by the water company are exactly 10x what my meter actually reads. That would explain the discrepancy!
Also see the nice note from their billing department. They can tell something's not right and want to help find the problem. I'll be asking about the 10x reading next time they call..
• • •
Missing some Tweet in this thread? You can try to
force a refresh
@felixarntz Specifically looking at img[loading=lazy], adoption is at 17% of websites, up from 1% this time last year.
Of those 17% of websites, 84% are @WordPress websites!
@felixarntz@WordPress When we look at how real users' LCP experiences compare on WordPress sites with and without loading=lazy, we see something peculiar:
LCP seems to be slower when lazy-loading is used 🤔
Here's a head-scratcher for you: why is example.com failing the Core Web Vitals assessment despite getting perfect lab scores? It's just a KB of text!
This is a good teachable moment in reading web perf tools.
Lab tests are run from a single location at a point in time. Lighthouse in PSI emulates a relatively low-end phone and the site performs very well, getting a lab performance score of 100 and 0.8 second LCP.
So far so good.
Field data is a distribution of real-user experiences aggregated over time.
Good lab tests today may not be simulating poor real-user experiences from a couple of weeks ago. So the field data may be dragged down until the poor experiences are "flushed" out of the 28-day window.
And when scrolling back to the top of the page, the header is added back into the layout flow, causing YET ANOTHER layout shift.
This kind of CLS is unbounded, meaning users can incur many layout shifts depending on their scrolling behavior, and it can be hard to debug.
(2/4)
The solution for this and most other layout stability issues is to reserve space for the header when it becomes pinned, for example with a placeholder element or margin-top on the next content.