How to Improve Page Performance and Make the Most of Your Hosting

Server farm

This article was sponsored by Hosting Facts. Thank you for supporting the sponsors who make SitePoint possible.


You can spend months building an amazing website only to let yourself down at the last stage with inadequate optimization or hosting.

Average page weight has reached 2,300KB and increases around 15% every year. The rise of projects such as Google Accelerated Mobile Pages, Facebook Instant Articles and ad-blockers highlight user frustration with the web we’ve created. Obese pages:

  • are slower to load and render
  • struggle on mobile networks and may cost users money
  • are less responsive on slower devices and smartphones
  • will affect your search engine rankings
  • are more difficult to update and maintain.

Few developers bother to optimize their sites so why should you?

The reason: there’s no downside. Your search engine rankings improve. Your users benefit from a slicker experience. Your conversions increase. Your hosting charges drop. Unlike real life, the most drastic weight loss can be achieved with minimal effort…

Site Analysis Tools

Assess the scale of any problems before making changes. Several free tools are available which report the number of requests, file sizes and server response speed. Some provide improvement suggestions.

Alternatively, use the Network or Profiling tools in your browser’s development tools to assess your site. Make a copy of the statistics so you can compare improvements later.

The following sections provide optimization suggestions starting with the easiest changes.

Find a Suitable Web Host

Your site may have taken considerable time and money to create. Should you really host it on a $5 per month service?

Take time to assess whether you need space on a shared server, your own private server or a cloud-based virtual server. Read hosting reviews at sites such as Hosting Facts and seek advice from others with similar requirements. At this moment, they’re suggesting to use A2 Hosting or A Small Orange.

Use a Content Delivery Network (CDN)

Browsers limit HTTP requests to between four and eight simultaneous connections per domain. Loading 40 page assets at once is not possible – files are queued on each request thread.

In addition, your users may be located in a different geographical location to your server. A user in France would see a faster response from a UK-based server than similar hardware in Australia.

A CDN increases download speeds by distributing web site assets to other servers. Those machines can be physically closer to the user and run from different domains which more than doubles HTTP request limits.

CDNs have become simpler to use and many automatically handle assets once you’ve configured DNS settings. Popular options include:

Enable GZIP Compression

Around a third of websites do not enable Gzip compression yet it can drastically reduce the amount of data sent to the browser. Gzip compression is often set by your web host on the server – contact them for further advice.

Enable Caching

Caching ensures a browser downloads asset files once. The local version is retained until your website instructs it to fetch an update. The first page load won’t be faster but subsequent page loads will be considerably improved.

There are plugins for Content Management Systems such as WordPress which make caching simple, e.g. W3 Total Cache or WP Super Cache.

Other systems can adopt technologies such as Expires, Last-Modified, Keep-Alive or Etag in the HTTP header. Your host may provide configuration options or you can define your own. For example, an Apache .htaccess setting to cache all images for one month:

<IfModule mod_expires.c>
ExpiresActive On

<FilesMatch ".(jpg|jpeg|png|gif|svg)$">
ExpiresDefault "access plus 1 month"


Optimize Your Media

Images account for more than 60% of page weight. The average page requests 55 separate images at 1,457KB, 126KB of fonts, 400KB of video and 45KB of Flash. This seems slightly preposterous given the current trend for simplistic, plain-colored flat-designs!

The first step: remove unnecessary assets. Do you need that background video, hero image, italic font or 300 icons few will ever see? Can you use a subset of a font? Could you replace some images with CSS3 effects such as gradients or borders?

Presuming an image is required, ensure you use the most efficient format. In general:

  • SVG is suitable for line diagrams
  • Web fonts may be an option for single-color icons
  • PNG or perhaps GIF is best for smaller images with clear color definitions such as icons, buttons and screenshots
  • JPG is best for photographs or anything where fine detail is less important.

If in doubt, experiment with different types until you find the best compromise between quality and file size.

