Comment by compumike | Hacker News Reader

Comment by compumike | Hacker News Reader

(Disclosure: I'm Carter's desk-neighbor at Triplebyte.)

I think there's actually a middle ground where you can utilize some of the more modern techniques to actually do better than the pure static pages approach, while still using normal browser-based page navigation.

As a personal challenge, I wanted to see what could be done about performance for a recently-launched side project: the Ultimate Electronics Book [1], which is a free online electronics textbook that has interactive circuit simulations built in. Here's what I ended up with in the spirit of progressive enhancement:

1) Static site generated by Jekyll (with a few custom plugins) and hosted on S3+CloudFront with appropriate caching headers

2) No JS blocking initial page load

3) No custom CSS fonts to download

4) Prefetch and dns-prefetch headers

5) Tell browser to preload next page on link mouseover (instant.page)

6) Lazy-loading of schematic images (lozad / IntersectionObserver) when they're nearly within scroll range

7) Client-side instant search index (awesomplete + custom code)

8) Tooltips with section descriptions on internal navigation links (balloon.css)

There are heavier components to this too:

1) Equation rendering (MathJax) is heavy and slow but starts rendering the equations after initial page load, and prioritizes equations within the first few thousand vertical pixels first. (Sadly I need the full power of MathJax; the faster KaTeX engine can't handle all of my equations.)

2) The schematic editor / client-side circuit simulation engine is an entirely separate SPA. (But by modern standards it's probably a smaller payload than many sites today use for serving totally static content with a few forms.)

The result is a site that loads pretty darn fast -- maybe faster than a static page due to preloading and lazy-loading -- but packs in a lot of functionality appropriate to the problem. Any techniques I'm missing?

[1] https://ultimateelectronicsbook.com/

Loads about as fast as I'd expect from a static site.

Hover is a bit messy. When I move my mouse down the table of contents, the tooltip obscures the next chapter title, and sometimes grabs the click as well.

Back button handling seems to be buggy. If I click from the table of contents to a chapter, then hit back, then click to another chapter, then hit back again and do that a few times, the history becomes filled with many instances of table of contents.

Also something weird happens when I click a chapter link. Like, the whole table of contents scrolls for an instant and then I see the chapter.

Edit: if I disable JS, all these problems go away and the site feels just as fast. So good job on that :-)

Thanks for the feedback. Tooltip hover on TOC is annoying -- need to think about that... The scrolling on TOC click was intentional as I wanted to highlight the section you clicked and center it if you do go back to TOC to "remember you place" in the book, but maybe I overdid it here.

MathJax can render server-side if you want to speed that up: https://github.com/pkra/mathjax-node-page

For the love of god, please, never, ever do lazy image loading. As a user, I expect the page to be 100% complete when the progress bar in my browser disappears.

Note that some browsers are planning to start doing lazy image loading themselves. See https://groups.google.com/a/chromium.org/forum/#!msg/blink-d...

As another lazy loading hater, I think that's a good thing. If a website wants to use lazy loading, it should be handled by the browser, rather than using a custom JavaScript code that the webpage requests. There being one universal method means that there is only one setting that I need to disable to avoid lazy loading. Currently I use a userscript based on heuristics to load all lazy-loading images, but it often doesn't work, as websites use a wide variety of methods to implement it.

Also, incorporating lazy loading into the browser would make NoScript viable in far more websites. Most of the time the only reason why I consider enabling JavaScript for a website is to view lazy-loading images, everything else works good enough (or better) without JavaScript. With lazy loading being done by the browser, almost no website I come across would have this problem, unless they choose to intentionally break without Javascript. Of course, this wouldn't be a problem in the first place without lazy loading, but alas, here we are, with most websites using it.

The NoScript point is a good one.

I don't necessarily expect browsers that implement it to have a user-visible way to disable lazy loading, though, so you may be out of luck there. You _might_ be able to create userscripts that force non-lazy loading on all potentially-lazy elements by using the opt-out frob browsers would add for websites.

I would hope that Firefox would have an about:config setting to disable it, but with the direction they are going, removing customizability left and right, who knows. Normally I would have also expected addons to disable this browser-side lazy loading, but since Firefox 57 they are more like glorified userscripts, so they probably wouldn't be able to.

On Chromium side, maybe Vivaldi and the like could provide the option to disable it, if it is not too difficult of a change on Chromium. But for sure, I would be very surprised if Chrome offered that option, so not much of an improvement for Chrome users, or maybe even a deterioration if sites start to adopt it even more, now that it is supported natively.

Firefox does not have plans to implement lazy loading at this time, fwiw. If we do, yes, I expect we will have a way to disable it.

> Currently I use a userscript based on heuristics to load all lazy-loading images, but it often doesn't work, as websites use a wide variety of methods to implement it.

Would you mind sharing this script? I use NoScript heavily and something would certainly be better than nothing in a lot of cases.

Mine was based on the answer here[1], now I see that the script in the answer was edited after I started using it. I should try the new version to see if it works better.

My experience with the previous version was that while it sometimes worked, on some websites it broke more than it fixed; and when I modified the script to account for that issue, it broke something somewhere else, as websites use very different methods to display images that I couldn't imagine (hence I welcome a standard way of doing it). So I ended up using the script on a whitelist basis instead. Maybe the new version works more properly, so that I can enable it globally again.

[1] https://superuser.com/questions/938345/load-all-images-even-...

> Any techniques I'm missing?

Not sure what would make it faster, but thought I'd report that with Safari 10.1.2 the site is currently broken for me. The MathJax equations never load, and I get text mixed with spinning circles.

Javascript Console contains: [Error] SyntaxError: Cannot declare a let variable twice: 'e'. (anonymous function) (compiled_postbody-544dfbba31d691e567064ba96e9eec29f4257fe5909a4ddb5218cd36d823e215.js:1).

Thanks for the bug report. I’ll try to reproduce.

Edit: I'm unable to reproduce this with Safari 12.1.1. Did some searching and this is a known bug in Safari 10 which was resolved in 2017: https://github.com/webpack-contrib/uglifyjs-webpack-plugin/i... / https://bugs.webkit.org/show_bug.cgi?id=171041 -- I will try to workaround.

I use Jekyll for my personal site and it renders MathJax, and even MusicXML with JS, amongst other small things. It's great, all static.

https://github.com/nixpulvis/nixpulvis.github.io

Interesting. Am I missing something? I went to https://nixpulvis.com/math/01-fibonacci and it appears to be effectively the same as what I have for MathJax -- pushing the raw LaTeX commands into a specially-labeled HTML element, and then loading the MathJax JS from cdnjs.cloudflare.com in order to process and render them client-side.

Yep, that part is pretty easy, and not too bad in terms of fallback while loading. I love how easy it is most of the time to write nice looking math.

Reply on news.ycombinator.com