Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How I test site speed changes using Chrome's local overrides (2021)

tryblackbird.com

Post reply on HN
Print view View original

11–20 of 32 posts

Re: How I test site speed changes using Chrome's local overrides (2021)

#11

Post by dlisboa »

nuancebydefault wrote: post #10
shortrounddev2 wrote: post #4

I have coworkers who only use 2 of chromes debugging tools: the console and the network tab. They dont know about breakpoints, mapped typescript/react files, or local overrides. Every time they come to me with some issue they're facing, I have them set up breakpoints first before we do anything. Usually that's all that we need to do, and we figure out the problem in about 5mins

On a tangent, it is weird sometimes that people not always pick the right tool for the job, even if the effort is small and the results pay off immediately. Like slicing carrots using a potato knife or even a table knife.

Most people don't know all the tools at their disposal, or how to use them. I certainly don't and I consider myself above average in this regard.

Chrome DevTools has that issue since it's always changing, adding new things, and they're not discoverable/learnable from inside of it.

If you had a drawer of 50 kitchen implements, would you even think to search for the mandoline slicer if you didn't already know about it?

Re: How I test site speed changes using Chrome's local overrides (2021)

#12

Post by exceptione »

onion2k wrote: post #5
CalRobert wrote: post #2

[flagged]

This is good advice for everyday browsing, but please test your web apps in all browsers, including Chrome.

A good way to end chrome's deathly entanglement of the web is to make chrome untenable.

Supporting chrome in taking over the web is not a neutral act.

Re: How I test site speed changes using Chrome's local overrides (2021)

#13

Post by andromaton »

The snippet for fetching performance numbers is useful but it's cargo culting (ie, using incorrectly and needlessly) Number.EPSILON [1], besides not using the built in toFixed(2)

How universal is the drive to try to keep others from making needless mistakes?

[1] "FCP is " +Math.round((fcp + Number.EPSILON) * 100) / 100

Re: How I test site speed changes using Chrome's local overrides (2021)

#14

Post by dotancohen »

nuancebydefault wrote: post #10
shortrounddev2 wrote: post #4

I have coworkers who only use 2 of chromes debugging tools: the console and the network tab. They dont know about breakpoints, mapped typescript/react files, or local overrides. Every time they come to me with some issue they're facing, I have them set up breakpoints first before we do anything. Usually that's all that we need to do, and we figure out the problem in about 5mins

On a tangent, it is weird sometimes that people not always pick the right tool for the job, even if the effort is small and the results pay off immediately. Like slicing carrots using a potato knife or even a table knife.

If you'd care to list some of your most used - or most useful tools - I'd love to read it. I suspect that I don't even know about most tools available to web devs.

For what it's worth, I stick to server-side for most of my work. But occasionally I have to fix something on the front end - whether it be a UI issue in CSS/HTML or a real problem in Javascript. So a quick mention of those front-end tools available and what they do would be great. Thank you!

Re: How I test site speed changes using Chrome's local overrides (2021)

#15

Post by shortrounddev2 »

dotancohen wrote: post #14
nuancebydefault wrote: post #10

Earlier quoted context omitted.

On a tangent, it is weird sometimes that people not always pick the right tool for the job, even if the effort is small and the results pay off immediately. Like slicing carrots using a potato knife or even a table knife.

If you'd care to list some of your most used - or most useful tools - I'd love to read it. I suspect that I don't even know about most tools available to web devs. For what it's worth, I stick to server-side for most of my work. But occasionally I have to fix something on the front end - whether it be a UI issue in CSS/HTML or a real problem in Javascript. So a quick mention of those front-end tools available and wha…

Not him but I use typescript with webpack. Webpack has webpack serve, which runs a simple HTTP server that shows an index.html for testing your script. It adds some file watchers on your source so if you make any changes it automatically compiles. Webpack will build the .map files so you can run breakpoints in your browser on the original source, but if you develop with vscode, you can create a launch profile which allows you to attach your vscode debugger to the browser and put your breakpoints in VSCode instead of the browser (which I prefer the UI for). This works with react as well

Re: How I test site speed changes using Chrome's local overrides (2021)

#16

Post by CalRobert »

onion2k wrote: post #5
CalRobert wrote: post #2

[flagged]

This is good advice for everyday browsing, but please test your web apps in all browsers, including Chrome.

Firefox users have been dealing with devs completely ignoring everything but Chrome for years.

Re: How I test site speed changes using Chrome's local overrides (2021)

#17

Post by aloer »

shortrounddev2 wrote: post #4

I have coworkers who only use 2 of chromes debugging tools: the console and the network tab. They dont know about breakpoints, mapped typescript/react files, or local overrides. Every time they come to me with some issue they're facing, I have them set up breakpoints first before we do anything. Usually that's all that we need to do, and we figure out the problem in about 5mins

I usually recommend chrome dev tools to newer colleagues by saying that they are probably the dev tools with the biggest budget. No idea if I am right but so so many features.

That said, 95% of my usual problems can be debugged with the console. Often it is faster, easier to grok and does not interrupt flow as much as a forgotten breakpoint would.

console.time, console.count, debugger; (breakpoint set in code) and $0 (code ref to highlighted html element) are super useful as well. Usually that is enough before manually setting breakpoints

also nice to know: Safari is great for (offscreen)canvas debugging

Re: How I test site speed changes using Chrome's local overrides (2021)

#18

Post by nuancebydefault »

dlisboa wrote: post #11
nuancebydefault wrote: post #10

Earlier quoted context omitted.

On a tangent, it is weird sometimes that people not always pick the right tool for the job, even if the effort is small and the results pay off immediately. Like slicing carrots using a potato knife or even a table knife.

Most people don't know all the tools at their disposal, or how to use them. I certainly don't and I consider myself above average in this regard. Chrome DevTools has that issue since it's always changing, adding new things, and they're not discoverable/learnable from inside of it. If you had a drawer of 50 kitchen implements, would you even think to search for the mandoline slicer if you didn't already know about it?

You are right. But what I wanted to say is, some people stick to very basic tools, even after you show them more convenient tools like a sharp knife with a firm handle and a knife sharpener. Often the switching part of the process seems to big of a hassle.

Re: How I test site speed changes using Chrome's local overrides (2021)

#19

Post by shortrounddev2 »

nuancebydefault wrote: post #18
dlisboa wrote: post #11

Earlier quoted context omitted.

Most people don't know all the tools at their disposal, or how to use them. I certainly don't and I consider myself above average in this regard. Chrome DevTools has that issue since it's always changing, adding new things, and they're not discoverable/learnable from inside of it. If you had a drawer of 50 kitchen implements, would you even think to search for the mandoline slicer if you didn't already know about it?

You are right. But what I wanted to say is, some people stick to very basic tools, even after you show them more convenient tools like a sharp knife with a firm handle and a knife sharpener. Often the switching part of the process seems to big of a hassle.

Yeah, I've shown the junior devs a dozen times how to set up breakpoints in VSCode and they still opt to console.log everything instead
Post reply on HN