Large images should be resized to reduce the resolution. An entry-level smartphone camera produces high-resolution photographs of several megabytes but you rarely need an image greater than 2,000 pixels wide for the best of today’s screens.

Next: ensure your images are the optimal size. Few graphics packages remove all possible data and most will retain unnecessary colors or EXIF meta data such as dates, locations and camera settings. One-off compression tasks can be achieved using online tools such as TinyPNG/JPE or Installable processing tools such as OptiPNG, PNGOUT, jpegtran and jpegoptim can bulk-compress images. You can introduce compression systems such as imagemin into your build process or CMS users have options such as WP Smush which automatically compress uploaded files.

Smaller images can be combined into a single image sprite to reduce the number of HTTP requests. This has less of an advantage in HTTP/2 but icons used on every page can still benefit from being combined.

Finally, consider Base64-encoded inline data URIs for smaller, regularly-used images, e.g.

.bullet {
    background-image: url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAQMAAAAlPW0iAAAABlBMVEUAAAD///+l2Z/dAAAAM0lEQVR4nGP4/5/h/1+G/58ZDrAz3D/McH8yw83NDDeNGe4Ug9C9zwz3gVLMDA/A6P9/AFGGFyjOXZtQAAAAAElFTkSuQmCC");

This reduces the number of requests although maintenance can be more difficult. Online tools such as and data:URI Generator are fine for one-off conversions. There may also be encoder plugins for your editor/IDE but the easiest solution is PostCSS Assets – a PostCSS plugin – which magically converts any image, e.g.

.inline {
    background-image: inline('image.png');

Continue reading %How to Improve Page Performance and Make the Most of Your Hosting%

Source: Sitepoint

Design and Build Your Own JavaScript Library: Tips & Tricks

This article was peer reviewed by Adrian Sandu, Vildan Softic and Dan Prince. Thanks to all of SitePoint’s peer reviewers for making SitePoint content the best it can be!

Libraries: we use them all the time. A library is packaged code that developers can use in their projects, which invariably saves work and prevents reinventing the wheel. Having reusable packages, either open or closed-source, is better than rebuilding the same feature, or manually copying and pasting from past projects.


But other than packaged code, what is a library exactly? With a few exceptions, a library should always be one file, or several in a single folder. Its code should be maintained separately and should remain as-is when implementing it in your project. A library should allow you to set project-specific configuration and/or behavior. Think of it as a USB-device that only allows communication through the USB port. Some devices, such as mice and keyboards, allow configuration through an interface provided with or by the device.

In this article, I will explain how libraries are built. Although most of the topics covered will apply to other languages, this article is mainly focused on building a JavaScript library.

Why Build a Library?

First and foremost, libraries make the reuse of existing code very convenient. You don’t have to dig up an old project and copy some files, you just pull the library in. This also fragments your application, keeping the application codebase smaller and making it easier to maintain.

Christ Church Library, Oxford
Christ Church Library (source)

Any code that makes achieving a certain goal easier and which can be reused, like an abstraction, is a candidate to be bundled into a library. An interesting example is jQuery. Although jQuery’s API is considerably more than a simplified DOM API, it meant a lot a few years ago, when cross-browser DOM manipulation was rather difficult.

If an open-source project becomes popular and more developers use it, it’s likely people will join in and help with that project by submitting issues or contributing to the code base. Either way, it will benefit the library and all the projects depending on it.

A popular open-source project can also lead to great opportunities. A company may be impressed by the quality of your work and offer you a job. Maybe a company will ask you to help integrate your project into their application. After all, no one knows your library better than you.

For many it’s merely a hobby—enjoying writing code, helping others, and learning and growing in the process. You can push your limits and try new things.

Scope and Goals

Before writing the first line of code, it should be clear what the purpose of your library is—you have to set goals. With them, you can maintain focus on what problem you hope to solve with your library. Keep in mind that your library should be easier to use and to remember than the problem in its raw form. The simpler the API, the easier it will be for users to learn to use your library. To quote the Unix philosophy:

Do One Thing and Do It Well

Ask yourself: What problem does your library solve? How do you intend to solve it? Will you write everything yourself, or can you utilize someone else’s library?

No matter the size of the library, try to make a roadmap. List every feature you want, then scrap as many as you can until you have a tiny, but functional library, much like a minimum viable product. That will be your first release. From there, you can create milestones for every new feature. Essentially, you’re breaking up your project into bite-size chunks, making every feature more of an accomplishment and more enjoyable. Believe me, this will keep you sane.

API Design

Personally, I really like to approach my library from the perspective of the end user. You could name it user-centric design. In essence, you are creating an outline of your library, hopefully giving it more thought and making it more convenient for whoever chooses to use it. At the same time you get to think about which aspects should be customizable, something discussed later in this article.

The ultimate API quality test is to eat your own dog food, to use your library in your own projects. Try to substitute application code with your library, and see if it covers all the features you desire. Try to keep the library as bare as possible, while keeping it flexible enough to make it work for their edge-cases too, through customization (as described later in this article).

Here’s an example of what the implementation, or outline of a User-Agent string library could look like:

// Start with empty UserAgent string
var userAgent = new UserAgent;

// Create and add first product: EvilCorpBrowser/1.2 (X11; Linux; en-us)
var application = new UserAgent.Product('EvilCorpBrowser', '1.2');
application.setComment('X11', 'Linux', 'en-us');

// Create and add second product: Blink/20420101
var engine = new UserAgent.Product('Blink', '20420101');

// EvilCorpBrowser/1.2 (X11; Linux; en-us) Blink/20420101

// Make some more changes to engine product
engine.setComment('Hello World');

// EvilCorpBrowser/1.2 (X11; Linux; en-us) Blink/20420101 (Hello World)

Depending on the complexity of your library, you may also want to give some thought to structuring. Utilizing design patterns is a great way to structure your library, or even to overcome some technical problems. It also reduces the risk of refactoring large parts when adding new features.

Continue reading %Design and Build Your Own JavaScript Library: Tips & Tricks%

Source: Sitepoint

The Web Should Just Work for Everyone: Microsoft Edge and Inclusive Design


This article is part of a web development series from Microsoft. Thank you for supporting the partners who make SitePoint possible.

This article is part of the web development series from Microsoft tech evangelists and engineers on practical JavaScript learning, open source projects, and interoperability best practices including Microsoft Edge browser and the new EdgeHTML rendering engine. 

We encourage you to test across browsers and devices including Microsoft Edge – the default browser for Windows 10 – with free tools on, including the EdgeHTML issue tracker, where you can report or search EdgeHTML issues, such as problems with site rendering or standards compliance. Also,  visit the Edge blog to stay updated and informed from Microsoft developers and experts.

Continue reading %The Web Should Just Work for Everyone: Microsoft Edge and Inclusive Design%

Source: Sitepoint

Quick Tip – Installing the Ionic Framework for HTML5 Apps

Ionic is a framework for building hybrid mobile apps using the web technologies you know and love, Angular and Cordova. The Ionic 2 release (currently in beta) leverages Angular 2 (also in beta) and ES6, and you can opt into TypeScript if you prefer.

It allows you to write your application code once in HTML, CSS and JavaScript and deploy to multiple targets using the same code and have them look and feel like native iOS and Android apps.

Continue reading %Quick Tip – Installing the Ionic Framework for HTML5 Apps%

Source: Sitepoint

¡Vamos! Break Out Of The Box With SmashingConf Barcelona 2016


You can’t be extraordinary in every project, but knowing how and when to break out of the box can go a long way. The upcoming SmashingConf Barcelona, taking place on October 25–26, will be packed with smart solutions ranging from front-end to visual design to UX — and a few delightful surprises along the way. To the early-bird-tickets.

SmashingConf Barcelona 2016

How do we avoid common traps in UX and front-end development? How do we break out of the predictable, generic, boxy layout? How do we solve complex problems more efficiently? With the second conference in magnificent Barcelona, we’ll explore practical techniques and design patterns from real projects.

The post ¡Vamos! Break Out Of The Box With SmashingConf Barcelona 2016 appeared first on Smashing Magazine.

Source: Smashing Magazine

Desktop Wallpaper Calendars: June 2016


We always try our best to challenge your artistic abilities and produce some interesting and unique artwork, and as designers, we usually turn to different sources of inspiration. As a matter of fact, we’ve discovered the best one: desktop wallpapers that are a little more distinctive than the usual crowd.

Desktop Wallpaper Calendars: June 2016

This creativity mission has been going on for eight years now, and we are very thankful to all designers who have contributed to it and who are still enthusiastically continuing to do so each month. This post features free desktop wallpapers created by artists across the globe for June 2016. Both versions with and without a calendar can be downloaded for free. It’s time to give your desktop a makeover!

The post Desktop Wallpaper Calendars: June 2016 appeared first on Smashing Magazine.

Source: Smashing Magazine

Jump Start Sass: Architecture in Sass


The following is a short extract from our recent book, Jump Start Sass, available for free to SitePoint Premium members. Print copies are sold in stores worldwide, or you can order them here. We hope you enjoy this extract and find it useful.

Architecture has always been one of the major pain points in CSS development. Without any variables, control directives, macros, or object inheritance, CSS code tends to be long and repetitive—a single ever-growing file. While it’s technically possible to split plain CSS into multiple files that reference each other with @import, the additional HTTP requests make that a poor solution. As you’ve seen, Sass has an answer for every piece of the architecture puzzle—but what’s the best way to put it all together?

Ask ten experts, and you’ll receive ten different answers—most of them involving (or aided by) Sass. OOCSS, SMACSS, Atomic Design, ITCSS, and BEM are all popular systems for CSS architecture, but there are many more. If you’re using a front-end framework such as Bootstrap or Foundation, there might be some architectural opinions already built in.

These are all solid systems, none of which were designed with your project in mind. CSS architecture is hard, so it’s a mistake to trust any one-size-fits-all solution. There is no “right” answer that works for every team on every project. We’d recommend learning them all, and then mashing together the best parts to create a system that works well for you.

Let’s start with a broad discussion of the building blocks, and then look at the ways we can fit them together.

Multiple Files and Folders

Breaking your code into multiple files is one key advantage to using a preprocessor, and forms the basis of any architecture. With Sass, there’s no harm in breaking your code into the smallest logical units and organizing it into multiple files and folders. We recommend taking full advantage of it.

Sass has bestowed new power on the CSS @import rule, allowing you to combine Sass and CSS files during compilation so they can be sent to the browser as one single file. This is the only place where Sass has stepped on the toes of an existing CSS directive, so it behaves differently in Sass than it did in CSS.

CSS Imports

As mentioned, the CSS @import directive allows you to reference one CSS file from another. Importing is handled by the browser and requires additional HTTP requests—since the importing file has to be parsed before the @import directive is discovered. If you have a chain of files importing each other, those imports will happen in sequence, blocking the document from rendering until all the CSS has loaded. For that reason, most people avoid CSS imports entirely.

Using CSS imports, you can reference another CSS file using relative or absolute paths, even adding a media query rule for conditional imports. Even though Sass provides different functionality under the same at-rule, there are various cases in which Sass will fall back to the vanilla CSS output, such as when:

  • an imported file has a .css extension

  • a filename begins with http:// or https://

  • the filename is a url(..) function

  • @import has any media queries

The following will compile to standard CSS imports, even in Sass:

[code language=”css”]
@import ‘relative/styles.css’;
@import ‘’;
@import url(‘landscape.css’) screen and (orientation: landscape);[/code]

Sass Imports and Partials

Sass imports look similar to CSS imports, but the imported files are compiled into one single output file, as though their contents (including variables, mixins, functions, and placeholders) were copied and pasted into place before compilation. This type of Sass import will only work on files with .sass or .scss extensions, but you can leave the extension off when importing (as long as there are no similarly named files). In fact, we recommend dropping the extension whenever you can, for simplicity. It’s also possible to import multiple files in one command, or import files into a nested context:

Continue reading %Jump Start Sass: Architecture in Sass%

Source: Sitepoint

8 Things You Shouldn’t Do at Your Investor Meeting

Man running late

Getting funding today isn’t too hard. As one of my good friends once sarcastically said when I lived in Silicon Valley, “Everyone and their mothers is an investor out [in Silicon Valley],” going on to tell me that you don’t need a groundbreaking product to secure investment. When investors put money into startups, they’re betting on the entrepreneur. Since pivots are a necessity with most startups, investors look for entrepreneurs who can handle change and aren’t banking on a single idea.


While this article is about preparing to meet with investors, it’s worth mentioning that angel and venture capital should be a last resort for your funding. As soon as you take on an investor, you’ll need to meet their demands, even if they go against your original direction.

It’s cheaper than ever to start a software company. Aside from bootstrapping, you could technically take on small amounts of debt, or even crowdfund your software project. If you’re in the hardware space, many investors only speak with successfully crowdfunded products because it’s an effective way to minimize the risk of their investments.

Here are eight things you shouldn’t do when trying to get an investor meeting, or once you’re in the meeting itself.

Don’t Ignore Your Network

Getting a meeting with an investor is hard, but it’s not impossible. Going back to my friend, he (again, sarcastically) summed up the venture capital space as “a good old boy’s club.” The best option you have to secure a meeting with an investor is to connect with the employees of venture-backed companies. Investors rarely make investments from cold leads. They usually only take meetings via referrals, whether those come from other investors, executives from their portfolio companies, or people close to them.

Don’t Jump the Gun

It’s much easier to raise capital today than it was in the past. One of the fastest ways to destroy your company is to accept funds from an investor who isn’t a good fit for your business. That’s why you can’t just take the first offer that comes to you during the fundraising process.

When you raise capital you should choose an investor who has skills that complement those your team has. If you have domain expertise in hardware or software engineering, a good potential investor is someone who has a track record of bringing new technologies to market.

Don’t Worry about Projection Accuracy

As you’re developing your pitch deck, you shouldn’t worry too much about your financial projections. It’s a given that those numbers are going to be wrong. If they were correct, most investments would turn a profit.

The main purpose of projections is to show that you’ll spend the money wisely and that you’re being realistic about your growth expectations.

Don’t Talk about Market Size

If you’ve seen SharkTank, you know that one of the most popular lines is something like “we’re tackling a billion-dollar industry.” Sometimes the entrepreneurs will say that they just need one percent of the market to make millions.

Investors don’t need to you to tell them the size of an industry. If they’re meeting with you, they already know there’s potential to make money. Taking that a step further, investors don’t want to work with someone who is content with getting a sliver of market share in a space.

Continue reading %8 Things You Shouldn’t Do at Your Investor Meeting%

Source: Sitepoint

4 Steps to Boosting Conversions with Prioritized Navigation

A well-conceived navigation strategy can make or break any website. When done right, you lay out a path you want site visitors to take, leading to a sale, lead generation, or a successful form submission.

When done wrong, you are essentially allowing your visitors wander aimlessly. There’s a chance they will find your target, but probably not. Why chance it?

Good UX should never treat conversions so casually – it should take users by the hand, and provide intuitive cues that they can pick up on. That way, they know where to find what they need, while giving into what you wanted all along – a conversion.

In this article, I’m going to walk you through a simple strategy you can use on just about any site to boost its conversion rate.

When used properly, you can deliver clients a website that will not only look great but will actually help them succeed at their business goals.

In other words, you’ll be their hero.

Step 1: Adopt a Landing Page Strategy

Adopt a Landing Page Strategy

Knowing what we know about online marketing in 2016, every website should be using landing pages as a part of its conversion strategy. If you are applying this to a redesign, this step doesn’t require you to eliminate existing pages, but rather add to what you have.

The idea is that you build self-contained pages that have all of the necessary information required to properly convince a visitor to convert. The number of landing pages will vary, depending on the business and its goals. For simplicity’s sake, let’s use your own portfolio website as an example.

Let’s say you offer both web design and logo design as services. In addition to your simple portfolio pages which show your work, you would want to build two new landing pages – one for each service. On each landing page, you might include portfolio highlights, some convincing sales copy, a bulleted list of benefits you can provide, customer testimonials, and a clear call-to-action (CTA.)

The reason for these landing pages is this: You don’t want your visitors to have to click around from page to page. Give them everything they need in one place. This will result in a much more focused sales funnel, and you don’t risk losing them along the way.

Highlight Your &quot;Money&quot; Pages

Step 2: Highlight Your “Money” Pages

In addition to your new landing pages, are there any pages that you think are necessary to the conversion process? Maybe an entire page of testimonials perhaps? Or a list of your other services?

If this is the case, then you have a few options:

Placing links within the body copy of your landing pages can be a great way of leading site visitors through a pre-chosen path. Let’s say you have a few case studies on your landing page. You might want to offer them a look at more of them through a contextual link underneath the case study examples.
Image Source:

Limited Header Navigation

Another way to go is to choose your top two or three pages and link to them through a pared-down header navigation bar. Following the same portfolio site example, you might want to include links to both of your landing pages within the header, allowing visitors to toggle back and forth between your different offerings.

enter image description here
Image Source:

Ideally, you would want to make this header bar “sticky,” so that it stays in place as users scroll down the page.

De-emphasize Everything Else

Step 3: De-emphasize Everything Else

Have you ever heard of “decision fatigue?” It is basically the concept that says people given too many options are less likely to take any action at all. There was a famous study illustrating this concept with jam.

Researchers lined a small shelf at a grocery store with five varieties of jam. Passersby would stop to look at the selection and most who stopped selected one. Later that day, they added more options, until there were thirty jams to choose from. People would stop to look, feel overwhelmed by the sheer number of choices, then keep walking.

This isn’t what we want on a website. When you give visitors too many navigational choices, they may not see a clear path, and bounce. Here’s how to fix it:

All other pages should not be presented as primary options. They will be designated as secondary navigation.

It is up to you how you want to handle this secondary navigation. You can either place it in another, less important position on the page, (such as just above the footer,) or you may choose to store it in a hidden drawer menu, accessible by a menu button.

Yes, I know this is a hotly contested debate between UX-perts. Many of them hate the idea of hidden navigation for the extra barrier it creates. But remember: your landing pages and your primary navigation items should be enough to entice a conversion. The secondary pages are only there for those who choose to seek them out.

By eliminating the less important options, (or at least de-emphasizing them,) people will have a much clearer path in front of them, which is good user experience by any measure.

Step 4: Place Your CTA Button

A clear, strong CTA is the entire purpose of a website.

Following our same portfolio site example, suppose your end goal is to get your prospective clients to fill out a form in order to schedule a consultation with you. Once you have that part figured out, you’ll want to put it in a place of honor, where it will most likely be seen.

In addition to strategically placing it within the body of your landing pages, I recommend placing it in the main header navigation as well.

But in order to make it stand out from your other two or three navigation options, you should style it as a button. This gives it a bit more visual punch, especially if it is a bright pop of color that stands out against the rest of the content on your site.

enter image description here
Img Source:

Continue reading %4 Steps to Boosting Conversions with Prioritized Navigation%

Source: Sitepoint

Project Documentation with Hexo Static Site Generator

When starting an open source project, one of the most important things is to create project documentation. Documentation is essential if we want our project to be used by others, and it can be done in many ways:

  • GitHub Wiki – GitHub lets us make a wiki associated with each project. It is composed of pages written with markdown and is definitely a tool to take into consideration to build documentation. However, it does have a few limitations: contributions to a wiki don’t appear in the project contributions; is limited to a strict structure and layout; you must host assets in other locations.
  • README – we can create a, which will show on the GitHub project page. It might be a good solution if the documentation will be very short, otherwise it gets a big one page full of information. Usually this serves to introduce the project and not to show documentation.
  • Self Hosted – we can create a custom site for our documentation. This gives us total freedom to create what we want, but it prevents possible contributions to our documentation. It also comes with the price of hosting.
  • GitHub Pages – GitHub also provides a way of hosting a static site for each project. By creating a branch called gh-pages in your project’s repo, GitHub will publish its contents as a website. This is great to place a documentation site, although, maintaining documentation in a separate branch is not optimal: documentation files get hard to find for contributors and contributions won’t show up in the master branch.

Fortunately, there’s a way of combining the best parts of the options above.

Introducing Hexo

Hexo is a static site generator built with Node.js. It is mostly used as a blog framework, but it has a deploy integration for GitHub which makes it a great fit to build a documentation site for a GitHub project.

With Hexo, we can create markdown files and HTML layouts which will be converted to static HTML files when deployed. Hexo provides a deploy configuration which builds our static files into a GitHub branch. This means we can maintain our documentation as markdown in our project’s master branch and deploy it, with one command, to gh-pages.

Installing Hexo

Hexo is built with Node.js, so to install and use it we’ll need Node.js installed in our system. We’ll also need Git which will be used by Hexo to deploy our documentation site to gh-pages.

Installing Node.js

To install Node I recommend using a version manager, such as nvm. There are other version managers out there that you can use, but they all make life easier when it comes to installing and switching between Node.js versions.

Using nvm, let’s run the following:

nvm install 4

This will install the most recent release of Node.js 4.x, which also comes with npm ready to use.

Installing Git

We’ll also need Git installed in our system. If you’re not sure you already have it, run the following:

git --version

If the result is a Git version you can skip this section. If instead you see an error, you’ll have to install it first.


On a windows system we can run an installer provided by Git.


On OS X, we can install it in one of three different ways:

  • Using the installer.
  • Using Homebrew by running brew install git.
  • Using MacPorts by running sudo port install git +doc +bash_completion +gitweb.

Usually, I prefer using Homebrew to install this type of software, but if you’re more familiar with MacPorts or just want to use the installer, there’s nothing wrong with that.

Linux – Ubuntu or Debian

On an Ubuntu or Debian-based system we can install Git with apt:

sudo apt-get install git-core

Linux – Fedora, Red Hat or CentOS

On a Fedora, Red Hat or CentOS system we can install Git with yum:

sudo yum install git-core

Installing Hexo CLI

After installing Node.js and Git we can now finally install Hexo by running:

npm install -g hexo-cli

To make sure everything is set up, type the following:

hexo --version

If you see a list of versions, good news: you have everything ready to use Hexo!

Setting Up

Now that we have Hexo installed, we can now start to create our documentation on our GitHub master branch. To follow this article, you can either:

  • Create the documentation for one of your existing GitHub projects
  • Create a new repo here

For simplicity, I’ll assume you’re creating a new project called hexo-documentation, but you can follow the article with an existing one.

Let’s clone the GitHub repo locally by running:

git clone

Replace USERNAME with your username and REPOSITORY with the name you gave to your repo. In my case, the command would be:

git clone

Now let’s cd into it and create a folder called docs:

cd hexo-documentation
mkdir docs

The docs folder is where our documentation site will be, and it’s where we’ll initialize Hexo by running:

hexo init docs

What the command above does is add a bunch of Hexo’s configuration and dependency settings. But we still need to install those dependencies, which are defined in a package.json file inside the docs folder. To do so, let’s run the following:

Continue reading %Project Documentation with Hexo Static Site Generator%

Source: Sitepoint