So how do you actually go about doing it?įirst off, I’d say to write the benchmark before you start writing your blog post. Okay, so that was my long diatribe about why you’d bother writing about web performance. So they aren’t always familiar with the day-to-day concerns of working web developers. Browser developers spend most of their day writing C, C++, and Rust, not necessarily HTML, CSS, and JavaScript. Plus, as a web developer, you might actually be in a better position to write a benchmark that is more representative of real-world code. In the same way, if you don’t work at a browser vendor (I don’t, anymore), then you are blessedly free to say whatever you want about browsers, and to honestly assess their claims and compare them to each other in fair, unbiased benchmarks. ![]() Don’t expect them to admit that their new model has a lousy safety rating. (If you work for a browser vendor and are reading this, I’m sure some examples come to mind.)ĭon’t expect a car company to tell you that their competitor has better mileage. But I choose not to, because I’d rather pick on myself. I worked on marketing videos that showed our browser winning in experiments where we already knew we’d win.Īnd if you think I’m picking on Microsoft, I could easily find examples of the other browser vendors doing the same thing. (Not before! Definitely not before.) I designed benchmarks that explicitly showed off the improvements we had made. I wrote about input responsiveness after we had already made it faster. I wrote about scrolling performance because, at the time, our engine was the best at scrolling. I worked on the performance team at Microsoft Edge (back in the EdgeHTML days, before the switch to Chromium), and I did the same stuff. (Don’t expect the team who built the feature to eagerly tell you this, though.)īy the way, I don’t blame the browser vendors at all for this situation. If you actually look into these claims, though, you might find that the performance improvement is pretty meager, or it only manifests in a specific context. Other times, browser vendors will release a new feature, announce it with some fanfare, and then make vague claims about how it improves performance without delving into any specifics. If anything, they’ll talk about it after they’ve done the work to make things faster, meaning the benchmark already went through several rounds of internal discussion, and was maybe used to evaluate some internal initiative to improve performance – a process that might last years before the public actually hears about it. But nobody is going to go out of their way to sing from the mountaintops about how lousy their browser is in a benchmark. Occasionally you will find someone’s personal blog, or a comment on a public bugtracker, which betrays that their browser is actually not so great in some benchmark. Of course, there are exceptions to this rule. So the browser vendors’ hands are pretty tied when it comes to accurately writing about how their product actually works. This is why whenever a browser vendor releases a new benchmark, surprise surprise! Their browser wins. If you run a benchmark and it turns out that your browser is the slow one, or it’s a mixed bag, then browser vendors will keep pretty quiet about it. Web performance claims are often used in marketing, with claims like “Browser X is 25% faster than Browser Y,” which might need to get approved by the marketing department, the legal department, not to mention various owners and stakeholders…Īnd that’s only if your browser is the fast one. Browsers are in the business of selling browsers. ![]() (Or send them a DM, I suppose, in our post-pandemic world.)īut in other ways, browser vendors really aren’t in a good position to talk frankly about web performance. If some part of the system is performing slowly, you can go knock on the door of your colleague who wrote the code and ask them why it’s slow. ![]() Browser vendors know how their product actually works. The first and maybe most obvious question is: why bother? Why write about web performance? Isn’t this something that’s better left to the browser vendors themselves? This post is an attempt to distill some of what I’ve learned over the years to offer as advice to other aspiring tinkerers, benchmarkers, and anyone curious about how browsers actually work when you put them to the test. I like to think I’ve gotten pretty good at it, but sometimes I look back on my older blog posts and cringe at the mistakes I made. I’ve been writing about performance for a long time.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |