Daily Link Aggregating from the Best Design & Showcase Sites
16,930 Links to Search From

10 Best Tools & Tips for Choosing a Website Color Scheme

Posted by Design Shack - 3 mins ago
Finding the perfect color combination for a website can be a challenging task, especially when you’re trying to make a particular design fit in with a client’s requirements. We’ve picked out a few great color scheme generating tools for you to easily create the perfect palette! If you’re stuck trying to find the perfect color...

5 Reasons to Fire Your Client

Posted by Web Designer Depot - 4 hours ago
I like money. Clients give me money (when everything goes right). Ergo, therefore, and hopefully…clients = money, more clients = more money—I’m actually pretty terrible at math. When you first start out as a freelance designer or even agency. it can be pretty tempting to say “yes” to every single client that comes your way. […]


Posted by cssdsgn - 7 hours ago

The Future of Design in Start-Ups 2017

Posted by One Page Love - 22 hours ago
Colorful One Pager with lovely illustrations calling for submissions for the annual Future of Design survey by NEA. We featured their 2016 Survey Results – presented in a smart long-scrolling One Page website of course ????

5 Tips for Designing the Perfect eBook Cover

Posted by Design Shack - 1 day ago
People are going to judge your eBook by its cover. The cover is the first impression and first chance you have to hook a reader. It has to be visually appealing, include lettering that’s easy to read and entice users to download (and read) your book. The perfect eBook cover stands out from all the...

Christine Phung

Posted by cssdsgn - 1 day ago

Elutine Production

Posted by Divine CSS - 1 day ago
Web Design

Vedett Gazett

Posted by Divine CSS - 1 day ago
Submit Your Story

Piero Milano

Posted by Awwwards - 2 days ago
Piero Milano Gioielli is synonymous with excellence and prestige, creating the most original lines of jewellery.


Posted by CSS Design Awards - 3 days ago
Die-hard Metroid fans collaborate on creating a website to spread the word about one of the most beloved sagas in the gaming world.


Posted by cssdsgn - 1 hour ago

The Gigi

Posted by Awwwards - 4 hours ago
The Gigi project comes from the desire to think beyond and overcome the widespread conformism of Fashion Industry, designing something new but yet immortal.

Front-End Developers Are Information Architects Too

Posted by 24 Ways - 8 hours ago

Francis Storr delves deep into our HTML and considers if the choice and application of semantics in front-end code contributes in a meaningful way to the information architecture of our sites. Perhaps the true meaning of Christmas lies in the markup.

The theme of this year’s World IA Day was “Information Everywhere, Architects Everywhere”. This article isn’t about what you may consider an information architect to be: someone in the user-experience field, who maybe studied library science, and who talks about taxonomies. This is about a realisation I had a couple of years ago when I started to run an increasing amount of usability-testing sessions with people who have disabilities: that the structure, labelling, and connections that can be made in front-end code is information architecture. People’s ability to be successful online is unequivocally connected to the quality of the code that is written.

Places made of information

In information architecture we talk about creating places made of information. These places are made of ones and zeros, but we talk about them as physical structures. We talk about going onto a social media platform, posting in blogs, getting locked out of an environment, and building applications. In , Andrew Hinton stated:

People live and work in these structures, just as they live and work in their homes, offices, factories and malls. These places are not virtual: they are as real as our own minds.

We’re creating structures which people rely on for significant parts of their lives, so it’s critical that we carry out our work responsibly. This means we must use our construction materials correctly. Luckily, our most important material, HTML, has a well-documented specification which tells us how to build robust and accessible places. What is most important, I believe, is to understand the semantics of HTML.


The word “semantic” has its origin in Greek words meaning “significant”, “signify”, and “sign”. In the physical world, a structure can have semantic qualities that tell us something about it. For example, the stunning Westminster Abbey inspires awe and signifies much about the intent and purpose of the structure. The building’s size; the quality of the stone work; the massive, detailed stained glass: these are all signs that this is a building meant for something the creators deemed important. Alternatively consider a set of large, clean, well-positioned, well-lit doors on the ground floor of an office block: they don’t need an “entrance” sign to communicate their use and to stop people trying to use a nearby fire exit to get into the building. The design of the doors signify their usage. Sometimes a more literal and less awe-inspiring approach to communicating a building’s purpose happens, but the affect is similar: the building is signifying something about its purpose.

HTML has over 115 elements, many of which have semantics to signify structure and affordance to people, browsers, and assistive technology. The HTML 5.1 specification mentions semantics, stating:

Elements, attributes, and attribute values in HTML are defined … to have certain meanings (semantics). For example, the <ol> element represents an ordered list, and the lang attribute represents the language of the content.

HTML’s baked-in semantics means that developers can architect their code to signify structure, create relationships between elements, and label content so people can understand what they’re interacting with. Structuring and labelling information to make it available, usable, and understandable to people is what an information architect does. It’s also what a front-end developer does, whether they realise it or not.

A brief introduction to information architecture

We’re going to start by looking at what an information architect is. There are many definitions, and I’m going to quote Richard Saul Wurman, who is widely regarded as the father of information architecture. In he said an information architect is:

the individual who organizes the patterns inherent in data, making the complex clear; a person who creates the structure or map of information which allows others to find their personal paths to knowledge; the emerging 21st century professional occupation addressing the needs of the age focused upon clarity, human understanding, and the science of the organization of information.

To me, this clearly defines any developer who creates code that a browser, or other user agent (for example, a screen reader), uses to create a structured, navigable place for people.

Just as there are many definitions of what an information architect is, there are for information architecture itself. I’m going to use the definition from the fourth edition of Information Architecture For The World Wide Web, in which the authors define it as:

  • The structural design of shared information environments.
  • The synthesis of organization, labeling, search, and navigation systems within digital, physical, and cross-channel ecosystems.
  • The art and science of shaping information products and experiences to support usability, findability, and understanding.
