Menu Search
Jump to the content X X
SmashingConf London Avatar

We use ad-blockers as well, you know. 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 London, dedicated to all things web performance.

The Front-End Performance Challenge: Make Your Site Blazingly Fast And Win Some Smashing Prizes

Not too long ago, front-end performance was a mere afterthought. Something that was postponed to the end of a project and that didn’t go much beyond minification, asset optimization, and maybe a few adjustments on the server’s config file. But things have changed. We have become more conscious of the impact performance has on the user experience1, and the tools and techniques that help us cater for snappy experiences have improved and are widely supported now as well.

It's time for a new challenge! Are you ready?2
It’s time for a new challenge! Are you ready?

Time to roll up your sleeves and make use of these possibilities! A while ago, we challenged your coding skills in the CSS Grid Challenge3, now we have something new to tickle your brains: The Front-End Performance Challenge. A perfect opportunity to apply everything you’ve learned about Service Workers, HTTP/2, Brotli and Zopfli, resource hint and other optimization techniques in one project. And, of course, there’ll be a smashing prize waiting for one lucky winner in the end.

The Challenge Link

Show off the performance of your site or your project — use everything you can to make your website perform blazingly fast! Please note that the final visual appearance should be identical before and after (font loading might differ and reflows are acceptable but should be kept to a minimum). You can use this checklist4 as a guideline and dive into performance optimization for everything from image assets and web fonts delivery to HTTP/2 and Service Workers.

The deadline is the 24th of November, 2017.

Here are a few things you can do to enhance your chances of winning:

  • Optimize as much as you can: We’ll be looking into Lighthouse and WebPageTest as well as the complexity of the site you’re working on.
  • You don’t have to optimize a personal blog: The more advanced the project is, the better chances of winning you have.
  • The most critical metrics are the first meaningful paint and the time to interactive.

So, What Can You Win? Link

After the deadline has ended, we’ll award a smashing prize to one lucky winner. It has to do with web performance, but see for yourself:

  • A roundtrip flight to London,
  • Full accommodation in a fancy hotel,
  • A ticket to SmashingConf London 20185, a new front-end, performance-focused conference, taking place Feb 7–8, 2018,
  • A Smashing workshop of your choice.

Join In! Link

Ready to take on the challenge? We’d love to see how you’ll tackle it!

What You Need To Deliver Link

  • Performance results before and after (using WebPageTest and Lighthouse).
  • A brief description/strategy of the work you did.

Once you have everything together, please send us your entry to The deadline is the 24th of November. The winner will be announced on the 4th of December, 2017.

Resources To Get Started Link

Last but not least, here are some resources to kick-start your performance optimization endeavor. Have fun!

  • Improving Web Fonts Delivery
    Zach Leatherman’s “Comprehensive Guide To Font Loading Strategies6” explains the ins and outs of approaches such as FOUT with a Class and Critical FOFT.
  • Improving CSS Delivery
    Dean Hume summarized an easy way to inline critical CSS7 into the <head> of your pages, even when your site contains different templates.
  • Getting Started With Service Workers
    Lyza Danger Gardner wrote up her gotchas and the bugs she ran into when making a Service Worker8. Also be sure to check out her “Pragmatist’s Guide to Service Workers9,” a GitHub repository with Service Worker code examples.
  • Dealing With Third-Party Scripts
    Damien Jubeau shares useful tips and techniques to deal with third-party content10 such as social network widgets, advertising and tracking scripts, and explains their impact on performance.
  • Moving To HTTP/2
    HTTPS is a must for websites. Vladislav Denishev’s complete guide to switching from HTTP to HTTPS11 helps you master the transition.
  • HTTP/2 Server Push
    Server Push allows you to send site assets to the user before they’ve even asked for them. Jeremy Wagner’s comprehensive guide to Server Push12 explains everything from how it works to the problems it solves.
  • Progressive Web App
    Progressive Web Apps can replace all of the functions of native apps and websites at once. Ada Rose Edwards summarized do’s and don’ts on how to make them13.
  • Brotli/Zopfli Compression
    Do you already use Brotli or Zopfli compression? The lossless data format Brotli14 appears to be more effective than Gzip and Deflate, while Zopfli15 is a good solution for resources that don’t change much and are designed to be compressed once and downloaded many times.
  • Resource Hints
    Resource hints16 are a good way to warm up the connection and speed up delivery, saving time on dns-prefetch, preconnect, prefetch, prerender and preload.
  • CDNs Supporting HTTP/2
    Concerns over performance have long been a common excuse to avoid security obligations. In reality, TLS has only one performance problem: It’s not used widely enough. Everything else can be optimized17.
  • Responsive Images
    Eric Portis wrote up how to get responsive images right18 — with <picture> and srcset.
  • Caching
    If you need a little refresher on caching, Ilya Grigorik19 and Jake Archibald20 have got you covered.
  • Optimizing For First Meaningful Paint
    First Meaningful Paint21 is the paint after which the biggest above-the-fold layout change has happened. The lower its score, the faster that the page appears to display its primary content.

