[Insert Clickbait Headline About Progressive Enhancement Here]

Published
Reading Time
24 minutes
Tagged
progressive enhancement web design javascript
Reactions
Crossposted
Medium

Late last week, Josh Korr, a project manager at Viget, posted at length about what he sees as a fundamental flaw with the argument for progressive enhancement. In reading the post, it became clear to me that Josh really doesn’t have a good grasp on progressive enhancement or the reasons its proponents think it’s a good philosophy to follow. Despite claiming to be “an expert at spotting fuzzy rhetoric and teasing out what’s really being said”, Josh makes a lot of false assumptions and inferences. My response would not have fit in a comment, so here it is…

Before I dive in, it’s worth noting that Josh admits that he is not a developer. As such, he can’t really speak to the bits where the rubber really meets the road with respect to progressive enhancement. Instead, he focuses on the argument for it, which he sees as a purely moral one… and a flimsily moral one at that.

I’m also unsure as to how Josh would characterize me. I don’t think I fit his mold of PE “hard-liners”, but since I’ve written two books and countless articles on the subject and he quotes me in the piece, I’ll go out on a limb and say he probably thinks I am.

Ok, enough with the preliminaries, let’s jump over to his piece…

Right out of the gate, Josh demonstrates a fundamental misread of progressive enhancement. If I had to guess, it probably stems from his source material, but he sees progressive enhancement as a moral argument:

It’s a moral imperative that everything on the web should be available to everyone everywhere all the time. Failing to achieve — or at least strive for — that goal is inhumane.

Now he’s quick to admit that no one has ever explicitly said this, but this is his takeaway from the articles and posts he’s read. It’s a pretty harsh, black & white, you’re either with us or against us sort of statement that has so many people picking sides and lobbing rocks and other heavy objects at anyone who disagrees with them. And everyone he quotes in the piece as examples of why he thinks this is progressive enhancement’s central conceit is much more of an “it depends” sort of person.

To clarify, progressive enhancement is neither moral or amoral. It’s a philosophy that recognizes the nature of the Web as a medium and asks us to think about how to build products that are robust and capable of reaching as many potential customers as possible. It isn’t concerned with any particular technology, it simply asks that we look at each tool we use with a critical eye and consider both its benefits and drawbacks. And it’s certainly not anti-JavaScript.

I could go on, but let’s circle back to Josh’s piece. Off the bat he makes some pretty bold claims about what he intends to prove in this piece:

  1. Progressive enhancement is a philosophical, moral argument disguised as a practical approach to web development.
  2. This makes it impossible to engage with at a practical level.
  3. When exposed to scrutiny, that moral argument falls apart.
  4. Therefore, if PEers can’t find a different argument, it’s ok for everyone else to get on with their lives.

For the record, I plan to address his arguments quite practically. As I mentioned, progressive enhancement is not solely founded on morality, though that can certainly be viewed as a facet. The reality is that progressive enhancement is quite pragmatic, addressing the Web as it exists not as we might hope that it exists or how we experience it.

Over the course of a few sections—which I wish I could link to directly, but alas, the headings don’t have unique ids—he examines a handful of quotes and attempts to tease out their hidden meaning by following the LSAT’s Logic Reasoning framework. We’ll start with the first one.

Working without JavaScript

Statement

  • “When we write JavaScript, it’s critical that we recognize that we can’t be guaranteed it will run.” — Aaron Gustafson
  • “If you make your core tasks dependent on JavaScript, some of your potential users will inevitably be left out in the cold.” — Jeremy Keith

Unstated assumptions:

  • Because there is some chance JavaScript won’t run, we must always account for that chance.
  • Core tasks can always be achieved without JavaScript.
  • It is always bad to ignore some potential users for any reason.

His first attempt at teasing out the meaning of these statements comes close, but ignores some critical word choices. First off, neither Jeremy nor I speak in absolutes. As I mentioned before, we (and the other folks he quotes) all believe that the right technical choices for a project depend on specifically on the purpose and goals of that specific project. In other words it depends. We intentionally avoid absolutist words like “always” (which, incidentally, Josh has no problem throwing around, on his own or on our behalf).

For the development of most websites, the benefits of following a progressive enhancement philosophy far outweigh the cost of doing so. I’m hoping Josh will take a few minutes to read my post on the true cost of progressive enhancement in relation to actual client projects. As a project manager, I hope he’d find it enlightening and useful.

It’s also worth noting that he’s not considering the reason we make statements like this: Many sites rely 100% on JavaScript without needing to. The reasons why sites (like news sites, for instance) are built to be completely reliant on a fragile technology is somewhat irrelevant. But what isn’t irrelevant is that it happens. Often. That’s why I said “it’s critical that we recognize that we can’t be guaranteed it will run” (emphasis mine). A lack of acknowledgement of JavaScript’s fragility is one of the main problems I see with web development today. I suspect Jeremy and everyone else quoted in the post feels exactly the same. To be successful in a medium, you need to understand the medium. And the (sad, troubling, interesting) reality of the Web is that we don’t control a whole lot. We certainly control a whole lot less than we often believe we do.

As I mentioned, I disagree with his characterization of the argument for progressive enhancement being a moral one. Morality can certainly be one argument for progressive enhancement, and as a proponent of egalitarianism I certainly see that. But it’s not the only one. If you’re in business, there are a few really good business-y reasons to embrace progressive enhancement:

  • Legal: Progressive enhancement and accessibility are very closely tied. Whether brought by legitimate groups or opportunists, lawsuits over the accessibility of your web presence can happen; following progressive enhancement may help you avoid them.
  • Development Costs: As I mentioned earlier, progressive enhancement is a more cost-effective approach, especially for long-lived projects. Here’s that link again: The True Cost of Progressive Enhancement.
  • Reach: The more means by which you enable users to access your products, information, etc., the more opportunities you create to earn their business. Consider that no one thought folks would buy big-ticket items on mobile just a few short years ago. Boy, were they wrong. Folks buy cars, planes, and more from their tablets and smartphones on the regular these days.
  • Reliability: When your site is down, not only do you lose potential customers, you run the risk of losing existing ones too. There have been numerous incidents where big sites got hosed due to JavaScript dependencies and they didn’t have a fallback. Progressive enhancement ensures users can always do what they came to your site to do, even if it’s not the ideal experience.

Hmm, no moral arguments for progressive enhancement there… but let’s continue.

Some experience vs. no experience

Statement

  • “[With a PE approach,] Older browsers get a clunky experience with full page refreshes, but that’s still much, much better than giving them nothing at all.” — Jeremy Keith
  • “If for some reason JavaScript breaks, the site should still work and look good. If the CSS doesn’t load correctly, the HTML content should still be there with meaningful hyperlinks.” — Nick Pettit

Unstated assumptions:

  • A clunky experience is always better than no experience.
  • HTML content — i.e. text, images, unstyled forms — is the most important part of most websites.

You may be surprised to hear that I have no issue with Josh’s distillation here. Clunky is a bit of a loaded word, but I agree that an experience is better than no experience, especially for critical tasks like checking your bank account, registering to vote, making a purchase from an online shop. In my book, I talk a little bit about a strange thing we experienced when A List Apart stopped delivering CSS to Netscape Navigator 4 way back in 2001:

We assume that those who choose to keep using 4.0 browsers have reasons for doing so; we also assume that most of those folks don’t really care about “design issues.” They just want information, and with this approach they can still get the information they seek. In fact, since we began hiding the design from non–compliant browsers in February 2001, ALA’s Netscape 4 readership has increased, from about 6% to about 11%.

Folks come to our web offerings for a reason. Sometimes its to gather information, sometimes it’s to be entertained, sometimes it’s to make a purchase. It’s in our best interest to remove every potential obstacle that can preclude them from doing that. That’s good customer service.

Project priorities

Statement

  • “Question any approach to the web where fancy features for a few are prioritized & basic access is something you’ll ‘get to’ eventually.” — Tim Kadlec

Unstated assumptions:

  • Everything beyond HTML content is superfluous fanciness.
  • It’s morally problematic if some users cannot access features built with JavaScript.

Not to put words in Tim’s mouth (like Josh is here), but what Tim’s quote is discussing is hype-driven (as opposed to user-centered) design. We (as developers) often prioritize our own convenience/excitement/interest over our users’ actual needs. It doesn’t happen all the time (note I said often), but it happens frequently enough to require us to call it out now and again (as Tim did here).

As for the “unstated assumptions”, I know for a fact that Tim would never call “everything beyond HTML” superfluous. What he is saying is that we should question—as in weigh the pros and cons—of each and every design pattern and development practice we consider. It’s important to do this because there are always tradeoffs. Some considerations that should be on your list include:

  • Download speed;
  • Time to interactivity;
  • Interaction performance;
  • Perceived performance;
  • Input methods;
  • User experience;
  • Screen size & orientation;
  • Visual hierarchy;
  • Aesthetic design;
  • Contrast;
  • Readability;
  • Text equivalents of rich interfaces for visually impaired users and headless UIs;
  • Fallbacks; and
  • Copywriting.

This list is by no means exhaustive nor is it in any particular order; it’s what came immediately to mind for me. Some interfaces may have fewer or more considerations as each is different. And some of these considerations might be in opposition to others depending on the interface. It’s critical that we consider the implications of our design decisions by weighing them against one another before we make any sort of decision about how to progress. Otherwise we open ourselves up to potential problems and the cost of changing things goes up the further into a project we are:

The cost of changing your mind goes up the further into any project you are. Just ask any contractor you hire to work on your house.

As a project manager, I’m sure Josh understands this reality.

As to the “morally problematic” bit, I’ll refer back to my earlier discussion of business considerations. Sure, morality can certainly be part of it, but I’d argue that it’s unwise to make assumptions about your users regardless. It’s easy to fall into the trap of thinking that all of or users are like us (or like the personas we come up with). My employer, Microsoft, makes a great case for why we should avoid doing this in their Inclusive Design materials:

When we design only for others like us, we exclude everyone who is not like us.

If you’re in business, it doesn’t pay to exclude potential customers (or alienate current ones).

Erecting unnecessary barriers

Statement

  • “Everyone deserves access to the sum of all human knowledge.” — Nick Pettit
  • “[The web is] built with a set of principles that — much like the principles underlying the internet itself — are founded on ideas of universality and accessibility. ‘Universal access’ is a pretty good rallying cry for the web.” — Jeremy Keith
  • “The minute we start giving the middle finger to these other platforms, devices and browsers is the minute where the concept of The Web starts to erode. Because now it’s not about universal access to information, knowledge and interactivity. It’s about catering to the best of breed and leaving everyone else in the cold.” — Brad Frost

Unstated assumptions:

  • What’s on the web comprises the sum of human knowledge.
  • Progressive enhancement is fundamentally about universal access to this sum of human knowledge.
  • It is always immoral if something on the web isn’t available to everyone.

I don’t think anyone quoted here would argue that the Web (taken in its entirety) is “the sum of all human knowledge”—Nick, I imagine, was using that phrase somewhat hyperbolically. But there is a lot of information on the Web folks should have access too, whether from a business standpoint or a legal one. What Nick, Jeremy, and Brad are really highlighting here is that we often make somewhat arbitrary design & development decisions that can block access to useful or necessary information and interactions.

In my talk Designing with Empathy (slides), I discussed “mystery meat” navigation. I can’t imagine any designer sets out to make their site difficult to navigate, but we are influenced by what we see (and are inspired by) on the web. Some folks took inspiration from web-based art projects like this Toyota microsite:

On Toyota’s Mind is a classic example of mystery meat navigation. It’s a Flash site and you can navigate when you happen to mouse over "hotspots" in the design. I’m pointing to one with a big red arrow here.

Though probably not directly influenced by On Toyota’s Mind, Yeshiva of Flatbush was certainly influenced by the concept of “experiential” (which is a polite way of saying “mystery meat”) navigation.

Yeshiva of Flatbush uses giant circles for their navigation. Intuitive, right?

That’s a design/UX example, but development is no different. How many Single Page Apps have you see out there that really didn’t need to be built that way? Dozens? We often put the cart before the horse and decide to build a site using a particular stack or framework without even considering the type of content we’re dealing with or whether that decision is in the best interest of the project or its end users. That goes directly back to Tim’s earlier point.

Progressive enhancement recognizes that experience is a continuum and we all have different needs when accessing the Web. Some are permanent: Low vision or blindness. Some are temporary: Imprecise mousing due to injury. Others are purely situational: Glare when your users are outside on a mobile device or have turned their screen brightness down to conserve battery. When we make our design and development decisions in the service of the project and the users who will access it, everyone wins.

Real answers to real questions

