My team's approach has been to automate real devices and report on any regressions in terms of JavaScript evaluation, layout, paint, garbage collection, etc. Shameless plug: the team is growing and we're hiring an experienced front-end dev. https://nordstrom.taleo.net/careersection/2m/jobdetail.ftl?j...
Oh no Taleo, the corporate ATS blackhole where resumes go to die. I rather not apply with companies that use Taleo for various past bad experiences. The first being the resume and all the details that I type in Taleo goes into HR oblivion. The problem of job applicant tracking & recruitment is not yet solved.
I've recently been through a number of these damn things and have found SmartRecruiters[0] to be pretty solid. Clean UI and easy application flow. The companies using it have been good about actually responding to applications as well, which is always nice.
How are you measuring those metrics on real devices ? Do you use the Chrome tracing timeline ? I wrote a tool called http://github.com/axemclion/browser-perf that does something similar, so was curious !!
Join the Nordstrom.com Web Performance Team! We believe that with our talented engineers, smart technology, and passionate customers we can deliver the best retail experience on the web. We’re looking for UI, Fullstack, & Node engineers to help us re-architect and refine our customer-facing UIs and supporting services. If it has performance impact, we care about it. You’ll enhance our existing applications and help drive the future direction of the stack and architecture that powers nordstrom.com.
Thanks for posting your findings - very useful data. It would be interesting to see the Webpagetest waterfalls in greater detail if you're able to share that.
You planning to use your resource hints to enable server push at CDN edge?
Server push at the edge is problem atm. Current push semantics require the HTML document say which resources to push. That's an issue if you're serving assets off a CDN domain.
Asset domains make less since with h2 from a performance perspective but there are still security concerns that need to addressed.
Good point if you're using push for page content that varies, like images in the the 99designs portfolio and gallery. That gets into dynamic caching territory.
As a first step, I'm focused on using push to cut latency between TTFB and processing of render-blocking static assets. Serving those from same domain as the base page, it should be easy for origin to supply edge with the list of resources push. Either in the HTML or with the `link` response header. It also means my critical assets are not longer behind a separate DNS lookup.
In the design gallery, this type of push approach could help you regain control of loading priority and get your fonts loading before that wall of images.
The priority queue isn't the issue. In fact the priority queue is what kept our first paint times tanking because browsers prioritised render blocking resources instead of images.
The issue was due to the variance of image size. An image that is significantly larger than the page average will be loaded slower since all images get an equal share of bandwidth (priority).
We could further improve first paint times by pushing render blocking resources but we'd need to be serving those resources off the 99designs domain (with current push implementations). This opens us up to a class security issues we avoid by having an asset domain i.e. types of reflected XSS and serving cookies on assets.
For now we'll wait for the webperf working group to address the limitations with server push semantics.
Interesting note on the impact of image size variation on queue, thanks for elaborating.
Serving those resources from the 99designs domain is worth a look. I considered the cookies and security trade offs as well. I found H2 compressed cookies enough to perform better than a separate cookieless domain for static assets, due to the DNS savings. DNS times can be bad at high percentiles. Reflected XSS addressed with a Content Security Policy. But I'm fortunate to have user base that supports CSP well.
