Improve page load times

[abhishekkumar2718]

Let's measure the page load times with network cache disabled (as that would be close to the experience of a first time visitor to the site)

Page	Requests	Data Transferred	Page Load Time
Home page	44	2.68 Mb	14.87s
About Us	38	4.51 Mb	19.71s
Past Editions	44	11.32 Mb	1.37m
Talk Archives	114	4.03 Mb	24.50s
Team	53	1.79 Mb	10,6s
Partners	41	4.67 Mb	25.40s
Contact	43	2.80s	15.20s

While the page sizes are not bad, we should strive to reduce the number of requests. Firefox and Chrome allow six connections at a time and bottlenecks network speed.

Admittedly, I am on a shitty network connection (with 200kbps average speed). Is this a universal experience?

PageSpeed Insights: Mobile - 22/100, Desktop: 52/100

PingDom: 70/100 (Grade D)

Improvements

With #91 merged, Our PageSpeed Insight scores have improved to 34 (mobile) and 91 (desktop) and Pingdom score improves to 72 (Grade C).

With #95 merged, Our PageSpeed Insight scores have improved to 36 (mobile) and 94 (desktop).

Performance for the home page is much worse than any other page on mobile devices because the time taken to execute title.js

[abhishekkumar2718]

I have three independent, substantial proposals that might take us 2-3 weeks to implement.

I am more driven by learning new skills than user experience improvement, as TEDx offers (for me) an opportunity to work on a "production-grade" project.

Move to a static site generator

Static Site Generators (like Jekyll, Hugo) are applications that take site content, apply it to templates, and generate a structure of purely static HTML.

Our web pages (except the theme page) are fairly formulaic. Each of them has a header and footer. Within a page, for example, past editions, each edition has same HTML structure but with different titles and content.

We have also been using javascript as a replacement for templating (for example, the salon faq is generated by loading questions and generating javascript). Using SSG templates would be similar to compiling the HTML pages once, instead of incurring the cost of generating the HTML on each page load.

While the performance improvement would be (admittedly) marginal, using a SSG would improve developer productivity and minimize friction for build tasks.

Move to a better hosting service

We are currently using Github pages as our hosting service. It does exactly what it says on the tin, nothing more and nothing less. However, using Github pages is slow because:

• We serve local assets from Github's servers (that are in US) which incurs a round trip time of 200ms.
• Lack of caching control.
• Manual asset optimization.

Moving to a service like Netlify would also provide additional benefits like deploy previews, better SEO rankings, and better gzip compression.

Optimize images

JPG is a lossy compressed file format, which attempts to make the file size smaller by reducing details in the image. PNG is an image format that supports lossless compression by default.

While we have been using JPG and PNG images interchangeably, the image formats have a well-defined use case: JPGs for Photos, PNG for Graphics. For example, converting img/bg/about.png to a JPEG file reduces file size from 2.8 MiB to 756.1 Kib (which is nearly one-fourth of the original size).

Additionally, we need to manually resize images where the largest possible final size is known. For example, the sponsor's images in the partners' page are constrained to a height of 200px. Resizing the original to 200px would reduce the file size to be nearly one-ninth of the original size! (Note: Netlify can take care of image resizing on the server-end).

If we opt for an SSG, optimizing images should be a part of the build process. Otherwise, to minimize the friction we should create a script with takes path to the image, format, and dimensions as parameters, optimizing image as requested.