In the next section, Josh tries to say we only discuss progressive enhancement as a moral imperative. Clearly I don’t (and would go further to say no one else who was quoted does either). He argues that ours is “a philosophical argument, not a practical approach to web development”. I call bullshit. As I’ve just discussed in the previous sections, progressive enhancement is a practical, fiscally-responsible, developmentally robust philosophical approach to building for the Web.

But let’s look at some of the questions he says we don’t answer:

“Wait, how often do people turn off JavaScript?”

Folks turning off JavaScript isn’t really the issue. It used to be, but that was years ago. I discussed the misconception that this is still a concern a few weeks ago. The real issue is whether or not JavaScript is available. Obviously your project may vary, but the UK government pegged their non-JavaScript usage at 1.1%. The more interesting bit, however, was that only 0.2% of their users fell into the “Javascript off or no JavaScript support” camp. 0.9% of their users should have gotten the JavaScript-based enhancement on offer, but didn’t. The potential reasons are myriad. JavaScript is great, but you can’t assume it’ll be available.

“I’m not trying to be mean, but I don’t think people in Sudan are going to buy my product.”

This isn’t really a question, but it is the kinda thing I hear every now and then. An even more aggressive and ill-informed version I got was “I sell TVs; blind people don’t watch TV”. As a practical person, I’m willing to admit that your organization probably knows its market pretty well. If your products aren’t available in certain regions, it’s probably not worth your while to cater to folks in that region. But here’s some additional food for thought:

  • When you remove barriers to access for one group, you create opportunities for others. A perfect example of this is the curb cut. Curb cuts were originally created to facilitate folks in wheelchairs getting across the road. In creating curb cuts, we’ve also enabled kids to ride bicycles more safely on the sidewalk, delivery personnel to more easily move large numbers of boxes from their trucks into buildings, and parents to more easily cross streets with a stroller. Small considerations for one group pay dividends to more. What rational business doesn’t want to enable more folks to become customers?
  • Geography isn’t everything. I’m not as familiar with specific design considerations for Sudanese users, but since about 97% of Sudanese people are Muslim, let’s tuck into that. Ignoring translations and right-to-left text, let’s just focus on cultural sensitivity. For instance, a photo of a muscular, shirtless guy is relatively acceptable in much of the West, but would be incredibly offensive to a traditional Muslim population. Now your target audience may not be 100% Muslim (nor may your content lend itself to scantily-clad men), but if you are creating sites for mass consumption, knowing this might help you art direct the project better and build something that doesn’t offend potential customers.

Reach is incredibly important for companies and is something the Web enables quite easily. To squander that—whether intentionally or not—would be a shame.

Failures of understanding

Josh spends the next section discussing what he views as failures of the argument for progressive enhancement. He’s of course, still debating it as a purely moral argument, which I think I’ve disproven at this point, but let’s take a look at what he has to say…

The first “fail” he casts on progressive enhancement proponents is that we “are wrong about what’s actually on the Web.” Josh offers three primary offerings on the Web:

  • Business and personal software, both of which have exploded in use now that software has eaten the world and is accessed primarily via the web
  • Copyrighted news and entertainment content (text, photos, music, video, video games)
  • Advertising and marketing content

This is the fundamental issue with seeing the Web only through the lens of your own experience. Of course he would list software as the number one thing on the Web—I’m sure he uses Basecamp, Harvest, GitHub, Slack, TeamWork, Google Docs, Office 365, or any of a host of business-related Software as a Service offerings every day. As a beneficiary of fast network speeds, I’m not at all surprised that entertainment is his number two: Netflix, Hulu, HBO Go/Now… It’s great to be financially-stable and live in the West. And as someone who works at a web agency, of course advertising would be his number three. A lot of the work Viget, and most other agencies for that matter, does is marketing-related; nothing wrong with that. But the Web is so much more than this. Here’s just a fraction of the stuff he’s overlooked:

  • eCommerce,
  • Social media,
  • Banks,
  • Governments,
  • Non-profits,
  • Small businesses,
  • Educational institutions,
  • Research institutions,
  • Religious groups,
  • Community organizations, and
  • Forums.

It’s hard to find figures on anything but porn—which incidentally accounts for somewhere between 4% and 35% of the Web, depending on who you ask—but I have to imagine that these categories he’s overlooked probably account for the vast majority of “pages” on the Web even if they don’t account for the majority of traffic on it. Of course, as of 2014, the majority of traffic on the Web was bots, so…

The second “fail” he identifies is that our “concepts of universal access and moral imperatives… make no sense” in light of “fail” number one. He goes on to provide a list of things he seems to think we want even though advocating for progressive enhancement (and even universal access) doesn’t mean advocating for any of these things:

  • All software and copyrighted news/entertainment content accessed via the web should be free. and Netflix, Spotify, HBO Now, etc. should allow anyone to download original music and video files because some people don’t have JavaScript. I’ve never heard anyone say that… ever. Advocating a smart development philosophy doesn’t make you anti-copyright or against making money.
  • Any content that can’t be accessed via old browsers/devices shouldn’t be on the web in the first place. No one made that judgement. We just think it behooves you to increase the potential reach of your products and to have a workable fallback in case the ideal access scenario isn’t available. You know, smart business decisions.
  • Everything on the web should have built-in translations into every language. This would be an absurd idea given that the number of languages in use on this planet top 6,500. Even if you consider that 2,000 of those have less than 1,000 speakers it’s still absurd. I don’t know anyone who would advocate for translation to every language.1
  • Honda needs to consider a universal audience for its marketing websites even though (a) its offline advertising is not universal, and (b) only certain people can access or afford the cars being advertised. To you his first point, Honda does actually offline advertising in multiple languages. They even issue press releases mentioning it: “The newspaper and radio advertisements will appear in Spanish or English to match the primary language of each targeted media outlet.” As for his second argument… making assumptions about target audience and who can or cannot afford your product seems pretty friggin’ elitist; it’s also incredibly subjective. For instance, we did a project for a major investment firm where we needed to support Blackberry 4 & 5 even though there were many more popular smartphones on the market. The reason? They had several high-dollar investors who loved their older phones. You can’t make assumptions.
  • All of the above should also be applied to offline software, books, magazines, newspapers, TV shows, CDs, movies, advertising, etc. Oh, I see, he’s being intentionally ridiculous.

I’m gonna skip the third fail since it presumes morality is the only argument progressive enhancement has and then chastises the progressive enhancement community for not spending time fighting for equitable Internet access and net neutrality and against things like censorship (which, of course, many of us actually do).

In his closing section, Josh talks about progressive enhancement moderates and he quotes Matt Griffin on A List Apart:

One thing that needs to be considered when we’re experimenting … is who the audience is for that thing. Will everyone be able to use it? Not if it’s, say, a tool confined to a corporate intranet. Do we then need to worry about sub-3G network users? No, probably not. What about if we’re building on the open web but we’re building a product that is expressly for transferring or manipulating HD video files? Do we need to worry about slow networks then? … Context, as usual, is everything.

In other words, it depends, which is what we’ve all been saying all along.

I’ll leave you with these facts:

  • Progressive enhancement has many benefits, not the least of which are resilience and reach.
  • You don’t have to like or even use progressive enhancement, but that doesn’t detract from its usefulness.
  • If you ascribe to progressive enhancement, you may have a project (or several) that aren’t really good candidates for it (e.g., online photo editing software).
  • JavaScript is a crucial part of the progressive enhancement toolbox.
  • JavaScript availability is never guaranteed, so it’s important to consider offering fallbacks for critical tasks.
  • Progressive enhancement is neither moral nor amoral, it’s just a smart way to build for the Web.

Is progressive enhancement necessary to use on every project?

No.

Would users benefit from progressive enhancement if it was followed on more sites than it is now?

Heck yeah.

Is progressive enhancement right for your project?

It depends.

My sincere thanks to Sara Soueidan, Baldur Bjarnasun, Jason Garber, and Tim Kadlec for taking the time give me feedback on this piece.

  1. Of course, last I checked, over 55% of the Web was in English and just shy of 12% of the world speaks English, so… ↩

