Steve Souders

As far as Google goes, the easiest place to get better end-user latency/performance (2x-3x) is ... fixing the JavaScript.

I'm being totally serious. Backends are generally fast, and the backend engineers are performance-minded.

Front end engineers are not as cognizant of performance (somewhat necessarily, since arguably they have a harder problem to solve). Back in the mid-2000's, Gmail/Maps/Reader days Google had a lot of great JS talent, but it seems to have ceded some of that ground to Facebook and Microsoft.

If you have heard Steve Souders speak, he always mentions that he was a backend guy. Until he actually measured latency, and realized that the bottleneck is the front end. That was at Yahoo, but it's very much true for Google too.

http://stevesouders.com/bio.php

I would like to see a machine learning system rewrite JavaScript code to perform better and make UI more usable. I believe that's beyond the state of the art now, but it's probably not out of the question in the near future.

-----

As far as scheduling that was just one example of an important systems problem that hasn't been solved with machine learning. Not saying it can't be, of course. Just that this is a research direction and not a deployed system.

It's also important to note that there are plenty of other feedback-based/data-driven algorithms for resource management that are not neural nets. If neural nets work, then some simpler technique probably works too.

I did some research on this a few years ago [1], and Steve Souders recently re-ran the test with the latest http archive data [2]. Given the percentages, I'm still not convinced that it makes sense to reference jQuery or any other library from a shared CDN.

That said, you also need to be careful with concatenation. It's tempting to go for a 'concatenate everything into one file' approach, but that can be suboptimal. When you've got a large library like jQuery that changes infrequently, concatenating that with your constantly-evolving application code results in your users paying the download cost for jQuery every time you make a change (albeit without the connection overhead). Instead, it make sense for some applications to bundle third party libraries into one file, and the application code into another.

As I said in my original article, the most important thing you can do to improve the performance of your site is to measure client-side performance from your real user traffic, establish a baseline and only then try various techniques and see which ones have the greatest impact for your site and your visitors. There are various techniques that /might/ help, and some are more universal than others, but you won't know for sure if a change helped or hindered if you can't look at your stats.

[1] http://statichtml.com/2011/google-ajax-libraries-caching.html
[2] http://www.stevesouders.com/blog/2013/03/18/http-archive-jquery/

I got the headers by right-clicking on some image links and seeing what I got. Can't reproduce it right now. Apologies if there was a brain freeze moment.

I've been thinking about how to best do this over the weekend and the approach I cam up with is this: Use Cloudfront (Amazon's CDN) and use custom CNAMES for S3 buckets. An S3 bucket would be an image library (say tango.stdicon.com) and so the subdirectories of this Cloudfront subdomain would be the images sizes (tango.stdicon.com/48/foo).

This sets up a nice CDN with proper headers and a scalable way to add more libraries (just add subdomains).

This also has the "very advanced use-case" advantage: website owners can CNAME to the same library subdomain multiple times (say assets1.mysite.com assets2.mysite.com and assets3.mysite.com) and let the browser download images in parallel. See these two refs:

1. http://www.stevesouders.com/blog/2008/03/20/roundup-on-parallel-connections/

2. http://www.websiteoptimization.com/speed/tweak/parallel/

Would love to talk more if you're interested. Email address "encoded" in my profile page.

I've been working in the performance industry (focusing on front-end performance and UX) for 15 years. Some resources you might find helpful:

• Steve Souders' books 'High Performance Web Sites' & 'Even Faster Web Sites' – https://stevesouders.com/ – Steve literally wrote the book(s) on performance and is widely considered the godfather of the industry.

• WPO stats – https://wpostats.com/ – Case studies and experiments demonstrating the impact of performance optimization on UX and business metrics

• performance.now() talks – https://www.youtube.com/c/WebConferencesAmsterdam/videos – PerfNow is the only annual global conference dedicated to performance. You can watch past talks on their YouTube channel.

• Intro to Web Performance – https://support.speedcurve.com/docs/psychology-of-web-performance – This is a collection of introductory articles covering topics like the psychology of sit speed to Core Web Vitals to how to create a performance culture in your organization.

Separate domains for CSS and images files are primarily intended to overcome certain (old?) browsers' limitation on the number of concurrent connections to a single domain [1][2]. Cookieless domains can only help you if you have supermassive cookies. Keep those to a special subdomain, if you really need to have them. But you probably don't.

There is no one rule of thumb for performance. Generally, inline everything that's small enough to inline. If it's big enough such that caching a separate file will help you on subsequent page loads, then put it in a separate file.

Test and measure. If you can't measure the difference, it doesn't matter. If you don't measure the difference, the rule you are following probably isn't helping you.

[1] http://www.stevesouders.com/blog/2013/09/05/domain-sharding-revisited/

[2] http://www.stevesouders.com/blog/2008/03/20/roundup-on-parallel-connections/

Step 1: Learn to use the CSS profiler in Chrome.

Also, here are some articles I found in my links list:

CSS Stress Tester Bookmarklet (Copy into a bookmarklet. Then it will tell you the rules that are causing the most lag.)

javascript:(function(d){var s=d.createElement('script');s.src='http://andy.edinborough.org/Demos/css-stress/stressTest.js?_=+Math.random();var es=d.getElementsByTagName('script')[0];es.parentNode.insertBefore(s,es);var doit=function(){if(window.stressTest){stressTest.bookmarklet();}else{setTimeout(doit,100);}};doit();})(document);

Old but still relevant I think: http://www.stevesouders.com/blog/2009/06/18/simplifying-css-selectors/
Text makes CSS slow (don't render too much): https://news.ycombinator.com/item?id=2232212
In general, following good guidelines might help: https://github.com/csswizardry/CSS-Guidelines