https://vaz.ac/ Recent content on vaz.ac Hugo -- gohugo.io en-us Tue, 01 Jan 2019 20:27:33 -0600 https://vaz.ac/about/ Thu, 19 Oct 2023 00:00:00 +0500 https://vaz.ac/about/ I am currently an engineer in Core Technology at Citadel. Previously, I was working on the Web Platform via #webperf with Akamai and was a cofounder of SOASTA. I’ve been around the block - and back. I’ve seen some things, some things that can’t be unseen. Some of those things I’ve written: a charting library in VML (back when webapps could afford to be IE only) long-running applications built without hard navigations before they were called “SPAs” or we said “AJAX” or “Comet” browser analytics code in OG vanilla JavaScript with support for anything as modern as IE5. https://vaz.ac/post/server-timing/ Tue, 01 Jan 2019 20:27:33 -0600 https://vaz.ac/post/server-timing/ This is a cross-post from @stoyanstefanov’s 2018 Performance Calendar, the original can be found here. Consider the following timing data for a stylesheet request: If you were staring at the browser who had to wait around for a response for those 236.79 milliseconds, you’d be hard pressed to find out what was going on. Maybe that time reflects RTT (roundtrip time) and my server responded instantly. Or maybe my server had to do a bunch of custom work to hand me back the bytes of my stylesheet. https://vaz.ac/post/server-timing-compression/ Fri, 21 Dec 2018 12:02:44 -0600 https://vaz.ac/post/server-timing-compression/ Introduction For domains that use our RUM product, through the power of the Edge, we are now injecting up to 3 Server-Timing entries per resource (including basepage). Because we don’t sample and because we beacon back every timer of every resource requested from every non cross-origin <IFRAME>, we’ve already been applying custom compression based on tries to save data going out of the browser. For Server-Timing, we have a lot of work to do, because the data can get pretty verbose and redundant. https://vaz.ac/post/clearresourcetimings/ Wed, 15 Aug 2018 00:00:00 +0000 https://vaz.ac/post/clearresourcetimings/ While doing some field research for a talk he gave at #PerfMatters Conference, my colleague @simonhearne made an interesting discovery. 👋 @newrelic @newrelicdev ! Your injected JS clears the ResourceTiming buffer when it gets full, meaning nothing else can access the data. Please fix, i.e. don't clear the buffer 🙏https://t.co/SHAfecuGqi pic.twitter.com/uPSReutDPR — Simon Hearne (@simonhearne) March 23, 2018 Was there really “beef” between two Javascript analytics agents? How did it resolve? https://vaz.ac/post/unbound-listeners/ Mon, 30 Jul 2018 10:00:00 -0500 https://vaz.ac/post/unbound-listeners/ The Setup One of the trickiest things to get right in javascript is this. To illustrate this point, let’s look at a situation we came across with one of my favorite browser APIs: addEventListener. Attaching a load event listener to the window object is pretty straight forward: 1 2 3 window.addEventListener("load", function (e) { // handle `load` event }); People start to get themselves into trouble when they assign references to instance methods and later want to execute those instance methods.