Webmentions

  3. Kevin Marks

    you could link to his subheadings with fragmentions ,and progressively enhance the links with a plugin

  4. Stephanie

    the funny thing is that title is very click bait-ish.

  16. Stephen Hay

    So, so good, Aaron. Thanks for writing it.

  18. Aaron Gustafson

    I think important bits like that get overlooked because everyone seems to want to pick a side. We can (& should) work together.

  19. Stephen Hay

    I have trouble understanding how people tend to see it as a threat to their favourite toys.

  27. Chris Poteet

    Wonderful reply. Ironic that he set out to use “logic” and failed by his own standards. Nice job.

  28. Eric Bailey

    Loved your rebuttal. Have you posted it to Sidebar? Original article got a lot traction when posted there.

  52. admin

    c271_wotw

    Inspirational Website of the Week: 10×16

    A beautiful color theme combined with super-smooth movements make 10×16 our pick this week.

    Get inspired

    c271_graphicstock This content is sponsored via Syndicate Ads

    See GraphicStock’s New Holiday Photo Collection

    GraphicStock is giving you 7 days of free access to 350,000 fully-licensed images, including their new holiday photo collection.

    Get started

    c271_js30

    JavaScript30

    A fantastic 30-day challenge that will make you master Vanilla JavaScript. By Wes Bos. Check out the GitHub repo, too.

    Check it out

    c271_siema

    Siema

    Siema is a lightweight carousel plugin with no dependencies and no styling. Built by Paweł Grzybek

    Check it out

    c271_io

    IO – A space to publish freely

    IO is a lightweight and powerful writing tool where you can publish your thoughts anonymously, under a pseudonym, or as yourself. Made by Bold.

    Check it out

    c271_passworddumb

    Dumb Password Rules

    A shameful collection of not-so-intelligent password rules encountered on the Web. By Nicholas Duffy.

    Check it out

    c271_gitscout

    Gitscout

    Gitscout is a beautiful GitHub Issues experience for macOS.

    Check it out

    c271_pwamps

    Progressive Web AMPs

    Paul Bakaus shows the power of combining the ideas of Accelerated Mobile Pages with Progressive Web Apps.

    Read it

    c271_pe

    [Insert Clickbait Headline About Progressive Enhancement Here]

    Aaron Gustafson responds to Josh Korr’s article on Vidget and explains what progressive enhancement really is.

    Read it

    c271_react

    Server Side React

    Remy Sharp decided to give React a go and used it for server side rendering. Read about his insights.

    Read it

    c271_handwriting

    Four Experiments in Handwriting with a Neural Network

    Fantastic interactive visualizations for understanding how machine learning works at the example of handwriting experiments.

    Read it

    c271_instantsearch

    React-instantsearch

    React-instantsearch is a set of widgets and connectors to add instant-search experiences in your React application, using Algolia search engine.

    Check it out

    c271_displaytext

    Get the Balance Right: Responsive Display Text

    Richard Rutter shows how to handle responsive display text properly with the right balance.

    Read it

    c271_uielements

    Inspirational UI Elements vol. 2 (PSD)

    A beautiful set of UI elements in PSD format.

    Get it

    c271_fontossem

    Free Font: Ossem

    A beautiful free typeface with various styles designed by Kiril Semkov.

    Get it

    c271_imzy

    Imzy

    A new kind of community that aims to embrace diversity and simplicity.

    Check it out

    c271_mobirise

    Mobirise Icons

    A free, open source set of 124 elegant, pixel-perfect icons from Mobirise Builder.

    Get it

    c271_gitnotify

    Git Notify

    Get daily code diffs from public GitHub repos. Made by Sai Ram Kunala.

    Check it out

    c271_shorthandantipattern

    CSS Shorthand Syntax Considered an Anti-Pattern

    Learn why the use of shorthand syntax in CSS can beautiful problematic. By Harry Roberts.

    Read it

    c271_fontawesome

    Saving the internet 2000 terabytes a day: fixing Font Awesome’s fonts

    An interesting article on optimizing the Web’s most famous icon font.

    Read it

    c271_babel

    The State of Babel

    A very interesting article on the current state of Babel, the powerful JavaScript tooling suite. By Henry Zhu.

    Read it

    c271_deeplearning

    The major advancements in Deep Learning in 2016

    A great summary of this year’s research progress in Deep Learning.

    Read it

    c271_musicalinteractions From Our Blog

    Interactive Musical Instruments

    Experimental ideas for playful musical interactions powered by MIDI.js and the Web Audio API. Play instruments or make sounds by interacting with content.

    Check it out

    c271_geekychristmas From Our Blog

    Geeky Christmas Vector Set + Patterns

    A free hand-drawn vector set plus two bonus patterns with a geeky Christmas related theme. Includes vector files and ready-to-use, optimized PNGs.

    Get it

    Collective #271 was written by Pedro Botelho and published on Codrops.

    Source: tympanus

  53. info@danielemilana.it

    Go to Source

    c271_wotw

    Inspirational Website of the Week: 10×16

    A beautiful color theme combined with super-smooth movements make 10×16 our pick this week.

    Get inspired

    c271_graphicstock This content is sponsored via Syndicate Ads

    See GraphicStock’s New Holiday Photo Collection

    GraphicStock is giving you 7 days of free access to 350,000 fully-licensed images, including their new holiday photo collection.

    Get started

    c271_js30

    JavaScript30

    A fantastic 30-day challenge that will make you master Vanilla JavaScript. By Wes Bos. Check out the GitHub repo, too.

    Check it out

    c271_siema

    Siema

    Siema is a lightweight carousel plugin with no dependencies and no styling. Built by Paweł Grzybek

    Check it out

    c271_io

    IO – A space to publish freely

    IO is a lightweight and powerful writing tool where you can publish your thoughts anonymously, under a pseudonym, or as yourself. Made by Bold.

    Check it out

    c271_passworddumb

    Dumb Password Rules

    A shameful collection of not-so-intelligent password rules encountered on the Web. By Nicholas Duffy.

    Check it out

    c271_gitscout

    Gitscout

    Gitscout is a beautiful GitHub Issues experience for macOS.

    Check it out

    c271_pwamps

    Progressive Web AMPs

    Paul Bakaus shows the power of combining the ideas of Accelerated Mobile Pages with Progressive Web Apps.

    Read it

    c271_pe

    [Insert Clickbait Headline About Progressive Enhancement Here]

    Aaron Gustafson responds to Josh Korr’s article on Vidget and explains what progressive enhancement really is.

    Read it

    c271_react

    Server Side React

    Remy Sharp decided to give React a go and used it for server side rendering. Read about his insights.

    Read it

    c271_handwriting

    Four Experiments in Handwriting with a Neural Network

    Fantastic interactive visualizations for understanding how machine learning works at the example of handwriting experiments.

    Read it

    c271_instantsearch

    React-instantsearch

    React-instantsearch is a set of widgets and connectors to add instant-search experiences in your React application, using Algolia search engine.

    Check it out

    c271_displaytext

    Get the Balance Right: Responsive Display Text

    Richard Rutter shows how to handle responsive display text properly with the right balance.

    Read it

    c271_uielements

    Inspirational UI Elements vol. 2 (PSD)

    A beautiful set of UI elements in PSD format.

    Get it

    c271_fontossem

    Free Font: Ossem

    A beautiful free typeface with various styles designed by Kiril Semkov.

    Get it

    c271_imzy

    Imzy

    A new kind of community that aims to embrace diversity and simplicity.

    Check it out

    c271_mobirise

    Mobirise Icons

    A free, open source set of 124 elegant, pixel-perfect icons from Mobirise Builder.

    Get it

    c271_gitnotify

    Git Notify

    Get daily code diffs from public GitHub repos. Made by Sai Ram Kunala.

    Check it out

    c271_shorthandantipattern

    CSS Shorthand Syntax Considered an Anti-Pattern

    Learn why the use of shorthand syntax in CSS can beautiful problematic. By Harry Roberts.

    Read it

    c271_fontawesome

    Saving the internet 2000 terabytes a day: fixing Font Awesome’s fonts

    An interesting article on optimizing the Web’s most famous icon font.

    Read it

    c271_babel

    The State of Babel

    A very interesting article on the current state of Babel, the powerful JavaScript tooling suite. By Henry Zhu.

    Read it

    c271_deeplearning

    The major advancements in Deep Learning in 2016

    A great summary of this year’s research progress in Deep Learning.

    Read it

    c271_musicalinteractions From Our Blog

    Interactive Musical Instruments

    Experimental ideas for playful musical interactions powered by MIDI.js and the Web Audio API. Play instruments or make sounds by interacting with content.

    Check it out

    c271_geekychristmas From Our Blog

    Geeky Christmas Vector Set + Patterns

    A free hand-drawn vector set plus two bonus patterns with a geeky Christmas related theme. Includes vector files and ready-to-use, optimized PNGs.

    Get it

    Collective #271 was written by Pedro Botelho and published on Codrops.

    Go to Source

    Share this:

    Like this:

    Like Loading…

    <h3><em>Related</em></h3>
  54. info@danielemilana.it

    Go to Source

    c271_wotw

    Inspirational Website of the Week: 10×16

    A beautiful color theme combined with super-smooth movements make 10×16 our pick this week.

    Get inspired

    c271_graphicstock This content is sponsored via Syndicate Ads

    See GraphicStock’s New Holiday Photo Collection

    GraphicStock is giving you 7 days of free access to 350,000 fully-licensed images, including their new holiday photo collection.

    Get started

    c271_js30

    JavaScript30

    A fantastic 30-day challenge that will make you master Vanilla JavaScript. By Wes Bos. Check out the GitHub repo, too.

    Check it out

    c271_siema

    Siema

    Siema is a lightweight carousel plugin with no dependencies and no styling. Built by Paweł Grzybek

    Check it out

    c271_io

    IO – A space to publish freely

    IO is a lightweight and powerful writing tool where you can publish your thoughts anonymously, under a pseudonym, or as yourself. Made by Bold.

    Check it out

    c271_passworddumb

    Dumb Password Rules

    A shameful collection of not-so-intelligent password rules encountered on the Web. By Nicholas Duffy.

    Check it out

    c271_gitscout

    Gitscout

    Gitscout is a beautiful GitHub Issues experience for macOS.

    Check it out

    c271_pwamps

    Progressive Web AMPs

    Paul Bakaus shows the power of combining the ideas of Accelerated Mobile Pages with Progressive Web Apps.

    Read it

    c271_pe

    [Insert Clickbait Headline About Progressive Enhancement Here]

    Aaron Gustafson responds to Josh Korr’s article on Vidget and explains what progressive enhancement really is.

    Read it

    c271_react

    Server Side React

    Remy Sharp decided to give React a go and used it for server side rendering. Read about his insights.

    Read it

    c271_handwriting

    Four Experiments in Handwriting with a Neural Network

    Fantastic interactive visualizations for understanding how machine learning works at the example of handwriting experiments.

    Read it

    c271_instantsearch

    React-instantsearch

    React-instantsearch is a set of widgets and connectors to add instant-search experiences in your React application, using Algolia search engine.

    Check it out

    c271_displaytext

    Get the Balance Right: Responsive Display Text

    Richard Rutter shows how to handle responsive display text properly with the right balance.

    Read it

    c271_uielements

    Inspirational UI Elements vol. 2 (PSD)

    A beautiful set of UI elements in PSD format.

    Get it

    c271_fontossem

    Free Font: Ossem

    A beautiful free typeface with various styles designed by Kiril Semkov.

    Get it

    c271_imzy

    Imzy

    A new kind of community that aims to embrace diversity and simplicity.

    Check it out

    c271_mobirise

    Mobirise Icons

    A free, open source set of 124 elegant, pixel-perfect icons from Mobirise Builder.

    Get it

    c271_gitnotify

    Git Notify

    Get daily code diffs from public GitHub repos. Made by Sai Ram Kunala.

    Check it out

    c271_shorthandantipattern

    CSS Shorthand Syntax Considered an Anti-Pattern

    Learn why the use of shorthand syntax in CSS can beautiful problematic. By Harry Roberts.

    Read it

    c271_fontawesome

    Saving the internet 2000 terabytes a day: fixing Font Awesome’s fonts

    An interesting article on optimizing the Web’s most famous icon font.

    Read it

    c271_babel

    The State of Babel

    A very interesting article on the current state of Babel, the powerful JavaScript tooling suite. By Henry Zhu.

    Read it

    c271_deeplearning

    The major advancements in Deep Learning in 2016

    A great summary of this year’s research progress in Deep Learning.

    Read it

    c271_musicalinteractions From Our Blog

    Interactive Musical Instruments

    Experimental ideas for playful musical interactions powered by MIDI.js and the Web Audio API. Play instruments or make sounds by interacting with content.

    Check it out

    c271_geekychristmas From Our Blog

    Geeky Christmas Vector Set + Patterns

    A free hand-drawn vector set plus two bonus patterns with a geeky Christmas related theme. Includes vector files and ready-to-use, optimized PNGs.

    Get it

    Collective #271 was written by Pedro Botelho and published on Codrops.

    Go to Source

    Share this:

    Like this:

    Like Loading…

    <h3><em>Related</em></h3>

  58. This Web Design News Courtesy Of: http://feedproxy.google.com/~r/tympanus/~3/unfoUg3YjG0/

    Re-posting this post that I am posting for you.EnjoyWeb Design

    c271_wotw

    Inspirational Website of the Week: 10×16

    A beautiful color theme combined with super-smooth movements make 10×16 our pick this week.

    Get inspired

    c271_graphicstock This content is sponsored via Syndicate Ads

    See GraphicStock’s New Holiday Photo Collection

    GraphicStock is giving you 7 days of free access to 350,000 fully-licensed images, including their new holiday photo collection.

    Get started

    c271_js30

    JavaScript30

    A fantastic 30-day challenge that will make you master Vanilla JavaScript. By Wes Bos. Check out the GitHub repo, too.

    Check it out

    c271_siema

    Siema

    Siema is a lightweight carousel plugin with no dependencies and no styling. Built by Paweł Grzybek

    Check it out

    c271_io

    IO – A space to publish freely

    IO is a lightweight and powerful writing tool where you can publish your thoughts anonymously, under a pseudonym, or as yourself. Made by Bold.

    Check it out

    c271_passworddumb

    Dumb Password Rules

    A shameful collection of not-so-intelligent password rules encountered on the Web. By Nicholas Duffy.

    Check it out

    c271_gitscout

    Gitscout

    Gitscout is a beautiful GitHub Issues experience for macOS.

    Check it out

    c271_pwamps

    Progressive Web AMPs

    Paul Bakaus shows the power of combining the ideas of Accelerated Mobile Pages with Progressive Web Apps.

    Read it

    c271_pe

    [Insert Clickbait Headline About Progressive Enhancement Here]

    Aaron Gustafson responds to Josh Korr’s article on Vidget and explains what progressive enhancement really is.

    Read it

    c271_react

    Server Side React

    Remy Sharp decided to give React a go and used it for server side rendering. Read about his insights.

    Read it

    c271_handwriting

    Four Experiments in Handwriting with a Neural Network

    Fantastic interactive visualizations for understanding how machine learning works at the example of handwriting experiments.

    Read it

    c271_instantsearch

    React-instantsearch

    React-instantsearch is a set of widgets and connectors to add instant-search experiences in your React application, using Algolia search engine.

    Check it out

    c271_displaytext

    Get the Balance Right: Responsive Display Text

    Richard Rutter shows how to handle responsive display text properly with the right balance.

    Read it

    c271_uielements

    Inspirational UI Elements vol. 2 (PSD)

    A beautiful set of UI elements in PSD format.

    Get it

    c271_fontossem

    Free Font: Ossem

    A beautiful free typeface with various styles designed by Kiril Semkov.

    Get it

    c271_imzy

    Imzy

    A new kind of community that aims to embrace diversity and simplicity.

    Check it out

    c271_mobirise

    Mobirise Icons

    A free, open source set of 124 elegant, pixel-perfect icons from Mobirise Builder.

    Get it

    c271_gitnotify

    Git Notify

    Get daily code diffs from public GitHub repos. Made by Sai Ram Kunala.

    Check it out

    c271_shorthandantipattern

    CSS Shorthand Syntax Considered an Anti-Pattern

    Learn why the use of shorthand syntax in CSS can beautiful problematic. By Harry Roberts.

    Read it

    c271_fontawesome

    Saving the internet 2000 terabytes a day: fixing Font Awesome’s fonts

    An interesting article on optimizing the Web’s most famous icon font.

    Read it

    c271_babel

    The State of Babel

    A very interesting article on the current state of Babel, the powerful JavaScript tooling suite. By Henry Zhu.

    Read it

    c271_deeplearning

    The major advancements in Deep Learning in 2016

    A great summary of this year’s research progress in Deep Learning.

    Read it

    c271_musicalinteractions From Our Blog

    Interactive Musical Instruments

    Experimental ideas for playful musical interactions powered by MIDI.js and the Web Audio API. Play instruments or make sounds by interacting with content.

    Check it out

    c271_geekychristmas From Our Blog

    Geeky Christmas Vector Set + Patterns

    A free hand-drawn vector set plus two bonus patterns with a geeky Christmas related theme. Includes vector files and ready-to-use, optimized PNGs.

    Get it

    Collective #271 was written by Pedro Botelho and published on Codrops.

  83. Ponieważ moja biblioteka przydatnych linków stopniowo się powiększa, pomyślałem że jest to dobry moment i miejsce, aby je zebrać razem.

    JavaScript

    W3Schools Online Web TutorialsES6 for Everyone — The best way to learn modern ES6 JavaScriptNodeSchoolES2015 Crash CourseEloquent JavaScriptgetify/You-Dont-Know-JS · GitHubBest resources to learn JavaScript – Stack OverflowUnheap – A tidy repository of jQuery PluginsJavascript [Illustrator Praxis] skrypty do Adobe IllustratorDouglas Crockford: The JavaScript Programming Language – YouTubeDouglas Crockford: An Inconvenient API – The Theory of the DOM – YouTubeDouglas Crockford: Advanced JavaScript – YouTubeTrain with Programming Challenges/Kata | CodewarsVideo Courses on JavaScript and Front-End Web DevelopmentLearning Functional Programming with JavaScript // slidr.ioThe Little JavaScripterDouglas Crockford’s JavascriptCoderbyteHow to Learn JavaScript Properly | JavaScript is SexyThe 50 Best Websites to Learn JavaScriptCodeCombat – Learn how to code by playing a gameLearning JavaScript Design PatternsObject-Oriented JavaScript Programming Course | UdacityJavaScript Design Patterns | UdacitySo You Want to be a Functional Programmer (Part 1) – MediumNamed function expressions demystifiedFunction Declarations vs. Function Expressions – JavaScript, JavaScript…Understand JavaScript Callback Functions and Use Them | JavaScript is SexyLearn ECMAScript6 by doing itJSbooks – free javascript booksKurs JavaScriptLoading JSON-formatted data with Ajax and xhr.responseType=’json’ · Mathias BynensJavaScript + jQuery Design Pattern Framework – dofactory.comThe Best of JavaScript and the web platormUp and Running with ESLint — the Pluggable JavaScript LinterJavaScript GardenLearning JavaScript Design Patterns | DegreedJavaScript Best Practices: Tips & Tricks to Level Up Your Code | CodementorJavaScript books by Dr. Axel RauschmayerBest Web Development & Programming Blogs in 2017 | CodementorFunctional Programming – Mostly Adequate GuideThe Two Pillars of JavaScript – JavaScript Scene – MediumA Gentle Introduction to Functional JavaScript: Part 1Read JavaScript Allongé (ES5) | LeanpubPure JavaScript on VimeoRead JavaScript Allongé, the "Six" Edition | LeanpubJSONPlaceholder – Fake online REST API for developersAjax Requests – You Don’t Need jQuery! – Free yourself from the chains of jQuery by embracing and understanding the modern Web API and discovering various directed libraries to help you fill in the gaps.Andrew Van Slaarsstoeffel/awesome-fp-js: A curated list of awesome functional programming stuff in jsSynchroniczna asynchroniczność – webroad.plUnderstanding Asynchronous JavaScript Callbacks Through Household ChoresThe Evolution of Asynchronous JavaScript | RisingStackUnderstanding Asynchronous JavaScript – YouTubeJavaScript Goes Asynchronous (and It’s Awesome)No promises: asynchronous JavaScript with only generatorsKIRUPA | become a better web developerBasic AJAX Request: XMLHttpRequestXMLHttpRequest object usageBrowser APIs and Protocols: XMLHttpRequest – High Performance Browser Networking (O’Reilly)Making HTTP Requests in JavaScript | kirupa.com

    React

    How-to setup Webpack on an ES6 React Application with SASS? – Jonathan PetitcolasLearn React.JS in 8 Minutes – Learning New Stuff – MediumBuilding Your First React.js App – Learning New Stuff – MediumSurviveJS ReactSurviveJS WebpackReactJS Programegghead.io – Learn professional JavaScript tools with Tutorial Videos & Training @eggheadioThinksterBuilding Your Second React.js App – Learning New Stuff – MediumGetting Started with Redux – Course by @dan_abramov @eggheadioBe an expert in ReactJS by watching these 5 videos.

    HTML i CSS

    Semantyczny blog w HTML5[IT] Ciekawe artykuły z branży – Porady i tutoriale WWW – forumweb.plBEM I (finally) understandBEM – krótki przykład na żywo | Pasja OnlineBEM & Atomic Design: A CSS Architecture Worth Loving | LullabotOrganize your CSS (BEM way) | ZaraffaSoftBetter CSS: Putting it together with Atomic, ITCSS & BEM » SilverStripeStructuring Sass: Saying Goodbye to Atomic Design AmbiguityUnderstanding Flexbox: Everything you need to knowAlmost complete guide to flexbox (without flexbox) | Kenan YusufA Complete Guide to Flexbox | CSS-TricksFlexbox SheetLearning from Lego: A Step Forward in Modular Web Design · An A List Apart ArticleSass ReferenceSass Guidelines — Polish translationHow Sass 3.3 Will Solve Your RWD ProblemsBulma: a modern CSS framework based on FlexboxUtility OpenType † Simple, CSS utility classes for advanced typographic features.Profound Grid | A grid system for fixed and fluid layoutsGetting started · BootstrapComponents · BootstrapCSS-TricksCSS Animation 101CSS Reference – A free visual guide to the most popular CSS properties.[Insert Clickbait Headline About Progressive Enhancement Here], From the Notebook of Aaron GustafsonScreenfly / Test Your Website at Different Screen ResolutionsHTML 5 Cheat Sheet – Including Free PDF DownloadLearn HTML5 and CSS3 for Free4.7 Embedded content — HTML5HTML5 Doctor, helping you implement HTML5 todayWeb API Interfaces | MDNThe 100% correct way to do CSS breakpoints

    Różne

    RegExr: Learn, Build, & Test RegExEmmet Expand Abbreviation for SublimeText3Rog.ieArchives | Sublime Text TipsSublime Text 3 (OSX) Cheat Sheet by martinprins – Cheatography.com: Cheat Sheets For Every OccasionSublime Text Power UserPlunkerDesign + Code — FREEBIE.SUPPLYscraps/bootstrap-full-class-list.txt at master · BillyWM/scraps · GitHubCodrops | Useful resources and inspiration for creative mindsAn introduction to functional programmingLearning How to Learn: The Most Important Developer Skillgulp/getting-started.md at master · gulpjs/gulpBlog – CodeUnion.ioBlog o zwinnym zarządzaniu produktami|ProductVisinW3cubDocs API Documentation – W3cubDocsGit – Book

    				<a href="http://blog.grzegorzlaszczyk.pl/chodzimy-po-drzewie/">
					← Chodzimy po drzewie
				</a>
  84. ribenzhandianyo@163.com

    2017前端性能优化清单

    你开始使用渐进启动了么？是不是已经使用过React和Angular中tree-shaking和code-splitting两个工具？有没有用过Brotli、Zofli和HPACK这几种压缩技术，或者OCSP协议（在线证书状态协议）？知不知道资源提醒，客户端提醒和CSS containment一类的技术？了解IPv6，HTTP/2和Service Worker这些协议吗？

    回想那些年，大家往往在完成了产品之后才会去考虑性能。常常把与性能相关的事情拖到项目的最后来做，所做的也不过是对服务器上的config文件进行一些微调、串联、优化以及部分特别小的调整。而现在，技术已经有了翻天覆地的变化。

    一个项目的性能是非常重要的，除了要在技术层面上注意，更要在项目的设计之初就开始考虑，这样才可以使性能的各种隐形需求完美的整合到项目中，随着项目一起推进。性能最好具有可量化、可监测以及可改动的特性。网络越来越复杂，对网络的监控也变得越来越难，因为监测的过程会受到包括设备、浏览器、协议、网络类型以及其他技术（CDN，ISP，缓存，代理服务器，防火墙，负载均衡器和服务器对性能的影响都很大）的很大影响。

    下文是一份2017年的前端性能优化清单，阐述了作为前端开发人员，为了确保反馈速度以及浏览器兼容性我们需要考虑的问题。

    （你也可以下载checklist PDF或者check in Apple Pages。优化万岁！）

    正文

    微优化是保持性能最好的办法，但是又不能有太过明确的优化目标，因为过于明确的目标会影响在项目中做的每一个决定。以下是一些不同的模型，请按照自己舒服的顺序阅读。

    请准备好然后定下目标！

    1. 比你最强的竞争对手快20%

    根据一个心理学研究，你的网站最少在速度上比别人快20%，才能让用户感觉到你的网站比别人的更快。这个速度说的不是整个页面的加载时间，而是开始加载渲染的时间，首次有效渲染时间（例如页面需要加载主要内容的时间），或者交互时间（指的是页面或者应用中主要的页面加载完成，并主备好与用户进行交互的时间）。

    在Moto G（一个中端三星设备）和Nexus 4（比较主流的设备）上衡量开始渲染时间（用WebPagetest）以及首页有效渲染时间（用Lighthouse），最好是在一个开放的实验室中，使用规范的3G，4G和Wi-Fi链接。

    243d50ba-20181116183210-5bef0d2ae092e.png
    Lighthouse，一个Google开发的新的性能审查工具

    你可以通过你的分析报告看看你的用户处在哪个阶段，选取其中前90%的用户体验来做测试。接着收集数据，建一个表格，筛去20%的数据并预设一个目标（如：性能预算）。现在你可以将上述两个值进行对比检测。如果你始终维持着你的目标并且通过一点一点改变脚本去加快交互时间，那么上述方法就是合理可行的。

    8dd627bb-20181116183212-5bef0d2c56e1a.png
    由Brad Frost创建的性能分析

    和你的同事分享这份清单。首先要确保团队中的每个人都熟悉这份清单。项目中每一个决定都会影响性能，如果前端工程师们都在积极的参与项目概念，UX以及视觉设计的决定，这将会给整个项目带来巨大收益。地图设计的决定违背了性能理念，所以他在这份清单内的顺序有待考虑。

    2. 反应时间为100毫秒，帧数是每秒60帧

    RAIL性能模型会为你提供一个优秀的目标，既尽最大的努力在用户初始操作后的100毫秒内提供反馈。为了达到这个目标，页面需要放弃权限，并将权限在50毫秒内交回给主线程。对于像动画一样的高压点，最好的方法就是什么都不做，因为你永远无法达到最小绝对值。
    同理，动画的每一帧都需要在16毫秒内完成，这样才能保证每秒60帧（一秒/60=16.6毫秒），如果可以的话最好能在10毫秒内完成。因为浏览器需要一定的时间去在屏幕上渲染新的帧，而且你的代码需要在16.6毫秒内完成执行。要注意，上述目标应用于衡量项目的运行性能，而非加载性能。

    3. 首次有效渲染时间要低于1.25秒，速度指数要低于1000

    纵使这个目标实现起来非常困难，你的最终目标也应该是让开始渲染时间低于1秒且速度指数低于1000（在网速快的地方）。对于首次有效渲染时间，上限最好是1250毫秒。对于移动端，3G下移动设备首次渲染时间低于3秒都是可以接受的。稍微高一点也没关系，但千万别高太多。

    定义你所需要的环境

    4. 选择和安装你的开发环境

    不要过多的关注当下最流行的工具，坚持选择适合自己开发环境的工具，例如Grunt、Gulp、Webpack、PostCSS，或者组合起来的工具。只要这个工具运行的速度够快，而且没有给你的维护带来太大问题，这就够了。

    5. 渐进增强（progressive enhancement）

    在构建前端结构的时候，应始终将渐进增强作为你的指导原则。首先设计并且构建核心体验，随后再完善那些为高性能浏览器设计的高级特性的相关体验，创建弹性体验。如果你的网页可以在使用低速网络、老旧显示器的很慢的电脑上运行飞快，那么在光纤高配电脑上它只会运行的更快。

    6. Angular，React，Ember等

    最好使用那些支持服务器端渲染的框架。在使用某个框架钱，先记录服务器和客户端的引导时间，记得要在移动设备上测试，最终才能使用某个框架（因为面对的是性能问题，如果在使用某个框架后，再做修改是非常困难的）。如果你使用JavaScript框架，要保证你的选择是被广泛使用并且经过考验的。不同框架对性能有着不同程度的影响，同时对应着不同的优化策略，所以最好可以清楚的了解你要用的框架的每个方面。在写网页应用时可以先看看PRPL pattern和application shell architecture。

    68bbfd00-20181116183213-5bef0d2dd63a7.png
    本图描述了PRPL pattern

    6f8e7694-20181116183215-5bef0d2f7a6b6.jpg
    上图是application shell，是一个小型的、由HTML,CSS和JavaScript构成的用户界面

    7. AMP还是Instant Articles？

    根据你整体组织结构的优先顺序和策略，你可以考虑使用Google的AMP或Facebook的Instant Articles。要知道没有这些你也可以达到不错的性能，但是AMP可以提供一个性能不错的免费的内容分发网络框架（CDN），Instant Articles可以在Facebook上促进你的性能。你也可以建立progressive web AMP。

    8. 选择适合你的CDN

    根据你的动态数据量，可以将一部分内容外包给静态网站生成工具，将它置于CDN上，从中生成一个静态版本，从而避免那些数据库的请求。也可以选择基于CDN的静态主机平台，通过交互组件丰富你的页面（JAMStack）。

    注意CDN是否可以很好的处理（或分流）动态内容。没必要单纯的将你的CDN限制为静态。反复检查CDN是否执行了内容的压缩和转化，检查智能HTTP/2传输和缓存服务器（ESI），注意哪些静态或动态的部分处在CDN的边缘（最接近用户的服务器）。

    开始优化

    9. 直接确定优化顺序

    首先应该弄清楚你想解决的问题是什么。检查一遍你所有的文件（JavaScript，图片，字体，第三方script文件以及页面中重要的模块，例如轮播，复杂信息图标和多媒体内容），并将他们分类。
    列一个表格。明确浏览器上应该有的基础核心内容，哪些部分属于为高性能浏览器设计的升级体验，哪些是附加内容（那些不必要或者可以被延时加载的部分，例如字体，不必要的样式，轮播组件，播放器，社交网站入口，很大的图片）。更详细的细节请参考文章”Improving Smashing Magazine’s Performance‘’。

    10. 使用符合标准的技术

    使用符合标准的技术向过时的浏览器提供核心体验，向老式浏览器提供增强体验, 同时对所加载的内容要有严格的把控。即首要加载核心体验部分，将增强部分放在DomContentLoaded，把额外内容发在load事件中。

    以前我们可以通过浏览器的版本推断出设备的性能，但现在我们已经无法推测了。因为现在市场上很多廉价的安卓手机都不考虑内存限制和CPU性能，直接使用高版本的Chrome浏览器。一定要注意，在我们没有其他选择的时候，我们选择的技术同时可能成为我们的限制。

    11. 考虑微优化和渐进启动

    在一些应用中，可以在渲染页面前先初始化应用。最好先显示框架，而不是一个进度条或指示器。使用可以加速初始渲染时间的模块或技术（例如tree-shaking和code-splitting），因为大部分性能问题来自于应用引导程序的初始分析时间。还可以在服务器上提前编译，从而减轻部分客户端的渲染过程，从而快速输出结果。最后，考虑使用Optimize.js来加快初始加载速度，它的原理是包装优先级高的调用函数（虽然现在已经没什么必要了）。

    a9cd6491-20181116183217-5bef0d3169723.jpg
    渐进启动指的是使用服务器端渲染，从而快速得到首次有效渲染，这个渲染过程也包括小部分的JavaScript文件，目的是使交互时间尽可能的接近首次有效渲染时间。

    到底采用客户端渲染还是服务器端渲染？不论哪种做法，我们的目标都是建立渐进启动：使用服务器端渲染可以得到很短的首次有效渲染时间，这个渲染过程也包括小部分的JavaScript文件，目的是使交互时间尽可能的接近首次有效渲染时间。接下来，尽可能的增加一些应用的非必要功能。不幸的是，正如Paul Lewis所说，框架基本上对开发者是没有优先级的概念的，因此渐进启动在很多库和框架上是很难实施的。如果你有时间的话，还是考虑使用策略去优化你的性能吧。

    12. HTTP的缓存头使用的合理吗？

    仔细检查一下例如expires，cache-control，max-age以及其他HTTP缓存头是否被正确的使用。一般来说，资源不论在短时间（如果它会被频繁改动）还是不确定的时间内（如果它是静态的）都是可缓存的——你大可在需要的时候在URL中成改版本。

    如果可能，使用为指纹静态资源设计的Cache-control:immutable，从而避免二次验证（2016年12月，只有FireFox在https://处理中支持）。你可以使用，Heroku的primer on HTTP caching headers，Jake Archibald的 ”Caching Best Practices”，还有IIya Grigorik的HTTP caching primer作为指导。

    13. 减少使用第三方库，加载JavaScript异步操作

    当用户请求页面时，浏览器会抓取HTML同时生成DOM，然后抓取CSS并建立CSS对象模型，最后通过匹配DOM和CSS对象生成渲染树。在需要处理的JavaScript文件被解决之前，浏览器不会开始对页面进行渲染。作为开发者，我们要明确的告诉浏览器不要等待，直接开始渲染。具体方法是使用HTML中的defer和async两个属性。

    事实上，defer更好一些（因为对于IE9及以下用户对于IE9及以下用户，很有可能会中断脚本）。同时，减少第三方库和脚本的使用，尤其是社交网站的分享按键和<iframe>嵌入（比如地图）。你可以使用静态的社交网站分享按键（例如SSBG的）和指向交互地图的静态链接去代替他们。

    14. 图片是否被正确优化？

    尽可能的使用带有srcset，sizes还有<picture>元素的响应式图片。你也可以利用<picture>元素的WebP格式，用JPEG格式作为替补（参见Andreas Bovens的code snippet）或是使用内容协商（使用接受头）。Sketch原本就支持WebP，WebP图片可以直接被Photoshop的WebP plugin导出。当然也有很多其他方法。

    d03bc9d0-20181116183218-5bef0d327aaad.jpg
    响应图片断点生成器可自动处理图片

    你也可以使用客户端提示，现在浏览器也可以做到。在用来生成响应图片的源文件过少时，使用响应图片断点生成器或类似Cloudinary的服务自动的优化图片。在很多案例中，单独使用sreset和sizes都带来了很大的收益。在本网站上，我们给文件添加-opt后缀——例如brotli-compression-opt.png；这样团队的每一个人就知道这些带着后最的图片是被优化过的。

    15. 图片的进一步优化

    当你在编写登陆界面的时候，发现页面上的图片加载的特别快，这时你需要确认一下JPEG格式文件是否已经通过mozJPEG（它可以操作扫描等级从而提高渲染时间）优化和压缩，PNG格式对应Pingo，GIF需要用到Lossy GIF，SVG要使用SVGOMG。对图片不重要的部分进行模糊处理（使用高斯模糊过滤器处理他们），从而减少文件大小，最后你可能还要去彩色化使图片变成黑白，从而减少更多的容量。对于背景图片，使用Photoshop保持0到10%的质量输出是绝对可以接受的。

    如果你还觉得不够，那你可以通过多重背景图片技术来提高图片的感知性能。

    16. 网页字体优化了吗？

    你用来修饰网页字体的服务很有可能毫无用处，包括字形和额外的特性。如果你在使用开源的字体，尝试用字体库中某一个小的子集或是自己归类一个小的子集从而压缩文件大小（例如通过一些特殊的注音符号引用Latin）。WOFF2 support是个非常不错的选择，如果浏览器不支持，那你可以将WOFF和OTF作为备用。你也可以从Zach Leatherman的“Comprehensive Guide to Font-Loading Strategies”一文中选择一个合适的策略，然后使用服务器来缓存字体。如果想要快速入门，Pixel Ambacht的教程与案例会让你的字体变得尽然有序。

    14d90ed2-20181116183219-5bef0d33a3e58.png
    Zach Leatherman的“Comprehensive Guide to Font-Loading Strategies”提供了一打可以让字体传输变得更好的选项

    如果你用的是第三方服务器主机，没办法自己在服务器上对字体进行操作，一定看看Web Font Loader。FOUT is better than FOIT中提到，在备选情况下立即渲染文本，并且异步加载字体——你也可以使用loadCSS实现这个。你可能也会避免本地OS上安装字体。

    17. 快速执行关键部分的CSS

    为了确保浏览器尽可能快的渲染你的页面，先收集页面首次可见部分的CSS文件（也叫决定性CSS或上半版CSS）进行渲染，然后将它加入页面的<head>部分，从而避免重复操作。因为慢启动阶段对交换包大小的限制，你关键CSS文件的大小也被限制在14KB左右。如果高于这个值，浏览器需要重复一些步骤来获取更多的样式。关键CSS是允许你这样做的。可能对每个模板都需要这个操作。如果可能，考虑一下用Fiament Group用的条件内敛方法。

    通过HTTP/2，关键CSS可以单独存为CSS文件，通过服务器传输，而且可以避免HTML膨胀。服务器传输缺乏连续支持，并且存在一些超高速缓存的问题（Hooman Beheshti演示的前144页）。事实上，这样会导致网络缓冲区膨胀。因为TCP的慢启动，服务器传输在稳定的连接下会更有效率。所以你可能需要建立带有缓存的HTTP/2服务器传输机制。但请记住，新的cache-digest规则会否定手动建立的需要缓存的服务器的请求。

    18. 通过tree-shaking和code-splitting减少净负载

    Tree-shaking是通过保留那些在项目过程中真正需要的代码从而清理你的构建过程的一种方式。你可以用Webpack 2来提出那些没用的住配置文件，用UnCSS或Helium从CSS中取出不需要的样式。同理，也可以考虑学习一下如何编写高效的CSS选择器，以及如何避免膨胀和高费的样式。

    Code-splitting是另一个Webpack特性，它可以根据按需加载的块将你的代码分开。只要你在代码中定义了分离点，Webpack便会处理好相关的输出文件。它基本上能保证你初始下载的内容很小，而且在需求被添加时按需请求代码。

    Rollup所展示的结果要比Browserify配置文件所显示的好得多。所以当我们想使用类似工具的时候，或许应该看看Rollupify，它将ECMAScript2015模块变成了一个更大的CommonJS模块——因为小模块没准有出乎意料的高性能成本，这源自于你对打包工具模块系统的选择。

    19. 提升渲染性能

    使用类似CSS containment的方法对高消耗组建进行隔离，从而限制浏览器样式的范围，可以作用在为无canvas的浏览工作的布局和装饰工作中，或是用在第三方工具上。要确保页面滚动和出现动画效果时没有延迟，别忘了之前提到过的每秒60帧的原则。如果没办法做到，那就尽可能保证每秒帧数的大致范围在15到60帧。使用CSS中的will-change通知浏览器哪些元素和属性发生了变化。

    也记得要衡量渲染执行中的性能（可以用DevTools）。可以参照Udacity上Paul Lewis的免费课程——浏览器渲染优化，作为入门。还有一篇Sergey Chikuyonok的文章讲了如何正确的用GPU动画。

    20. 预热网络连接，加快传输速度

    使用页面框架，对高消耗组建延迟加载（字体，JS文件，循环播放，视频和内嵌框架）。使用资源提示来节省在dns-prefetch（指的是在后台执行DNS检索），preconnect（指要求浏览器在后台进行握手链接（DNS，TCP，TLS）），prerender（指要求浏览器在后台对特定页面进行渲染），preload（指的是提前取出暂不执行的源文件）。根据你浏览器的支持情况，尽量使用preconnect来代替dns-prefetch，而且在使用prefetch和prerender要特别小心——后者（prerender）只有在你非常确信用户下一步操作的情况下再去使用（比如购买流程中）。

    HTTP/2

    21. 准备好使用HTTP/2

    Google开始向着更安全网页的方向努力，并且将所有Chrome上的HTTP网页定义为“不安全”时，你或许应该考虑是继续使用HTTP/1.1，还是将目光转向HTTP/2环境。虽然初期投入比较大，但是使用HTTP/是大趋势，而且在熟练掌握之后，你可以使用service worker和服务器推送技术让行性能再提升一大截。

    544a7f61-20181116183221-5bef0d358cd5e.png
    现在，Google计划把所有HTTP页面标记为不安全，并且将HTTP安全指示器设置为与Chrome用来拦截HTTPS的红色三角相同的图标。

    使用HTTP/2的环境的缺点在于你要转移到HTTPS上，并且根据你HTTP/1.1用户的数量（主要指使用过时操作系统和过时浏览器的用户），你需要适应不同的建构过程，才能发送不同的建构。注意：不论是迁移还是新的构建过程都可能非常棘手而且耗时很多。

    22. 适当部署HTTP/2

    重申，使用HTTP/2协议之前，你需要彻底排查目前为止你所使用协议的情况。你需要在打包组建和同时加载很多小组间之间找到平衡。

    一方面，你可能想要避免将很多资源链式链接，与其将你全部的界面分割成许多小模块，不如将他们压缩使之成为建构过程的一部分，之后给它们赋予可检索的信息并加载它们。这样的话，对一个文件将不再需要重新下载整个样式清单或JavaScript文件。

    另一方面，封装是很有必要的，因为一次向浏览器发送太多JavaScript文件会出问题。首先，压缩会造成损坏。得益于dictionary reuse，压缩大文件不会对文件造成损害，压缩小文件则不然。确实有方法可以解决这个问题，但这不是本文讨论的范畴。其次，浏览器还没有优化到可以对类似工作流进行优化。例如，Chrome会引发进程间通信（IPCs），这些通信的数量与资源的数量成正比，而这成百上千个资源将会消耗大量的浏览器的执行时间。

    1adb7b1e-20181116183222-5bef0d369fecb.png
    Chrome的Jake Archibald建议，为了用HTTP/2达到最好的效果，考虑一下逐步加载CSS文件

    当然你可以考虑逐步加载CSS文件。很显然，你这样做对HTTP/1.1的用户非常不利，所以你可能需要根据不同的浏览器建立多个版本来应对你的调度过程，这样就会使过程略微复杂。你也可以避免HTTP/2连接的合并，同时受益于HTTP/2来使用域名碎片，但是实现起来有些困难。

    我们到底应该做什么呢？如果你粗略的用过HTTP/2，似乎成功的发送过10个左右的包（在老是浏览器上运行的也不错）。那你就能着手开始试验并且为你的网站找到平衡点。

    23. 确保服务器安全可靠

    所有的浏览器都支持HTTP/2并且使用TLS，这是有你可能想要避免安全警告，并删除页面上没用的元素。好好检查你的安全头部是否设置正确，排除已知的缺陷并检查证书。

    如果还没有迁移到HTTP， 你那可以先看看HTTPS准则（The HTTPS-Only Standard）。确保所有外部插件和监视脚本都能被HTTPS正确加载，确保没有跨站脚本出现，HTTP脚本传输的安全头和内容安全头也都设置正确。

    24. 你的服务器和CDN支持HTTP/2吗？

    不同服务器和CDN对HTTP/2的兼容性不同，你可以使用TLS够快吗？一文来查看你有什么选择。

    91328614-20181116183223-5bef0d37aa3b8.png
    Is TLS Fast Yet？让你能看看你的服务器和CDN在使用HTTP/2的时候你能使用的工具

    25. Brotli和Zopfli两种压缩算法还在用吗？

    2015年，Google介绍了Brotli，一个新的开源无损数据格式，它已经被Chrome，Firefox和Opera很好的兼容了。具体使用时，Brotli所显示出的效率要远高于Gzip和Deflate。它根据不同的配置可能压缩的时候会比较慢，但是压缩速度慢最后会让压缩效率提高。而且解压起来非常快。因为这个算法来自Google，所以浏览器只在用户通过HTTPS访问网页的时候使用它，这个事情就不奇怪了。Brotli的隐患是它没办法在目前大部分服务器上预设，而且如果没有NGINX或者Ubuntu，部署起来还是有难度的。但其实你是可以在不支持它的CDN上使用Brotli（通过service worker）。

    你可以看看Zopfli压缩算法作为备选，它将数据编码为Deflate，Gzip和Zlib格式。任何规范的Gzip压缩资源都受益于Zopfli改进了Deflate编码，因为文件会比Zlib压缩的最大文件小3%-8%。问题在于文件会消耗大概80倍的时间去压缩。这就是为什么在不怎么会变得资源上使用Zopfli是不错的选择，这样的文件一般都压缩一次，下载多次。

    26. OCSP装订是否可以使用？

    让服务器使用OCSP装订，可以提升你TLS握手的速度。线证书状态协议（OCSP）是作为证书废置列表协议的代替品被创造出来的。两个协议都可以用来检测SSL证书是否被取消。然而，OCSP不需要浏览器花时间下载和扫描证书信息的列表，所以它可以减少握手时间。

    27. 你是否开始使用IPv6？

    因为我们已经没什么IPv4的地址可用了，而且移动网络大都开始使用IPv6（美国已经有50%的入口采用IPv6），将你的DNS升级到IPv6为以后作打算是个不错的选择。要确保通网络可以支持双栈协议——它需要允许IPv6和IPv4同时运行。毕竟IPv6不只是做为后备计划的。而且研究显示，伴随邻居发现（NDP）和路由优化，使用IPv6的网站要比普通网站快10%到15%。

    28. 是否使用HPACK？

    如果你在使用HTTP/2，看看你的服务器有没有执行HPACK对HTTP的响应头进行压缩，来减少不必要的消耗。因为HTTP/2服务器相对较新，所以有些像HPACK这样的规格目前还没有被支持。我们可以用H2spec来检查HPACK是否在工作。

    83f76234-20181116183225-5bef0d39639a5.png
    H2spec的截图

    29. service workers是否为超高速缓存和网络提供预设机制？

    没有经过优化的网络可以比用户机器的本地缓存跑得更快。如果你的网站在HTTPS上运行，你可以参考“实用主义者的service workers手册”，然后把静态资源存在service worker的缓存中，把离线预设（甚至离线页面）存在用户机器方便检索，这样比多次进行网络连接更有效。你还可以参考Jake的离线使用手册和免费的Udactiy课程“离线网络应用”。如果浏览器支持，那就再好不过了，预设就能在任何地方代替网络了。

    测试与监听

    30. 监听混合内容中的警告

    如果你近期完成了HTTP到HTTPS的迁移，你可以利用类似Report-URI.io一类的对主动和被动的混合内容警告都进行监听。也可以利用混合内容扫描器来对你使用HTTPS的网页进行扫描。

    31. 你的开发流程是否使用Devtools进行了优化？

    选一个调试工具来对每一个按钮进行检查。确保自己明白如何分析渲染性能和控制台输出、明白如何调试JavaScript以及编辑CSS样式。Umar Hansa最近有一个关于使用DevTools调试和测试的分享，主要包括一些不常用的技巧和技术。

    32. 是否使用代理浏览器和过时浏览器测试过？

    仅仅使用Chrome和Firefox测试是不够的。还应该看看你的网页在代理浏览器和过时浏览器上运行的怎么样。比如UC浏览器和Opera Min, 它们在亚洲市场的份额很高（高达35%）。在推广时，利用目标客户所在国家的平均网速来进行测试，避免日后出现大的误差。同样的，不仅要在节流网络以及模拟的高数据处理设备上进行测试，还要在真实设备上测试。

    33. 有无建立持续监听？

    在进行快速、无限制的测试时，最好使用一个个人的WebPageTest实例。建立一个能自动预警的性能预算监听。建立自己的用户时间标记从而测量并监测具体商用的数据。使用SpeedCurve对性能的变化进行监控，同时利用New Relic获取WebPageTest没法提供的数据。SpeedTracker，Lighthouse和Calibre都是不错的选择。

    快速入门

    这份清单综合性很强，几乎介绍了所有的可用的优化方式。那么，如果你只有一个小时进行优化，你应该干什么呢？让我们从中总结10个最有用的来。别忘了在你开始优化前和结束优化后，记录你的结果，包括开始渲染时间以及在3G，有限连接下的速度。

    1. 有线连接下，你的目标是将开始渲染时间降低至1s一下，而3G的目标是保持在3s一下，SpeedIndex值保持在1000一下。为开始渲染时间和交互时间做优化。

    2. 为你主要的模板准备关键CSS文件，将它们放在页面的<head>中（你可以使用14KB）。

    3. 对于你自己和第三方的脚本文件，尽可能的延迟加载它们——尤其是社交网站按钮，播放器和高消耗的JavaScript文件。

    4. 使用更快的dns-lookup，preconnect，prefetch，preload和prerender添加资源提示，从而加快传输速度。

    5. 将字体一类属性作为子集，异步加载（或者使用系统字体代替）。

    6. 优化图片，并考虑在关键页中使用WebP（例如登陆页面）。

    7. 确保HTTP的缓存头和安全头都被正确的设置。

    8. 在服务器上使用Brotli或Zopfli压缩算法。（如果不支持这两个，尝试一下Gzip）

    9. 如果HTTP/2可用，使用HPACK压缩算法，并监听混合内容的警告。如果你在使用LTS，就可以使用OCSP装订。

    10. 如果可能，将类似字体，JavaScript文件以及图片缓存在service worker缓存中——事实上越多越好！

    结语

    文中提到的一些优化可能超出了你工作的范围，有的可能超出了你的预算，有的甚至对你正在使用的有些过时的代码判了死刑。但没关系，本文只是一个普通大纲（希望能做到综合性强），你应该根据自己的工作环境列一份适合自己的清单。最重要的，在开始优化之前，先对项目中存在的问题有一个明确的了解。最后，祝大家2017年优化顺利！

    ———————————-我们需要的小伙伴————————————

    工作职责：

    -Web前端的功能设计、开发和优化，开发可重用模块
    -实现与视觉稿、交互稿一致的跨平台、浏览器、客户端，兼容性好的移动端页面和PC页面
    -前沿技术研究和新技术调研，

    职位要求：

    -精通JavaScript/HTML5/CSS3等相关前端开发技术，熟悉页面架构和布局，有良好的程序设计和架构能力；
    -精通vue或react； 熟悉并熟练使用es6语法，熟悉node.js；
    -掌握前端调试、性能优化、工程化等开发等相关技术；
    -具有至少一年以上移动端网页开发经验；
    -对web技术钻研有强烈兴趣，有良好的学习能力和强烈的进取心，能主动跟进新技术发展动态优先 ；
    -学习能力强，强烈的责任心,具有较强的沟通能力及团队合作精神 ；
    -有较强的产品理解，能从技术角度推动产品优化；
    -思维缜密、思路清晰，较好的逻辑分析能力；
    -了解一门后台语言(php或java)者优先；

    有意向的同学,请发送简历到 xuheng@baidu .com 🙂

    | Permalink
  85. ribenzhandianyo@163.com

    2017前端性能优化清单

    你开始使用渐进启动了么？是不是已经使用过React和Angular中tree-shaking和code-splitting两个工具？有没有用过Brotli、Zofli和HPACK这几种压缩技术，或者OCSP协议（在线证书状态协议）？知不知道资源提醒，客户端提醒和CSS containment一类的技术？了解IPv6，HTTP/2和Service Worker这些协议吗？

    回想那些年，大家往往在完成了产品之后才会去考虑性能。常常把与性能相关的事情拖到项目的最后来做，所做的也不过是对服务器上的config文件进行一些微调、串联、优化以及部分特别小的调整。而现在，技术已经有了翻天覆地的变化。

    一个项目的性能是非常重要的，除了要在技术层面上注意，更要在项目的设计之初就开始考虑，这样才可以使性能的各种隐形需求完美的整合到项目中，随着项目一起推进。性能最好具有可量化、可监测以及可改动的特性。网络越来越复杂，对网络的监控也变得越来越难，因为监测的过程会受到包括设备、浏览器、协议、网络类型以及其他技术（CDN，ISP，缓存，代理服务器，防火墙，负载均衡器和服务器对性能的影响都很大）的很大影响。

    下文是一份2017年的前端性能优化清单，阐述了作为前端开发人员，为了确保反馈速度以及浏览器兼容性我们需要考虑的问题。

    （你也可以下载checklist PDF或者check in Apple Pages。优化万岁！）

    正文

    微优化是保持性能最好的办法，但是又不能有太过明确的优化目标，因为过于明确的目标会影响在项目中做的每一个决定。以下是一些不同的模型，请按照自己舒服的顺序阅读。

    请准备好然后定下目标！

    1. 比你最强的竞争对手快20%

    根据一个心理学研究，你的网站最少在速度上比别人快20%，才能让用户感觉到你的网站比别人的更快。这个速度说的不是整个页面的加载时间，而是开始加载渲染的时间，首次有效渲染时间（例如页面需要加载主要内容的时间），或者交互时间（指的是页面或者应用中主要的页面加载完成，并主备好与用户进行交互的时间）。

    在Moto G（一个中端三星设备）和Nexus 4（比较主流的设备）上衡量开始渲染时间（用WebPagetest）以及首页有效渲染时间（用Lighthouse），最好是在一个开放的实验室中，使用规范的3G，4G和Wi-Fi链接。

    51e1615a-20181122111216-5bf68f100f284.png
    Lighthouse，一个Google开发的新的性能审查工具

    你可以通过你的分析报告看看你的用户处在哪个阶段，选取其中前90%的用户体验来做测试。接着收集数据，建一个表格，筛去20%的数据并预设一个目标（如：性能预算）。现在你可以将上述两个值进行对比检测。如果你始终维持着你的目标并且通过一点一点改变脚本去加快交互时间，那么上述方法就是合理可行的。

    8e55fff7-20181122111217-5bf68f1193a6a.png
    由Brad Frost创建的性能分析

    和你的同事分享这份清单。首先要确保团队中的每个人都熟悉这份清单。项目中每一个决定都会影响性能，如果前端工程师们都在积极的参与项目概念，UX以及视觉设计的决定，这将会给整个项目带来巨大收益。地图设计的决定违背了性能理念，所以他在这份清单内的顺序有待考虑。

    2. 反应时间为100毫秒，帧数是每秒60帧

    RAIL性能模型会为你提供一个优秀的目标，既尽最大的努力在用户初始操作后的100毫秒内提供反馈。为了达到这个目标，页面需要放弃权限，并将权限在50毫秒内交回给主线程。对于像动画一样的高压点，最好的方法就是什么都不做，因为你永远无法达到最小绝对值。
    同理，动画的每一帧都需要在16毫秒内完成，这样才能保证每秒60帧（一秒/60=16.6毫秒），如果可以的话最好能在10毫秒内完成。因为浏览器需要一定的时间去在屏幕上渲染新的帧，而且你的代码需要在16.6毫秒内完成执行。要注意，上述目标应用于衡量项目的运行性能，而非加载性能。

    3. 首次有效渲染时间要低于1.25秒，速度指数要低于1000

    纵使这个目标实现起来非常困难，你的最终目标也应该是让开始渲染时间低于1秒且速度指数低于1000（在网速快的地方）。对于首次有效渲染时间，上限最好是1250毫秒。对于移动端，3G下移动设备首次渲染时间低于3秒都是可以接受的。稍微高一点也没关系，但千万别高太多。

    定义你所需要的环境

    4. 选择和安装你的开发环境

    不要过多的关注当下最流行的工具，坚持选择适合自己开发环境的工具，例如Grunt、Gulp、Webpack、PostCSS，或者组合起来的工具。只要这个工具运行的速度够快，而且没有给你的维护带来太大问题，这就够了。

    5. 渐进增强（progressive enhancement）

    在构建前端结构的时候，应始终将渐进增强作为你的指导原则。首先设计并且构建核心体验，随后再完善那些为高性能浏览器设计的高级特性的相关体验，创建弹性体验。如果你的网页可以在使用低速网络、老旧显示器的很慢的电脑上运行飞快，那么在光纤高配电脑上它只会运行的更快。

    6. Angular，React，Ember等

    最好使用那些支持服务器端渲染的框架。在使用某个框架钱，先记录服务器和客户端的引导时间，记得要在移动设备上测试，最终才能使用某个框架（因为面对的是性能问题，如果在使用某个框架后，再做修改是非常困难的）。如果你使用JavaScript框架，要保证你的选择是被广泛使用并且经过考验的。不同框架对性能有着不同程度的影响，同时对应着不同的优化策略，所以最好可以清楚的了解你要用的框架的每个方面。在写网页应用时可以先看看PRPL pattern和application shell architecture。

    97ebe8d0-20181122111219-5bf68f1313114.png
    本图描述了PRPL pattern

    9d13a83e-20181122111220-5bf68f14c5593.jpg
    上图是application shell，是一个小型的、由HTML,CSS和JavaScript构成的用户界面

    7. AMP还是Instant Articles？

    根据你整体组织结构的优先顺序和策略，你可以考虑使用Google的AMP或Facebook的Instant Articles。要知道没有这些你也可以达到不错的性能，但是AMP可以提供一个性能不错的免费的内容分发网络框架（CDN），Instant Articles可以在Facebook上促进你的性能。你也可以建立progressive web AMP。

    8. 选择适合你的CDN

    根据你的动态数据量，可以将一部分内容外包给静态网站生成工具，将它置于CDN上，从中生成一个静态版本，从而避免那些数据库的请求。也可以选择基于CDN的静态主机平台，通过交互组件丰富你的页面（JAMStack）。

    注意CDN是否可以很好的处理（或分流）动态内容。没必要单纯的将你的CDN限制为静态。反复检查CDN是否执行了内容的压缩和转化，检查智能HTTP/2传输和缓存服务器（ESI），注意哪些静态或动态的部分处在CDN的边缘（最接近用户的服务器）。

    开始优化

    9. 直接确定优化顺序

    首先应该弄清楚你想解决的问题是什么。检查一遍你所有的文件（JavaScript，图片，字体，第三方script文件以及页面中重要的模块，例如轮播，复杂信息图标和多媒体内容），并将他们分类。
    列一个表格。明确浏览器上应该有的基础核心内容，哪些部分属于为高性能浏览器设计的升级体验，哪些是附加内容（那些不必要或者可以被延时加载的部分，例如字体，不必要的样式，轮播组件，播放器，社交网站入口，很大的图片）。更详细的细节请参考文章”Improving Smashing Magazine’s Performance‘’。

    10. 使用符合标准的技术

    使用符合标准的技术向过时的浏览器提供核心体验，向老式浏览器提供增强体验, 同时对所加载的内容要有严格的把控。即首要加载核心体验部分，将增强部分放在DomContentLoaded，把额外内容发在load事件中。

    以前我们可以通过浏览器的版本推断出设备的性能，但现在我们已经无法推测了。因为现在市场上很多廉价的安卓手机都不考虑内存限制和CPU性能，直接使用高版本的Chrome浏览器。一定要注意，在我们没有其他选择的时候，我们选择的技术同时可能成为我们的限制。

    11. 考虑微优化和渐进启动

    在一些应用中，可以在渲染页面前先初始化应用。最好先显示框架，而不是一个进度条或指示器。使用可以加速初始渲染时间的模块或技术（例如tree-shaking和code-splitting），因为大部分性能问题来自于应用引导程序的初始分析时间。还可以在服务器上提前编译，从而减轻部分客户端的渲染过程，从而快速输出结果。最后，考虑使用Optimize.js来加快初始加载速度，它的原理是包装优先级高的调用函数（虽然现在已经没什么必要了）。

    e79c04f0-20181122111222-5bf68f165c94b.jpg
    渐进启动指的是使用服务器端渲染，从而快速得到首次有效渲染，这个渲染过程也包括小部分的JavaScript文件，目的是使交互时间尽可能的接近首次有效渲染时间。

    到底采用客户端渲染还是服务器端渲染？不论哪种做法，我们的目标都是建立渐进启动：使用服务器端渲染可以得到很短的首次有效渲染时间，这个渲染过程也包括小部分的JavaScript文件，目的是使交互时间尽可能的接近首次有效渲染时间。接下来，尽可能的增加一些应用的非必要功能。不幸的是，正如Paul Lewis所说，框架基本上对开发者是没有优先级的概念的，因此渐进启动在很多库和框架上是很难实施的。如果你有时间的话，还是考虑使用策略去优化你的性能吧。

    12. HTTP的缓存头使用的合理吗？

    仔细检查一下例如expires，cache-control，max-age以及其他HTTP缓存头是否被正确的使用。一般来说，资源不论在短时间（如果它会被频繁改动）还是不确定的时间内（如果它是静态的）都是可缓存的——你大可在需要的时候在URL中成改版本。

    如果可能，使用为指纹静态资源设计的Cache-control:immutable，从而避免二次验证（2016年12月，只有FireFox在https://处理中支持）。你可以使用，Heroku的primer on HTTP caching headers，Jake Archibald的 ”Caching Best Practices”，还有IIya Grigorik的HTTP caching primer作为指导。

    13. 减少使用第三方库，加载JavaScript异步操作

    当用户请求页面时，浏览器会抓取HTML同时生成DOM，然后抓取CSS并建立CSS对象模型，最后通过匹配DOM和CSS对象生成渲染树。在需要处理的JavaScript文件被解决之前，浏览器不会开始对页面进行渲染。作为开发者，我们要明确的告诉浏览器不要等待，直接开始渲染。具体方法是使用HTML中的defer和async两个属性。

    事实上，defer更好一些（因为对于IE9及以下用户对于IE9及以下用户，很有可能会中断脚本）。同时，减少第三方库和脚本的使用，尤其是社交网站的分享按键和<iframe>嵌入（比如地图）。你可以使用静态的社交网站分享按键（例如SSBG的）和指向交互地图的静态链接去代替他们。

    14. 图片是否被正确优化？

    尽可能的使用带有srcset，sizes还有<picture>元素的响应式图片。你也可以利用<picture>元素的WebP格式，用JPEG格式作为替补（参见Andreas Bovens的code snippet）或是使用内容协商（使用接受头）。Sketch原本就支持WebP，WebP图片可以直接被Photoshop的WebP plugin导出。当然也有很多其他方法。

    22bf264f-20181122111223-5bf68f17a79a1.jpg
    响应图片断点生成器可自动处理图片

    你也可以使用客户端提示，现在浏览器也可以做到。在用来生成响应图片的源文件过少时，使用响应图片断点生成器或类似Cloudinary的服务自动的优化图片。在很多案例中，单独使用sreset和sizes都带来了很大的收益。在本网站上，我们给文件添加-opt后缀——例如brotli-compression-opt.png；这样团队的每一个人就知道这些带着后最的图片是被优化过的。

    15. 图片的进一步优化

    当你在编写登陆界面的时候，发现页面上的图片加载的特别快，这时你需要确认一下JPEG格式文件是否已经通过mozJPEG（它可以操作扫描等级从而提高渲染时间）优化和压缩，PNG格式对应Pingo，GIF需要用到Lossy GIF，SVG要使用SVGOMG。对图片不重要的部分进行模糊处理（使用高斯模糊过滤器处理他们），从而减少文件大小，最后你可能还要去彩色化使图片变成黑白，从而减少更多的容量。对于背景图片，使用Photoshop保持0到10%的质量输出是绝对可以接受的。

    如果你还觉得不够，那你可以通过多重背景图片技术来提高图片的感知性能。

    16. 网页字体优化了吗？

    你用来修饰网页字体的服务很有可能毫无用处，包括字形和额外的特性。如果你在使用开源的字体，尝试用字体库中某一个小的子集或是自己归类一个小的子集从而压缩文件大小（例如通过一些特殊的注音符号引用Latin）。WOFF2 support是个非常不错的选择，如果浏览器不支持，那你可以将WOFF和OTF作为备用。你也可以从Zach Leatherman的“Comprehensive Guide to Font-Loading Strategies”一文中选择一个合适的策略，然后使用服务器来缓存字体。如果想要快速入门，Pixel Ambacht的教程与案例会让你的字体变得尽然有序。

    02563745-20181122111224-5bf68f18eaf02.png
    Zach Leatherman的“Comprehensive Guide to Font-Loading Strategies”提供了一打可以让字体传输变得更好的选项

    如果你用的是第三方服务器主机，没办法自己在服务器上对字体进行操作，一定看看Web Font Loader。FOUT is better than FOIT中提到，在备选情况下立即渲染文本，并且异步加载字体——你也可以使用loadCSS实现这个。你可能也会避免本地OS上安装字体。

    17. 快速执行关键部分的CSS

    为了确保浏览器尽可能快的渲染你的页面，先收集页面首次可见部分的CSS文件（也叫决定性CSS或上半版CSS）进行渲染，然后将它加入页面的<head>部分，从而避免重复操作。因为慢启动阶段对交换包大小的限制，你关键CSS文件的大小也被限制在14KB左右。如果高于这个值，浏览器需要重复一些步骤来获取更多的样式。关键CSS是允许你这样做的。可能对每个模板都需要这个操作。如果可能，考虑一下用Fiament Group用的条件内敛方法。

    通过HTTP/2，关键CSS可以单独存为CSS文件，通过服务器传输，而且可以避免HTML膨胀。服务器传输缺乏连续支持，并且存在一些超高速缓存的问题（Hooman Beheshti演示的前144页）。事实上，这样会导致网络缓冲区膨胀。因为TCP的慢启动，服务器传输在稳定的连接下会更有效率。所以你可能需要建立带有缓存的HTTP/2服务器传输机制。但请记住，新的cache-digest规则会否定手动建立的需要缓存的服务器的请求。

    18. 通过tree-shaking和code-splitting减少净负载

    Tree-shaking是通过保留那些在项目过程中真正需要的代码从而清理你的构建过程的一种方式。你可以用Webpack 2来提出那些没用的住配置文件，用UnCSS或Helium从CSS中取出不需要的样式。同理，也可以考虑学习一下如何编写高效的CSS选择器，以及如何避免膨胀和高费的样式。

    Code-splitting是另一个Webpack特性，它可以根据按需加载的块将你的代码分开。只要你在代码中定义了分离点，Webpack便会处理好相关的输出文件。它基本上能保证你初始下载的内容很小，而且在需求被添加时按需请求代码。

    Rollup所展示的结果要比Browserify配置文件所显示的好得多。所以当我们想使用类似工具的时候，或许应该看看Rollupify，它将ECMAScript2015模块变成了一个更大的CommonJS模块——因为小模块没准有出乎意料的高性能成本，这源自于你对打包工具模块系统的选择。

    19. 提升渲染性能

    使用类似CSS containment的方法对高消耗组建进行隔离，从而限制浏览器样式的范围，可以作用在为无canvas的浏览工作的布局和装饰工作中，或是用在第三方工具上。要确保页面滚动和出现动画效果时没有延迟，别忘了之前提到过的每秒60帧的原则。如果没办法做到，那就尽可能保证每秒帧数的大致范围在15到60帧。使用CSS中的will-change通知浏览器哪些元素和属性发生了变化。

    也记得要衡量渲染执行中的性能（可以用DevTools）。可以参照Udacity上Paul Lewis的免费课程——浏览器渲染优化，作为入门。还有一篇Sergey Chikuyonok的文章讲了如何正确的用GPU动画。

    20. 预热网络连接，加快传输速度

    使用页面框架，对高消耗组建延迟加载（字体，JS文件，循环播放，视频和内嵌框架）。使用资源提示来节省在dns-prefetch（指的是在后台执行DNS检索），preconnect（指要求浏览器在后台进行握手链接（DNS，TCP，TLS）），prerender（指要求浏览器在后台对特定页面进行渲染），preload（指的是提前取出暂不执行的源文件）。根据你浏览器的支持情况，尽量使用preconnect来代替dns-prefetch，而且在使用prefetch和prerender要特别小心——后者（prerender）只有在你非常确信用户下一步操作的情况下再去使用（比如购买流程中）。

    HTTP/2

    21. 准备好使用HTTP/2

    Google开始向着更安全网页的方向努力，并且将所有Chrome上的HTTP网页定义为“不安全”时，你或许应该考虑是继续使用HTTP/1.1，还是将目光转向HTTP/2环境。虽然初期投入比较大，但是使用HTTP/是大趋势，而且在熟练掌握之后，你可以使用service worker和服务器推送技术让行性能再提升一大截。

    e5b1eb36-20181122111226-5bf68f1a6d555.png
    现在，Google计划把所有HTTP页面标记为不安全，并且将HTTP安全指示器设置为与Chrome用来拦截HTTPS的红色三角相同的图标。

    使用HTTP/2的环境的缺点在于你要转移到HTTPS上，并且根据你HTTP/1.1用户的数量（主要指使用过时操作系统和过时浏览器的用户），你需要适应不同的建构过程，才能发送不同的建构。注意：不论是迁移还是新的构建过程都可能非常棘手而且耗时很多。

    22. 适当部署HTTP/2

    重申，使用HTTP/2协议之前，你需要彻底排查目前为止你所使用协议的情况。你需要在打包组建和同时加载很多小组间之间找到平衡。

    一方面，你可能想要避免将很多资源链式链接，与其将你全部的界面分割成许多小模块，不如将他们压缩使之成为建构过程的一部分，之后给它们赋予可检索的信息并加载它们。这样的话，对一个文件将不再需要重新下载整个样式清单或JavaScript文件。

    另一方面，封装是很有必要的，因为一次向浏览器发送太多JavaScript文件会出问题。首先，压缩会造成损坏。得益于dictionary reuse，压缩大文件不会对文件造成损害，压缩小文件则不然。确实有方法可以解决这个问题，但这不是本文讨论的范畴。其次，浏览器还没有优化到可以对类似工作流进行优化。例如，Chrome会引发进程间通信（IPCs），这些通信的数量与资源的数量成正比，而这成百上千个资源将会消耗大量的浏览器的执行时间。

    62c1d5e8-20181122111227-5bf68f1b8f869.png
    Chrome的Jake Archibald建议，为了用HTTP/2达到最好的效果，考虑一下逐步加载CSS文件

    当然你可以考虑逐步加载CSS文件。很显然，你这样做对HTTP/1.1的用户非常不利，所以你可能需要根据不同的浏览器建立多个版本来应对你的调度过程，这样就会使过程略微复杂。你也可以避免HTTP/2连接的合并，同时受益于HTTP/2来使用域名碎片，但是实现起来有些困难。

    我们到底应该做什么呢？如果你粗略的用过HTTP/2，似乎成功的发送过10个左右的包（在老是浏览器上运行的也不错）。那你就能着手开始试验并且为你的网站找到平衡点。

    23. 确保服务器安全可靠

    所有的浏览器都支持HTTP/2并且使用TLS，这是有你可能想要避免安全警告，并删除页面上没用的元素。好好检查你的安全头部是否设置正确，排除已知的缺陷并检查证书。

    如果还没有迁移到HTTP， 你那可以先看看HTTPS准则（The HTTPS-Only Standard）。确保所有外部插件和监视脚本都能被HTTPS正确加载，确保没有跨站脚本出现，HTTP脚本传输的安全头和内容安全头也都设置正确。

    24. 你的服务器和CDN支持HTTP/2吗？

    不同服务器和CDN对HTTP/2的兼容性不同，你可以使用TLS够快吗？一文来查看你有什么选择。

    bd935ae6-20181122111228-5bf68f1cbe0a4.png
    Is TLS Fast Yet？让你能看看你的服务器和CDN在使用HTTP/2的时候你能使用的工具

    25. Brotli和Zopfli两种压缩算法还在用吗？

    2015年，Google介绍了Brotli，一个新的开源无损数据格式，它已经被Chrome，Firefox和Opera很好的兼容了。具体使用时，Brotli所显示出的效率要远高于Gzip和Deflate。它根据不同的配置可能压缩的时候会比较慢，但是压缩速度慢最后会让压缩效率提高。而且解压起来非常快。因为这个算法来自Google，所以浏览器只在用户通过HTTPS访问网页的时候使用它，这个事情就不奇怪了。Brotli的隐患是它没办法在目前大部分服务器上预设，而且如果没有NGINX或者Ubuntu，部署起来还是有难度的。但其实你是可以在不支持它的CDN上使用Brotli（通过service worker）。

    你可以看看Zopfli压缩算法作为备选，它将数据编码为Deflate，Gzip和Zlib格式。任何规范的Gzip压缩资源都受益于Zopfli改进了Deflate编码，因为文件会比Zlib压缩的最大文件小3%-8%。问题在于文件会消耗大概80倍的时间去压缩。这就是为什么在不怎么会变得资源上使用Zopfli是不错的选择，这样的文件一般都压缩一次，下载多次。

    26. OCSP装订是否可以使用？

    让服务器使用OCSP装订，可以提升你TLS握手的速度。线证书状态协议（OCSP）是作为证书废置列表协议的代替品被创造出来的。两个协议都可以用来检测SSL证书是否被取消。然而，OCSP不需要浏览器花时间下载和扫描证书信息的列表，所以它可以减少握手时间。

    27. 你是否开始使用IPv6？

    因为我们已经没什么IPv4的地址可用了，而且移动网络大都开始使用IPv6（美国已经有50%的入口采用IPv6），将你的DNS升级到IPv6为以后作打算是个不错的选择。要确保通网络可以支持双栈协议——它需要允许IPv6和IPv4同时运行。毕竟IPv6不只是做为后备计划的。而且研究显示，伴随邻居发现（NDP）和路由优化，使用IPv6的网站要比普通网站快10%到15%。

    28. 是否使用HPACK？

    如果你在使用HTTP/2，看看你的服务器有没有执行HPACK对HTTP的响应头进行压缩，来减少不必要的消耗。因为HTTP/2服务器相对较新，所以有些像HPACK这样的规格目前还没有被支持。我们可以用H2spec来检查HPACK是否在工作。

    fe6c82f4-20181122111230-5bf68f1ebb19b.png
    H2spec的截图

    29. service workers是否为超高速缓存和网络提供预设机制？

    没有经过优化的网络可以比用户机器的本地缓存跑得更快。如果你的网站在HTTPS上运行，你可以参考“实用主义者的service workers手册”，然后把静态资源存在service worker的缓存中，把离线预设（甚至离线页面）存在用户机器方便检索，这样比多次进行网络连接更有效。你还可以参考Jake的离线使用手册和免费的Udactiy课程“离线网络应用”。如果浏览器支持，那就再好不过了，预设就能在任何地方代替网络了。

    测试与监听

    30. 监听混合内容中的警告

    如果你近期完成了HTTP到HTTPS的迁移，你可以利用类似Report-URI.io一类的对主动和被动的混合内容警告都进行监听。也可以利用混合内容扫描器来对你使用HTTPS的网页进行扫描。

    31. 你的开发流程是否使用Devtools进行了优化？

    选一个调试工具来对每一个按钮进行检查。确保自己明白如何分析渲染性能和控制台输出、明白如何调试JavaScript以及编辑CSS样式。Umar Hansa最近有一个关于使用DevTools调试和测试的分享，主要包括一些不常用的技巧和技术。

    32. 是否使用代理浏览器和过时浏览器测试过？

    仅仅使用Chrome和Firefox测试是不够的。还应该看看你的网页在代理浏览器和过时浏览器上运行的怎么样。比如UC浏览器和Opera Min, 它们在亚洲市场的份额很高（高达35%）。在推广时，利用目标客户所在国家的平均网速来进行测试，避免日后出现大的误差。同样的，不仅要在节流网络以及模拟的高数据处理设备上进行测试，还要在真实设备上测试。

    33. 有无建立持续监听？

    在进行快速、无限制的测试时，最好使用一个个人的WebPageTest实例。建立一个能自动预警的性能预算监听。建立自己的用户时间标记从而测量并监测具体商用的数据。使用SpeedCurve对性能的变化进行监控，同时利用New Relic获取WebPageTest没法提供的数据。SpeedTracker，Lighthouse和Calibre都是不错的选择。

    快速入门

    这份清单综合性很强，几乎介绍了所有的可用的优化方式。那么，如果你只有一个小时进行优化，你应该干什么呢？让我们从中总结10个最有用的来。别忘了在你开始优化前和结束优化后，记录你的结果，包括开始渲染时间以及在3G，有限连接下的速度。

    1. 有线连接下，你的目标是将开始渲染时间降低至1s一下，而3G的目标是保持在3s一下，SpeedIndex值保持在1000一下。为开始渲染时间和交互时间做优化。

    2. 为你主要的模板准备关键CSS文件，将它们放在页面的<head>中（你可以使用14KB）。

    3. 对于你自己和第三方的脚本文件，尽可能的延迟加载它们——尤其是社交网站按钮，播放器和高消耗的JavaScript文件。

    4. 使用更快的dns-lookup，preconnect，prefetch，preload和prerender添加资源提示，从而加快传输速度。

    5. 将字体一类属性作为子集，异步加载（或者使用系统字体代替）。

    6. 优化图片，并考虑在关键页中使用WebP（例如登陆页面）。

    7. 确保HTTP的缓存头和安全头都被正确的设置。

    8. 在服务器上使用Brotli或Zopfli压缩算法。（如果不支持这两个，尝试一下Gzip）

    9. 如果HTTP/2可用，使用HPACK压缩算法，并监听混合内容的警告。如果你在使用LTS，就可以使用OCSP装订。

    10. 如果可能，将类似字体，JavaScript文件以及图片缓存在service worker缓存中——事实上越多越好！

    结语

    文中提到的一些优化可能超出了你工作的范围，有的可能超出了你的预算，有的甚至对你正在使用的有些过时的代码判了死刑。但没关系，本文只是一个普通大纲（希望能做到综合性强），你应该根据自己的工作环境列一份适合自己的清单。最重要的，在开始优化之前，先对项目中存在的问题有一个明确的了解。最后，祝大家2017年优化顺利！

    ———————————-我们需要的小伙伴————————————

    工作职责：

    -Web前端的功能设计、开发和优化，开发可重用模块
    -实现与视觉稿、交互稿一致的跨平台、浏览器、客户端，兼容性好的移动端页面和PC页面
    -前沿技术研究和新技术调研，

    职位要求：

    -精通JavaScript/HTML5/CSS3等相关前端开发技术，熟悉页面架构和布局，有良好的程序设计和架构能力；
    -精通vue或react； 熟悉并熟练使用es6语法，熟悉node.js；
    -掌握前端调试、性能优化、工程化等开发等相关技术；
    -具有至少一年以上移动端网页开发经验；
    -对web技术钻研有强烈兴趣，有良好的学习能力和强烈的进取心，能主动跟进新技术发展动态优先 ；
    -学习能力强，强烈的责任心,具有较强的沟通能力及团队合作精神 ；
    -有较强的产品理解，能从技术角度推动产品优化；
    -思维缜密、思路清晰，较好的逻辑分析能力；
    -了解一门后台语言(php或java)者优先；

    有意向的同学,请发送简历到 xuheng@baidu .com 🙂

    | Permalink

Likes

Shares