Information Architecture For The World Wide Web, 4th Edition

To me, this describes front-end development. Done properly, there is an art to creating robust, accessible, usable, and findable spaces that delight all our users. For example, at 2015’s State Of The Browser conference, Edd Sowden talked about the accessibility of <table>s. He discovered that by simply not using the semantically-correct <th> element to mark up <table> headings, in some situations browsers will decide that a <table> is being used for layout and essentially make it invisible to assistive technology. Another example of how coding practices can affect the usability and findability of content is shown by Léonie Watson in her How ARIA landmark roles help screen reader users video. By using ARIA landmark roles, people who use screen readers are quickly able to identify and jump to common parts of a web page.

Our definitions of information architects and information architecture mention patterns, rules, organisation, labelling, structure, and relationships. There are numerous different models for how these elements get boiled down to their fundamentals. In his Understanding Context book, Andrew Hinton calls them Labels, Relationships, and Rules; Jorge Arango calls them Links, Nodes, And Order; and Dan Klyn uses Ontology, Taxonomy, and Choreography, which is the one we’re going to use. Dan defines these terms as:

The definition and articulation of the rules and patterns that govern the meaning of what we intend to communicate.
What we mean when we say what we say.
The arrangements of the parts. Developing systems and structures for what everything’s called, where everything’s sorted, and the relationships between labels and categories
Rules for interaction among the parts. The structures it creates foster specific types of movement and interaction; anticipating the way users and information want to flow and making affordance for change over time.

We now have definitions of an information architect, information architecture, and a model of the elements of information architecture. But is writing HTML really creating information or is it just wrangling data and metadata? When does data turn into information? In his book Managing For The Future Peter Drucker states:

… data is not information. Information is data endowed with relevance and purpose.

Managing For The Future

If we use the correct semantic element to mark up content then we’re developing with purpose and creating relevance. For example, if we follow the advice of the HTML 5.1 specification and mark up headings using heading rank instead of the outline algorithm, we’re creating a structure where the depth of one heading is relevant to the previous one. Architected correctly, an <h2> element should be relevant to its parent, which should be the <h1>. By following the HTML specification we can create a structured, searchable, labeled document that will hopefully be relevant to what our users need to be successful. If you’ve never used a screen reader, you might be wondering how the headings on a page are searchable. Screen readers give users the ability to interact with headings in a couple of ways:

  • by creating a list of headings so users can quickly scan the page for information
  • by using a keyboard command to cycle through one heading at a time

If we had a document for Christmas Day TV we might structure it something like this:

<h1>Christmas Day TV schedule</h1>
  <h2>Channel 4</h2>

If I use VoiceOver to generate a list of headings, I get this:

Once I have that list I can use keyboard commands to filter the list based on the heading level. For example, I can press 2 to hear just the <h2>s:

If we hadn’t used headings, of if we’d nested them incorrectly, our users would be frustrated.

Putting this together

Let’s put this together with an example of a button that, when pressed, toggles the appearance of a panel of links. There are numerous ways we could create a button on a web page, but the best way is to just use a <button>. Every browser understands what a <button> is, how it works, and what keyboard shortcuts should be used with them. The HTML specification for the <button> element says:

The <button> element represents a button labeled by its contents.

The contents that a <button> can have include the type attribute, any relevant ARIA attributes, and the actual text label that the user sees. This information is more important than the visual design: it doesn’t matter how beautiful or obtuse the design is, if the underlying code is non-semantic and poorly labelled, people are going to struggle to use it. Here are three buttons, each created with the same HTML but with different designs:

Regardless of what they look like, because we’ve used semantic HTML instead of a bunch of meaningless <div>s or <span>s, people who use assistive technology are going to benefit. Out of the box, without any extra development effort, a <button> is accessible and usable with a keyboard. We don’t have to write event handlers to listen for people pressing the Enter key or the space bar, which we would have to do if we’d faked a button with non-semantic elements. Our <button> can also be quickly findable: for example, in the same way it’s possible to create a list of headings with a screen reader, I can also create a list of form elements and then quickly jump to the one I want.

Now we have our <button>, let’s add the panel we’re toggling the appearance of. Here’s our code:

<button aria-controls="panel" aria-expanded="false" id="settings" type="button">Settings</button>

<div id="panel">
    <ul aria-labelledby="settings">
        <li><a href="…">Account</a></li>
        <li><a href="…">Privacy</a></li>
        <li><a href="…">Security</a></li>

There’s quite a bit going on here. We’re using the:

  • aria-controls attribute to architect a connection between the <button> element and the panel whose appearance it controls. When some assistive technology, for example the JAWS screen reader, encounters an element with aria-controls it audibly tells a user about the controlled expanded element and gives them the ability to move focus to it.
  • aria-expanded attribute to denote whether the panel is visible or not. We toggle this value using JavaScript to true when the panel is visible and false when it’s not. This important attribute tells people who use screen readers about the state of the elements they’re interacting with. For example, VoiceOver announces Settings expanded button when the panel is visible and Settings collapsed button when it’s hidden.
  • aria-labelledby attribute to give the list a title of “Settings”. This can benefit some users of assistive technology. For example, screen readers can cycle through all the lists on a page, so being able to title them can improve findability. Being able to hear list Settings three items is, I’d argue, more useful than list three items. By doing this we’re supporting usability and findability.
  • <ul> element to contain our list of links in our panel.

Let’s look at the choice of <ul> to contain our settings choices. Firstly, our settings are related items, so they belong in a structure that semantically groups things. This is something that a list can do that other elements or patterns can’t. This pattern, for example, isn’t semantic and has no structure:

<div><a href="…">Account</a></div>
<div><a href="…">Privacy</a></div>
<div><a href="…">Security</a></div>

All we have there is three elements next to each other on the screen and in the DOM. That is not robust code that signifies anything.

Why are we using an unordered list as opposed to an ordered list or a definition list? A quick look at the HTML specification tells us why:

The <ul> element represents a list of items, where the order of the items is not important — that is, where changing the order would not materially change the meaning of the document.

The HTML 5.1 specification’s description of the

    Will the meaning of our document materially change if we moved the order of our links around? Nope. Therefore, I’d argue, we’ve used the correct element to structure our content.

    These coding decisions are information architecture

    I believe that what we’ve done here is pure information architecture. Going back to Dan Klyn’s model, we’ve practiced ontology by looking at the meaning of what we’re intending to communicate:

    • we want to communicate there is an interactive element that toggles the appearance of an element on a page so we’ve used one, a <button>, with those semantics.
    • programmatically we’ve used the type='button' attribute to signify that the button isn’t a menu, reset, or submit element.
    • visually we’ve designed our <button> look like something that can be interacted with and, importantly, we haven’t removed the focus ring.
    • we’ve labelled the <button> with the word “Settings” so that our users will hopefully understand what the button is for.
    • we’ve used an <ul> element to structure and communicate our list of related items.

    We’ve also practiced taxonomy by developing systems and structures and creating relationships between our elements:

    • by connecting the <button> to the panel using the aria-controls attribute we’ve programmatically created a relationship between two elements.
    • we’ve developed a structure in our elements by labelling our <ul> with the same name as the <button> that controls its appearance.

    And finally we’ve practiced choreography by creating elements that foster movement and interaction. We’ve anticipated the way users and information want to flow:

    • we’ve used a <button> element that is interactive and accessible out of the box.
    • our aria-controls attribute can help some people who use screen readers move easily from the <button> to the panel it controls.
    • by toggling the value of the aria-expanded attribute we’ve developed a system that tells assistive technology about the status of the relationship between our elements: the panel is visible or the panel is hidden.
    • we’ve made sure our information is more usable and findable no matter how our users want or need to interact with it. Regardless of how someone “sees” our work they’re going to be able to use it because we’ve architected multiple ways to access our information.

    Information architecture, robust code, and accessibility

    The United Nations estimates that around 10% of the world’s population has some form of disability which, at the time of writing, is around 740,000,000 people. That’s a lot of people who rely on well-architected semantic code that can be interpreted by whatever assistive technology they may need to use.

    If everyone involved in the creation of our places made of information practiced information architecture it would make satisfying the WCAG 2.0 POUR principles so much easier. Our digital construction practices directly affect the quality of life of millions of people, and we have a responsibility to make technology available to them. In her book How To Make Sense Of Any Mess, Abby Covert states:

    If we’re going to be successful in this new world, we need to see information as a workable material and learn to architect it in a way that gets us to our goals.

    I believe that the world will be a better place if we start treating front-end development as information architecture.

    About the author

    Francis Storr is the lead designer for Intel’s Software Accessibility Program. An ex-pat from the UK, he now lives in Portland, Oregon where he appreciates not having to commute from Kent to London five days a week.

    More articles by Francis


    Posted by cssdsgn - 1 day ago

    Victory Advisors

    Posted by One Page Love - 1 day ago
    Dark-schemed long-scrolling One Pager for Victory Advisors – a London-based investment & advisory firm. Great to see the design optimized for larger resolutions too.

    Animation in Design Systems

    Posted by 24 Ways - 1 day ago

    Sarah Drasner drops down on the sofa, turns on the TV and puts on some Christmas classics. Yes, it’s time to talk animation, and not just any animation, but how you prescribe and document animation in your design systems. Perhaps you’ll be moved to make some changes.

    Brought to you by The CSS Layout Workshop. Does developing layouts with CSS seem like hard work? How much time could you save without all the trial and error? Are you ready to really learn CSS layout?

    Our modern front-end workflow has matured over time to include design systems and component libraries that help us stay organized, improve workflows, and simplify maintenance. These systems, when executed well, ensure proper documentation of the code available and enable our systems to scale with reduced communication conflicts.

    But while most of these systems take a critical stance on fonts, colors, and general building blocks, their treatment of animation remains disorganized and ad-hoc. Let’s leverage existing structures and workflows to reduce friction when it comes to animation and create cohesive and performant user experiences.

    Understand the importance of animation

    Part of the reason we treat animation like a second-class citizen is that we don’t really consider its power. When users are scanning a website (or any environment or photo), they are attempting to build a spatial map of their surroundings. During this process, nothing quite commands attention like something in motion.

    We are biologically trained to notice motion: evolutionarily speaking, our survival depends on it. For this reason, animation when done well can guide your users. It can aid and reinforce these maps, and give us a sense that we understand the UX more deeply. We retrieve information and put it back where it came from instead of something popping in and out of place.

    “Where did that menu go? Oh it’s in there.”

    For a deeper dive into how animation can connect disparate states, I wrote about the Importance of Context-Shifting in UX Patterns for CSS-Tricks.

    An animation flow on mobile.

    Animation also aids in perceived performance. Viget conducted a study where they measured user engagement with a standard loading GIF versus a custom animation. Customers were willing to wait almost twice as long for the custom loader, even though it wasn’t anything very fancy or crazy. Just by showing their users that they cared about them, they stuck around, and the bounce rates dropped.

    14 second generic loading screen.
    22 second custom loading screen.

    This also works for form submission. Giving your personal information over to an online process like a static form can be a bit harrowing. It becomes more harrowing without animation used as a signal that something is happening, and that some process is completing. That same animation can also entertain users and make them feel as though the wait isn’t as long.

    Eli Fitch gave a talk at CSS Dev Conf called: “Perceived Performance: The Only Kind That Really Matters”, which is one of my favorite talk titles of all time. In it, he discussed how we tend to measure things like timelines and network requests because they are more quantifiable–and therefore easier to measure–but that measuring how a user feels when visiting the site is more important and worth the time and attention.

    In his talk, he states “Humans over-estimate passive waits by 36%, per Richard Larson of MIT”. This means that if you’re not using animation to speed up how fast the wait time of a form submission loads, users are perceiving it to be much slower than the dev tools timeline is recording.

    Reign it in

    Unlike fonts, colors, and so on, we tend to add animation in as a last step, which leads to disorganized implementations that lack overall cohesion. If you asked a designer or developer if they would create a mockup or build a UI without knowing the fonts they were working with, they would dislike the idea. Not knowing the building blocks they’re working with means that the design can fall apart or the development can break with something so fundamental left out at the start. Good animation works the same way.

    The first step in reigning in your use of animation is to perform an animation audit. Look at all the places you are using animation on your site, or the places you aren’t using animation but probably should. (Hint: perceived performance of a loader on a form submission can dramatically change your bounce rates.)

    Not sure how to perform a good audit? Val Head has a great chapter on it in her book, Designing Interface Animations, which has of buckets of research and great ideas.

    Even some beautiful component libraries that have animation in the docs make this mistake. You don’t need every kind of animation, just like you don’t need every kind of font. This bloats our code. Ask yourself questions like: do you really need a flip 180 degree animation? I can’t even conceive of a place on a typical UI where that would be useful, yet most component libraries that I’ve seen have a mixin that does just this.

    Which leads to…

    Have an opinion

    Many people are confused about Material Design. They think that Material Design is Motion Design, mostly because they’ve never seen anyone take a stance on animation before and document these opinions well. But every time you use Material Design as your motion design language, people look at your site and think GOOGLE. Now that’s good branding.

    By using Google’s motion design language and not your own, you’re losing out on a chance to be memorable on your own website.

    What does having an opinion on motion look like in practice? It could mean you’ve decided that you never flip things. It could mean that your eases are always going to glide. In that instance, you would put your efforts towards finding an ease that looks “gliding” and pulling out any transform: scaleX(-1) animation you find on your site. Across teams, everyone knows not to spend time mocking up flipping animation (even if they’re working on an entirely different codebase), and to instead work on something that feels like it glides. You save time and don’t have to communicate again and again to make things feel cohesive.

    Create good developer resources

    Sometimes people don’t incorporate animation into a design system because they aren’t sure how, beyond the base hover states. All animation properties can be broken into interchangeable pieces. This allows developers and designers alike to mix and match and iterate quickly, while still staying in the correct language. Here are some recommendations (with code and a demo to follow):

    Create timing units, similar to h1, h2, h3. In a system I worked on recently, I called these t1, t2, t3. T1 would be reserved for longer pieces, down to t5 which is a bit like h5 in that it’s the default (usually around .25 seconds or thereabouts). Keep animation easings for entrance, exit, entrance emphasis and exit emphasis that people can commonly refer to. This, and the animation-fill-mode, are likely to be the only two properties that can be reused for the entrance and exit of the animation. Use the animation-name property to define the keyframes for the animation itself. I would recommend starting with 5 or 6 before making a slew of them, and see if you need more. Writing 30 different animations might seem like a nice resource, but just like your color palette having too many can unnecessarily bulk up your codebase, and keep it from feeling cohesive. Think critically about what you need here.

    See the Pen Modularized Animation for Component Libraries by Sarah Drasner (@sdras) on CodePen.

    The example above is pared-down, but you can see how in a robust system, having pieces that are interchangeable cached across the whole system would save time for iterations and prototyping, not to mention make it easy to make adjustments for different feeling movement on the same animation easily.

    One low hanging fruit might be a loader that leads to a success dialog. On a big site, you might have that pattern many times, so writing up a component that does only that helps you move faster while also allowing you to really zoom in and focus on that pattern. You avoid throwing something together at the last minute, or using a GIF, which are really heavy and mushy on retina. You can make singular pieces that look really refined and are reusable.

    React and Vue Implementations are great for reusable components, as you can create a building block with a common animation pattern, and once created, it can be a resource for all. Remember to take advantage of things like props to allow for timing and easing adjustments like we have in the previous example!


    At the very least we should ensure that interaction also works well on mobile, but if we’d like to create interactions that take advantage of all of the gestures mobile has to offer, we can use libraries like zingtouch or hammer to work with swipe or multiple finger detection. With a bit of work, these can all be created through native detection as well.

    Responsive web pages can specify initial-scale=1.0 in the meta tag so that the device is not waiting the required 300ms on the secondary tap before calling action. Interaction for touch events must either start from a larger touch-target (40px × 40px or greater) or use @media(pointer:coarse) as support allows.


    Sometimes people don’t create animation resources simply because it gets deprioritized. But design systems were also something we once had to fight for, too. This year at CSS Dev Conf, Rachel Nabors demonstrated how to plot out animation wants vs. needs on a graph (reproduced with her permission) to help prioritize them:

    This helps people you’re working with figure out the relative necessity and workload of the addition of these animations and think more critically about it. You’re also more likely to get something through if you’re proving that what you’re making is needed and can be reused.

    Good compromises can be made this way: “we’re not going to go all out and create an animated ‘About Us’ page like you wanted, but I suppose we can let our users know their contact email went through with a small progress and success notification.”

    Successfully pushing smaller projects through helps build trust with your team, and lets them see what this type of collaboration can look like. This builds up the type of relationship necessary to push through projects that are more involved. It can’t be overstressed that good communication is key.

    Get started!

    With these tools and good communication, we can make our codebases more efficient, performant, and feel better for our users. We can enhance the user experience on our sites, and create great resources for our teams to allow them to move more quickly while innovating beautifully.

    About the author

    Sarah is an award-winning Speaker, Consultant, and Staff Writer at CSS-Tricks. Sarah is also the co-founder of Web Animation Workshops, with Val Head. She’s given a Frontend Masters workshop on Advanced SVG Animations, and is working on a book for O’Reilly on SVG Animations. She’s formerly Manager of UX Design & Engineering at Trulia (Zillow).

    Last year Sarah won CSS Dev Conf’s “Best of Best of Award” as well as “Best Code Wrangler” from CSS Design Awards. She has worked for 15 years as a web developer and designer, and at points worked as a Scientific Illustrator and a Undergraduate Professor.

    More articles by Sarah

    My Coffee My Barista

    Posted by Divine CSS - 1 day ago
    My Coffee My Barista

    Jask Design

    Posted by Divine CSS - 1 day ago
    Jask Design is a creative agency based in Birmingham, United Kingdom specialising in web design, graphic design and print services to midlands-based businesses.

    HTTP/2 Server Push and Service Workers: The Perfect Partnership

    Posted by 24 Ways - 2 days ago

    Dean Hume pops on his gown and slippers and opens up his Christmas stocking to discover the high performance gifts of Server Push and Service Workers. It’s the gift that keeps on giving.

    Being a web developer today is exciting! The web has come a long way since its early days and there are so many great technologies that enable us to build faster, better experiences for our users. One of these technologies is HTTP/2 which has a killer feature known as HTTP/2 Server Push.

    During this year’s Chrome Developer Summit, I watched a really informative talk by Sam Saccone, a Software Engineer on the Google Chrome team. He gave a talk entitled Planning for Performance, and one of the topics that he covered immediately piqued my interest; the idea that HTTP/2 Server Push and Service Workers were the perfect web performance combination.

    If you’ve never heard of HTTP/2 Server Push before, fear not - it’s not as scary as it sounds. HTTP/2 Server Push simply allows the server to send data to the browser without having to wait for the browser to explicitly request it first. In this article, I am going to run through the basics of HTTP/2 Server Push and show you how, when combined with Service Workers, you can deliver the ultimate in web performance to your users.

    What is HTTP/2 Server Push?

    When a user navigates to a URL, a browser will make an HTTP request for the underlying web page. The browser will then scan the contents of the HTML document for any assets that it may need to retrieve such as CSS, JavaScript or images. Once it finds any assets that it needs, it will then make multiple HTTP requests for each resource that it needs and begin downloading one by one. While this approach works well, the problem is that each HTTP request means more round trips to the server before any data arrives at the browser. These extra round trips take time and can make your web pages load slower.

    Before we go any further, let’s see what this might look like when your browser makes a request for a web page. If you were to view this in the developer tools of your browser, it might look a little something like this:

    As you can see from the image above, once the HTML file has been downloaded and parsed, the browser then makes HTTP requests for any assets that it needs.

    This is where HTTP/2 Server Push comes in. The idea behind HTTP/2 Server Push is that when the browser requests a web page from the server, the server already knows about all the assets that are needed for the web page and “pushes” it to browser. This happens when the first HTTP request for the web page takes place and it eliminates an extra round trip, making your site faster.

    Using the same example above, let’s “push” the JavaScript and CSS files instead of waiting for the browser to request them. The image below gives you an idea of what this might look like.

    Whoa, that looks different - let’s break it down a little. Firstly, you can see that the JavaScript and CSS files appear earlier in the waterfall chart. You might also notice that the loading times for the files are extremely quick. The browser doesn’t need to make an extra HTTP request to the server, instead it receives the critical files it needs all at once. Much better!

    There are a number of different approaches when it comes to implementing HTTP/2 Server Push. Adoption is growing and many commercial CDNs such as Akamai and Cloudflare already offer support for Server Push. You can even roll your own implementation depending on your environment. I’ve also previously blogged about building a basic HTTP/2 Server Push example using Node.js. In this post, I’m not going to dive into how to implement HTTP/2 Server Push as that is an entire post in itself! However, I do recommend reading this article to find out more about the inner workings.

    HTTP/2 Server Push is awesome, but it isn’t a magic bullet. It is fantastic for improving the load time of a web page when it first loads for a user, but it isn’t that great when they request the same web page again. The reason for this is that HTTP/2 Server Push is not cache “aware”. This means that the server isn’t aware about the state of your client. If you’ve visited a web page before, the server isn’t aware of this and will push the resource again anyway, regardless of whether or not you need it. HTTP/2 Server Push effectively tells the browser that it knows better and that the browser should receive the resources whether it needs them or not. In theory browsers can cancel HTTP/2 Server Push requests if they’re already got something in cache but unfortunately no browsers currently support it. The other issue is that the server will have already started to send some of the resource to the browser by the time the cancellation occurs.

    HTTP/2 Server Push & Service Workers

    So where do Service Workers fit in? Believe it or not, when combined together HTTP/2 Server Push and Service Workers can be the perfect web performance partnership. If you’ve not heard of Service Workers before, they are worker scripts that run in the background of your website. Simply put, they act as middleman between the client and the browser and enable you to intercept any network requests that come and go from the browser. They are packed with useful features such as caching, push notifications, and background sync. Best of all, they are written in JavaScript, making it easy for web developers to understand.

    Using Service Workers, you can easily cache assets on a user’s device. This means when a browser makes an HTTP request for an asset, the Service Worker is able to intercept the request and first check if the asset already exists in cache on the users device. If it does, then it can simply return and serve them directly from the device instead of ever hitting the server.

    Let’s stop for a second and analyse what that means. Using HTTP/2 Server Push, you are able to push critical assets to the browser before the browser requests them. Then, using Service Workers you are able to cache these resources so that the browser never needs to make a request to the server again. That means a super fast first load and an even faster second load!

    Let’s put this into action. The following HTML code is a basic web page that retrieves a few images and two JavaScript files.

    <!DOCTYPE html>
      <meta charset="UTF-8">
      <title>HTTP2 Push Demo</title>
      <h1>HTTP2 Push</h1>
      <img src="./images/beer-1.png" />
      <img src="./images/beer-2.png" />
      <img src="./images/beer-3.png" />
      <img src="./images/beer-4.png" />
      <!-- Scripts -->
      <script async src="./js/promise.min.js"></script>
      <script async src="./js/fetch.js"></script>
      // Register the service worker
      if ('serviceWorker' in navigator) {
        navigator.serviceWorker.register('./service-worker.js').then(function(registration) {
          // Registration was successful
          console.log('ServiceWorker registration successful with scope: ', registration.scope);
        }).catch(function(err) {
          // registration failed :(
          console.log('ServiceWorker registration failed: ', err);

    In the HTML code above, I am registering a Service Worker file named service-worker.js. In order to start caching assets, I am going to use the Service Worker toolbox . It is a lightweight helper library to help you get started creating your own Service Workers. Using this library, we can actually cache the base web page with the path /push.

    The Service Worker Toolbox comes with a built-in routing system which is based on the same routing as Express. With just a few lines of code, you can start building powerful caching patterns.

    I’ve add the following code to the service-worker.js file.

    (global => {
      'use strict';
      // Load the sw-toolbox library.
      // The route for any requests
      toolbox.router.get('/push', global.toolbox.fastest);
      toolbox.router.get('/images/(.*)', global.toolbox.fastest);
      toolbox.router.get('/js/(.*)', global.toolbox.fastest);
      // Ensure that our service worker takes control of the page as soon as possible.
      global.addEventListener('install', event => event.waitUntil(global.skipWaiting()));
      global.addEventListener('activate', event => event.waitUntil(global.clients.claim()));

    Let’s break this code down further. Around line 4, I am importing the Service Worker toolbox. Next, I am specifying a route that will listen to any requests that match the URL /push. Because I am also interested in caching the images and JavaScript for that page, I’ve told the toolbox to listen to these routes too.

    The best thing about the code above is that if any of the assets exist in cache, we will instantly return the cached version instead of waiting for it to download. If the asset doesn’t exist in cache, the code above will add it into cache so that we can retrieve it when it’s needed again. You may also notice the code global.toolbox.fastest - this is important because gives you the compromise of fulfilling from the cache immediately, while firing off an additional HTTP request updating the cache for the next visit.

    But what does this mean when combined with HTTP/2 Server Push? Well, it means that on the first load of the web page, you are able to “push” everything to the user at once before the browser has even requested it. The Service Worker activates and starts caching the assets on the users device. The next time a user visits the page, the Service Worker will intercept the request and serve the asset directly from cache. Amazing!

    Using this technique, the waterfall chart for a repeat visit should look like the image below.

    If you look closely at the image above, you’ll notice that the web page returns almost instantly without ever making an HTTP request over the network. Using the Service Worker library, we cached the base page for the route /push, which allowed us to retrieve this directly from cache.

    Whether used on their own or combined together, the best thing about these two features is that they are the perfect progressive enhancement. If your user’s browser doesn’t support them, they will simply fall back to HTTP/1.1 without Service Workers. Your users may not experience as fast a load time as they would with these two techniques, but it would be no different from their normal experience. HTTP/2 Server Push and Service Workers are really the perfect partners when it comes to web performance.


    When used correctly, HTTP/2 Server Push and Service Workers can have a positive impact on your site’s load times. Together they mean super fast first load times and even faster repeat views to a web page. Whilst this technique is really effective, it’s worth noting that HTTP/2 push is not a magic bullet. Think about the situations where it might make sense to use it and don’t just simply “push” everything; it could actually lead to having slower page load times. If you’d like to learn more about the rules of thumb for HTTP/2 Server Push, I recommend reading this article for more information.

    All of the code in this example is available on my Github repo - if you have any questions, please submit an issue and I’ll get back to you as soon as possible.

    If you’d like to learn more about this technique and others relating to HTTP/2, I highly recommend watching Sam Saccone’s talk at this years Chrome Developer Summit.

    I’d also like to say a massive thank you to Robin Osborne, Andy Davies and Jeffrey Posnick for helping me review this article before putting it live!

    About the author

    Dean Hume is an author, Google Developer Expert, and all-around web performance geek. He regularly writes articles based on software development on his blog at deanhume.com.

    More articles by Dean

    Information Literacy Is a Design Problem

    Posted by 24 Ways - 3 days ago

    Lisa Maria Martin harnesses the huskies of information to the sled of knowledge and takes us on a ride through the snowy peaks and valleys of information design. Plan your route carefully and make your intentions clear, for in the wintery wastelands there are no go-arounds.

    Information literacy, wrote Dr. Carol Kulthau in her 1987 paper “Information Skills for an Information Society,” is “the ability to read and to use information essential for everyday life”—that is, to effectively navigate a world built on “complex masses of information generated by computers and mass media.”

    Nearly thirty years later, those “complex masses of information” have only grown wilder, thornier, and more constant. We call the internet a firehose, yet we’re loathe to turn it off (or even down). The amount of information we consume daily is staggering—and yet our ability to fully understand it all remains frustratingly insufficient.

    This should hit a very particular chord for those of us working on the web. We may be developers, designers, or strategists—we may not always be responsible for the words themselves—but we all know that communication is much more than just words. From fonts to form fields, every design decision that we make changes the way information is perceived—for better or for worse.

    What’s more, the design decisions that we make feed into larger patterns. They don’t just affect the perception of a single piece of information on a single site; they start to shape reader expectations of information anywhere. Users develop cumulative mental models of how websites should be: where to find a search bar, where to look at contact information, how to filter a product list.

    And yet: our models fail us. Fundamentally, we’re not good at parsing information, and that’s troubling. Our experience of an “information society” may have evolved, but the skills Dr. Kuhlthau spoke of are even more critical now: our lives depend on information literacy.

    Patterns from words

    Let’s start at the beginning: with the words. Our choice of words can drastically alter a message, from its emotional resonance to its context to its literal meaning. Sometimes we can use word choice for good, to reinvigorate old, forgotten, or unfairly besmirched ideas.

    One time at a wedding bbq we labeled the coleslaw BRASSICA MIXTA so people wouldn’t skip it based on false hatred.

    — Eileen Webb (@webmeadow) November 27, 2016

    We can also use clever word choice to build euphemisms, to name sensitive or intimate concepts without conjuring their full details. This trick gifts us with language like “the beast with two backs” (thanks, Shakespeare!) and “surfing the crimson wave” (thanks, Cher Horowitz!).

    But when we grapple with more serious concepts—war, death, human rights—this habit of declawing our language gets dangerous. Using more discrete wording serves to nullify the concepts themselves, euphemizing them out of sight and out of mind.

    The result? Politicians never lie, they just “misspeak.” Nobody’s racist, but plenty of people are “economically anxious.” Nazis have rebranded as “alt-right.”

    I’m not an asshole, I’m just alt-nice.

    — Andi Zeisler (@andizeisler) November 22, 2016

    The problem with euphemisms like these is that they quickly infect everyday language. We use the words we hear around us. The more often we see “alt-right” instead of “Nazi,” the more likely we are to use that phrase ourselves—normalizing the term as well as the terrible ideas behind it.

    Patterns from sentences

    That process of normalization gets a boost from the media, our main vector of information about the world outside ourselves. Headlines control how we interpret the news that follows—even if the story contradicts it in the end. We hear the framing more clearly than the content itself, coloring our interpretation of the news over time.

    Even worse, headlines are often written to encourage clicks, not to convey critical information. When headline-writing is driven by sensationalism, it’s much, much easier to build a pattern of misinformation. Take this CBS News headline: “Donald Trump: ‘Millions’ voted illegally for Hillary Clinton.” The headline makes no indication that this an objectively false statement; instead, this word choice subtly suggestions that millions did, in fact, illegally vote for Hillary Clinton.

    Headlines like this are what make lying a worthwhile political strategy. https://t.co/DRjGeYVKmW

    — Binyamin Appelbaum (@BCAppelbaum) November 27, 2016

    This is a deeply dangerous choice of words when headlines are the primary way that news is conveyed—especially on social media, where it’s much faster to share than to actually read the article. In fact, according to a study from the Media Insight Project, “roughly six in 10 people acknowledge that they have done nothing more than read news headlines in the past week.”

    If a powerful person asserts X there are 2 responsible ways to cover:
    1. “X is true”
    2. “Person incorrectly thinks X”

    Never “Person says X”

    — Helen Rosner (@hels) November 27, 2016

    Even if we do, in fact, read the whole article, there’s no guarantee that we’re thinking critically about it. A study conducted by Stanford found that “82 percent of students could not distinguish between a sponsored post and an actual news article on the same website. Nearly 70 percent of middle schoolers thought they had no reason to distrust a sponsored finance article written by the CEO of a bank, and many students evaluate the trustworthiness of tweets based on their level of detail and the size of attached photos.”

    Friends: our information literacy is not very good. Luckily, we—workers of the web—are in a position to improve it.

    Sentences into design

    Consider the presentation of those all-important headlines in social media cards, as on Facebook. The display is a combination of both the card’s design and the article’s source code, and looks something like this:

    A large image, a large headline; perhaps a brief description; and, at the bottom, in pale gray, a source and an author’s name.

    Those choices convey certain values: specifically, they suggest that the headline and the picture are the entire point. The source is so deemphasized that it’s easy to see how fake news gains a foothold: daily exposure to this kind of hierarchy has taught us that sources aren’t important.

    And that’s the message from the best-case scenario. Not every article shows every piece of data. Take this headline from the BBC: “Wisconsin receives request for vote recount.”

    With no image, no description, and no author, there’s little opportunity to signal trust or provide nuance. There’s also no date—ever—which presents potentially misleading complications, especially in the context of “breaking news.”

    And lest you think dates don’t matter in the light-speed era of social media, take the headline, “Maryland sidesteps electoral college.” Shared into my feed two days after the US presidential election, that’s some serious news with major historical implications. But since there’s no date on this card, there’s no way for readers to know that the “Tuesday” it refers to was in 2007. Again, a design choice has made misinformation far too contagious.

    More recently, I posted my personal reaction to the death of Fidel Castro via a series of twenty tweets. Wanting to share my thoughts with friends and family who don’t use Twitter, I then posted the first tweet to Facebook. The card it generated was less than ideal:

    The information hierarchy created by this approach prioritizes the name of the Twitter user (not even the handle), along with the avatar. Not only does that create an awkward “headline” (at least when you include a full stop in your name), but it also minimizes the content of the tweet itself—which was the whole point.

    The arbitrary elevation of some pieces of content over others—like huge headlines juxtaposed with minimized sources—teaches readers that these values are inherent to the content itself: that the headline is the news, that the source is irrelevant. We train readers to stop looking for the information we don’t put in front of them.

    These aren’t life-or-death scenarios; they are just cases where design decisions noticeably dictate the perception of information. Not every design decision makes so obvious an impact, but the impact is there. Every single action adds to the pattern.

    Design with intention

    We can’t necessarily teach people to read critically or vet their sources or stop believing conspiracy theories (or start believing facts). Our reach is limited to our roles: we make websites and products for companies and colleges and startups.

    But we have more reach there than we might realize. Every decision we make influences how information is presented in the world. Every presentation adds to the pattern. No matter how innocuous our organization, how lowly our title, how small our user base—every single one of us contributes, a little bit, to the way information is perceived.

    Are we changing it for the better?

    While it’s always been crucial to act ethically in the building of the web, our cultural climate now requires dedicated, individual conscientiousness. It’s not enough to think ourselves neutral, to dismiss our work as meaningless or apolitical. Everything is political. Every action, and every inaction, has an impact.

    As Chappell Ellison put it much more eloquently than I can:

    Every single action and decision a designer commits is a political act. The question is, are you a conscious actor?

    — Chappell Ellison???? (@ChappellTracker) November 28, 2016

    As shapers of information, we have a responsibility: to create clarity, to further understanding, to advance truth. Every single one of us must choose to treat information—and the society it builds—with integrity.

    About the author

    Lisa Maria Martin is an independent UX consultant and an editor with A Book Apart. She lives in Boston, MA. Follow her on Twitter, or learn more about her work at thefutureislikepie.com.

    More articles by Lisa Maria

    Today Studios

    Posted by cssdsgn - 2 hours ago

    The Capvest Group

    Posted by One Page Love - 4 hours ago
    Parallax scrolling One Pager for The Capvest Group that scales to a large resolution well. Cheers for the build notes!


    Posted by Web Creme - 8 hours ago


    Posted by cssdsgn - 1 day ago

    Nerds & Company

    Posted by CSS Design Awards - 1 day ago
    We design & develop interactive experiences to make your business better.

    Design Tickle

    Posted by Divine CSS - 1 day ago
    Design Tickle is an online magazine focusing around web & mobile design trends. It was built with WPBundle and I’ve customized the layout to feature author boxes, social media buttons, and post thumbnails.

    No Leath

    Posted by Divine CSS - 1 day ago
    No Leath esprime un nuovo concetto di calzatura per donna, maneggevole, realizzata interamente in PVC. La calzatura, duttile e innovativa, nasce dalla sinergia di stile, progettazione e meccanica.

    Converse: Diamonds

    Posted by Best Web Gallery - 1 day ago

    Arkade London

    Posted by Best Web Gallery - 2 days ago

    Marcus Eriksson

    Posted by Awwwards - 3 days ago

    Alex Hunting Studio

    Posted by cssdsgn - 3 hours ago


    Posted by CSS Design Awards - 6 hours ago
    We blend talent across branding, communications, production, media and architecture, making for a truly creative partner.

    One & Other

    Posted by Web Creme - 8 hours ago


    Posted by Featured / by - 1 day ago
    Sing-Sing teamed up with Sagmeister & Walsh to design and shoot this new campaign for Aizone, with wild optical illusions, and the best crew in the world. _______ Gotta love the high contrast colors of flat 2D meets 3D staging decor. Ohlala the eccentricity of it all.

    The Day

    Posted by cssdsgn - 1 day ago

    Geoff Muskett

    Posted by Divine CSS - 1 day ago
    A quirky jacket themed side scrolling mini portfolio


    Posted by Divine CSS - 1 day ago
    Website of cleaning company from Vienna in Austria.

    Popular Design News of the Week: September 11, 2017 – September 17, 2017

    Posted by Web Designer Depot - 2 days ago
    Every week users submit a lot of interesting stuff on our sister site Webdesigner News, highlighting great content from around the web that can be of interest to web designers.  The best way to keep track of all the great stories and news being posted is simply to check out the Webdesigner News site, however, […]


    Posted by One Page Love - 3 days ago
    Colorful One Pager for Rewind – a fun app to help rediscover your old Instagram photos.

    Ortiz. Leon

    Posted by Best Web Gallery - 3 days ago


    Posted by cssdsgn - 3 hours ago

    A Day Out

    Posted by cssdsgn - 6 hours ago


    Posted by Web Creme - 8 hours ago

    5 Techniques for Engaging Display Type

    Posted by Web Designer Depot - 1 day ago
    Sometimes your typeface needs to convey feeling as much as meaning, and for that function more designers are turning to dramatic typography. This type of typography is used for more than just legibility and readability (although that is still the primary purpose). Dramatic typography stands out. It reaches through the device screen, demands the viewer’s […]

    Tender to art

    Posted by Awwwards - 1 day ago
    TenderToArt is an incubator of contemporary art created in 201: a project involving artists every year selected for the innovation and the quality of their language and of their work.

    L A I K A B A S E

    Posted by Divine CSS - 1 day ago
    Once upon a time, the legend – just kidding… Okay, let’s keep it short: Sven Windszus and Lars Jandel teamed up in 2005 and brought birth to LAIKABASE, located In Berlin, Germany. If you like degrees, yes, they both do have design diplomas and Lars an additional one in film studies. The work of LAIKABASE […]

    Dearest Nature

    Posted by Divine CSS - 1 day ago
    An artsy lifestyle blog delivering daily inspirations from nature in the form of art, design, products, photography, DIYs, recipes, and more.


    Posted by CSS Design Awards - 2 days ago
    Enhanced website design with numerous intricate layouts, myriads of sections and thousands of informative pages.

    Comics of the Week #407

    Posted by Web Designer Depot - 3 days ago
    Every week we feature a set of comics created exclusively for WDD. The content revolves around web design, blogging and funny situations that we encounter in our daily lives as designers. These great cartoons are created by Jerry King, an award-winning cartoonist who’s one of the most published, prolific and versatile cartoonists in the world […]

    The Day Collective

    Posted by Site Inspire - 4 days ago

    View | Direct link