With all of this, you should be well-equipped for the challenge. Need a checklist? Here we go.22 We’re already looking forward to your submissions and to hearing your optimization stories!


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

Cosima has been an editor at SmashingMag since 2013. Whenever she's not writing articles for the bi-weekly Smashing Newsletter or the Quick Tips series, she’s probably working on a new Smashing eBook.

  1. 1

    Can I participate with an existing wordpress site?

  2. 3

    Since we built our new site/platform with performance in mind, we have no before. I guess we’re out.

  3. 4

    Should I break my site first in order to participate? ;)

  4. 5

    It seems odd that you have to deliver the pre performed solution to participate!?!?

    • 6

      Vitaly Friedman

      October 26, 2017 10:55 am

      You don’t have to deliver a pre-performed solution, but we should be able to validate that you indeed did some work to improve performance. :-)

      • 7

        Hi Vitaly… – if I do not present a pre-performed solution, how will the panel be the judge of which areas we improved?!

  5. 8

    May I ask some quesions before we consider submitting?

    1) Are entries deemed worth submitting, that *don’t* use most of the latest and fancy techniques outlined above, but *still* are fast (at least on our POV)?

    2) Is first page load the only metric, or are you actually looking at the app and how it performs when doing real stuff? I think page load is a bit overrated esp. for SPAs, since the page is loaded *one time* for the whole session (and I guess < 1sec is fast enough). So is that really more important than *actual* app performance?

    3) You say that you look at Lighthouse, and you say that "The most critical metrics are the first meaningful paint and the time to interactive". Is it the only measuremt, or do you take an actual look at the page with more reliable tools?

    Well … because I just tested with Lighthouse, and it's output is so plain wrong – *way off* – it is not even funny. It says 3000ms for "meaningful first paint" (what does "meaningful" mean anyways …) and 6000ms for interactive. Well, but in reality, its actually more like around 700ms for both … and timings do wildly differ from page load to page load as well. WebPageTest does it better, though.

    And, Lighthouse gets it wrong in some other places as well:

    * For users on slow connections, external scripts dynamically injected via `document.write()` can delay page load by tens of seconds.
    While we in fact use doc.write, we do NOT use it for scripts, but rather for a single CSS file with a dynamic URL that *has* to be calculated on the client. And in our case, doc.write is simply the easiest and most efficient way to do it. And even if it was faster using delayed techniques I would not care since it would introduce a *very* ugly FOUC then, so sometimes performance is not everything.

    * Does not uses Images with appropriate aspect ratio
    Wrong. No idea why lighthouse thinks we do

    And we get bad PWA score, because well, while our app is a SPA, it is not a PWA, and it makes not too much sense to convert it into one at least at the moment. For us, it is simply not worth the effort when there are more important things to do.

    Still interested? At least it is one of the more complex things (SPA with properly(!) implemented REST API, client has about 50k LOC alone)

  6. 9

    Marco Hengstenberg

    November 7, 2017 4:04 pm

    E-Mail sent. 😎


Leave a Comment

You may use simple HTML to add links or lists to your comment. Also, use <pre><code class="language-*">...</code></pre> to mark up code snippets. We support -js, -markup and -css for comments.

↑ Back to top