Front page loads 40MB+ of content on initial load.

[NickCraver]

The client-side paged loads work for very small scale, but not for anything with a decent post count. Maintaining this would mean loading lots of resources on the client they'll very likely never see as well as create an ever-increasing initial page size with slower load.

Currently loading http://stackexchange.github.io/blog/ results in my browser loading 43.9MB of content over 1.6 minutes, including things like http://stackexchange.github.io/blog/images/category/podcasts.jpg (14.5MB), http://stackexchange.github.io/blog/images/StackExchange-12.jpg (11.7MB) and http://stackexchange.github.io/blog/images/StackExchange-19.jpg (11.6MB). Even though the majority of the bytes are currently made up of a few images, there are still hundreds of HTTP requests happening.

I think for this to be realistic on a client performance perspective, it'll need to use Jekyll's built-in pagination generation.

Related to this: the hero images need to be sized to something reasonable for a client to load, the http://stackexchange.github.io/blog/images/category/podcasts.jpg example is a 5560x3707 14.5MB image of which only a 667x150px window is seen for the hero image (to be safe on assumptions: we can double that for high-dpi to 1334x300).

[JonHMChan]

Overall, there's very large room for improvement on the performance front, for all the reasons you've mentioned. I agree in its current state, it's flatly unacceptable on performance.

The current JS implementation for pagination is an experiment to see if there's a possible alternative to Jekyll's native pagination. Using the native pagination with the number of posts at hand, build time was taking up to 10mins and there's lack of support for pagination on posts by category/tags. The JS implementation definitely fixes those problems, but at a huge cost to performance on initial load for this many posts. What I want to try next is a blend of the two methods and tweaking the number of posts displayed initially to see if there's a reasonable middle ground.

When it comes to images, they definitely need to be scaled down and compressed. It's simply something I haven't gotten around to just yet.

[JonHMChan]

AJAX Pagination #19 does a lot to solve this problem. Still need to work on compressing images.

[JonHMChan]

Separating the image compression and pagination issues. Pagination is fixed. Image issue is now #20