5 ms·

(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 ac

(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/ https://ultimateelectronicsbook.com/

cousin_it 7y ago
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 :-)
- compumike 7y ago
  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.
  - deleted 7y ago
    [deleted]
nixpulvis 7y ago
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 https://github.com/nixpulvis/nixpulvis.github.io
- compumike 7y ago
  Interesting. Am I missing something? I went to https://nixpulvis.com/math/01-fibonacci 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.
  - nixpulvis 7y ago
    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.
bfirsh 7y ago
MathJax can render server-side if you want to speed that up: https://github.com/pkra/mathjax-node-page https://github.com/pkra/mathjax-node-page
nkurz 7y ago
> 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).
- compumike 7y ago
  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/issues/92#issuecomment-324818437 https://github.com/webpack-contrib/uglifyjs-webpack-plugin/i... / https://bugs.webkit.org/show_bug.cgi?id=171041 https://bugs.webkit.org/show_bug.cgi?id=171041 -- I will try to workaround.
grishka 7y ago
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.
- bzbarsky 7y ago
  Note that some browsers are planning to start doing lazy image loading themselves. See https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/jxiJvQc-gVg/wurng4zZBQAJ https://groups.google.com/a/chromium.org/forum/#!msg/blink-d...
  - lnl 7y ago
    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.
    - bzbarsky 7y ago
      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.

cousin_it 7y ago

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 :-)

compumike 7y ago
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.
- deleted 7y ago
  [deleted]

nixpulvis 7y ago

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 https://github.com/nixpulvis/nixpulvis.github.io

compumike 7y ago
Interesting. Am I missing something? I went to https://nixpulvis.com/math/01-fibonacci 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.
- nixpulvis 7y ago
  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.

bfirsh 7y ago

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

nkurz 7y ago

> 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).

compumike 7y ago
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/issues/92#issuecomment-324818437 https://github.com/webpack-contrib/uglifyjs-webpack-plugin/i... / https://bugs.webkit.org/show_bug.cgi?id=171041 https://bugs.webkit.org/show_bug.cgi?id=171041 -- I will try to workaround.

grishka 7y ago

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.

bzbarsky 7y ago
Note that some browsers are planning to start doing lazy image loading themselves. See https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/jxiJvQc-gVg/wurng4zZBQAJ https://groups.google.com/a/chromium.org/forum/#!msg/blink-d...
- lnl 7y ago
  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.
  - bzbarsky 7y ago
    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.