Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Web Development Reading List #170: Hamburger Alternatives, Libsodium In PHP And Choosing Profit

As web developers, we need to rely on our knowledge, and choosing solutions we’re already familiar with is often the most convenient approach to solving a problem. However, not only technology is evolving but also our knowledge of how to use it.

For a while, we thought it’s best to use base64 encoding for inlining assets into CSS files, for example, and that loading JavaScript asynchronously will make websites faster. With more evidence and research, however, we came to realize that we were wrong. We should take this as an occasion to remind ourselves to question our habits and from now on ask ourselves if the solution we have in mind for a given problem really is still the best one we could choose.

Further Reading on SmashingMag: Link

Concept & Design Link

Alternatives to Hamburger Menus7
Labels combined with icons could be an alternative to the hamburger menu. Levi Kovacs explores what else you can use8 instead. (Image credit9)

Security Link

Web Performance Link

JavaScript Link

Work & Life Link

Depend less on each other18
Basecamp’s Jason Fried advocates for separating the gears and depending less on each other19 in a company.

Going Beyond… Link

And with that, I’ll close for this week. If you like what I write each week, please support me with a donation21 or share this resource with other people. You can learn more about the costs of the project here22. It’s available via email, RSS and online.

— Anselm

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22

↑ Back to top Tweet itShare on Facebook

is a freelance front-end developer who cares about sustainable front-end experiences and ethical choices in life. He writes the WDRL, and is co-founder of the event platform Colloq.

  1. 1

    Harry Roberts’s article does a great job explaining why base64 encoding is a bad idea — for large images like his 1440×900px example file. It’s quite a leap to use that data to label the technique “a huge anti-pattern,” when the primary use case for it is to inline small (like <10k) files. The threshold where the benefits of encoding and inlining outweigh the costs depends on various site-specific factors such as how many cookies are set on a domain, since these must all be uploaded in their entirety via the uncompressible request headers for every HTTP request. The lesson here should be to test and find that threshold for your application, not to totally discard the technique.

    • 2

      Thank you – I came here to specifically say the same thing. When used effectively, and when you know how the technique improves your performance, it can be a useful tool.

  2. 3

    “…loading JavaScript asynchronously will make websites faster. With more evidence and research, however, we came to realize that we were wrong.”

    • 4

      Nevermind, the article is in the second javascript link.

      However I don’t think the article is saying that using async is wrong, just that it is no longer a necessity in browsers that use V8. The reason being is that V8 now allows parser blocking scripts to be processed by a background thread, the same as what happens when you use async or defer. The article doesn’t mention if this is the case in non-V8 browsers so I wouldn’t get rid of it just yet until more research is done.

      • 5

        Josh, you’re right. It’s not about base64 is always bad and has no use-case and it’s not about async being bad. It’s about us who need to realize that we shouldn’t use base64 for webfonts, inline images, etc, and it’s up to us to realize that loading all JavaScript asynchronously isn’t going to solve our performance problems but only shifting them. Instead, we need to only use the appropriate technique when it’s not shifting the issues to another point or causing new ones.

  3. 6

    Nice, thanks writing this up. I’m especially interested
    in where you’re headed regarding post-

  4. 7

    I disagree with the takeaways of the base64 performance article. His example was a great demonstration of base64 poorly implemented.

    Large or repeating (responsive query) images., should not be base64’d into the CSS. You also shouldn’t place non-critical, large, or situational images in the CSS.

    The best use of Base64 is for site-wide SVGs such as icons and preloading above-the-fold elements like the site logo. While base64 certainly isn’t as “efficient” as loading images normally, it certainly helps with creating the illusion of speed. With proper base64 use you can make the above-the-fold content appear to load instantly and in less than a second.

    The test you did was insane. Shame on anyone base64ing a 1440px by 900px header. But seriously, you couldn’t have done a more biased test. How about you do a test where you base64 a SVG logo, some SVG icons and compare the results on 3G mobile?

    And for the record, multiple requests are a performance killer for mobile. 18kb extra download is nothing compared to the time to do a new request.


↑ Back to top