# OptimizedHTML: a Gulp front-end starter aimed at PageSpeed scores

> OptimizedHTML is a starting HTML template that assembles Sass, Bootstrap grid, Autoprefixer, PostCSS, Uglify, image optimisation and FTP or rsync deployment into one Gulp build, with source in app/ and a production folder in dist/. The conventions are strict, which is what makes it work as a template rather than a pile of examples.

**wdmcourses/optimizedhtml-start-template** — OptimizedHTML is all-inclusive, optimized for Google PageSpeed start HTML5 template with Bootstrap (grid only), Gulp, Sass, Browsersync, Autoprefixer, PostCSS, Uglify, gulp-imagemin, Vinyl-FTP (+Rsync) and Bower (libs path) support. The template contains a .htaccess file with caching rules for web server.

- Repository: https://github.com/wdmcourses/optimizedhtml-start-template
- Website: https://webdesign-master.ru/blog/tools/optimizedhtml.html
- Stars: 713 · Forks: 395
- Language: JavaScript
- License: not declared
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/wdmcourses-optimizedhtml-start-template

## A template with a house style, not a demo

OptimizedHTML is described as an all-inclusive, optimized for Google PageSpeed start HTML5 template, and the second sentence of the README tells you what that means in practice. It uses a Sass with Sass syntax and a project structure with source code in the app directory and a production folder dist, which contains a ready project with optimized HTML, CSS, JS and images.

The design brief is a template that has already made the decisions most starters leave open. Bootstrap is included at grid only, so you get the grid and the reboot and none of the components. Gulp is the build tool, with Sass for styles, Browsersync for the live reload, Autoprefixer and PostCSS for the CSS pipeline, Uglify for the JavaScript, gulp-imagemin for images, Vinyl-FTP and rsync for deployment, and Bower for the libraries path. The template also contains a .htaccess file with caching rules for the web server.

The strictness is the point. There is a rules section for working with the starting HTML template, and it reads like a style guide enforced by convention rather than by tooling. All HTML files should have similar initial content to app/index.html. All custom JavaScript goes in app/js/common.js. All Sass variables go in app/sass/_vars.sass, all fonts in app/sass/_fonts.sass with a font-face mixin, all Bootstrap media queries in app/sass/_media.sass, and the CSS for JS libraries in app/sass/_libs.sass.

That layout is the thing you are buying. You get a project where the variables have one home, the fonts have one home, and the media queries have one home, and every file in the template expects those paths to be true. A contributor who moves a file breaks the build in a way that is annoying but never silent.

The primary language is JavaScript, the default branch is master, the last push was on 2026-07-15, and the release list shows 3.2.5, 3.2.6 and 3.2.7 in 2025.

## Getting it running, which takes four steps

The usage section is four steps, and two of them are things you would not guess from a front-end template.

First you download optimizedhtml-start-template from GitHub, using the archive link in the README. Second, if you are on Windows, you install WSL, and the manual link for that is provided. Third you install the Node modules in the project folder with npm i. Fourth you run the template with gulp.

The WSL step is the one that tells you what this project assumes. A Gulp build with a make-like task runner, a Sass compiler and a Browsersync server is a Unix-flavoured toolchain, and the template's answer for Windows users is to run the build inside the Windows Subsystem for Linux rather than in a native Windows shell. The reason is the deploy tasks, which use rsync and Vinyl-FTP.

That is also why the file layout at the top level is what it is. There is a .bowerrc, a .gitignore, the app/ directory, a gulpfile.js, a package.json and a readme.md, and the package.json is minimal. The name is optimizedhtml, the version is 3.2.0, the main is index.js, the type is module, the licence field is ISC, and the only script is a start script that runs gulp.

There is a browserslist entry set to the last 10 versions, which is the one line in that manifest that quietly affects your output, because Autoprefixer uses it to decide which vendor prefixes to emit. The devDependencies are the build itself, and they are worth reading as a list of decisions: gulp 5 with gulp-sass 6 and sass 1.85, PostCSS through gulp-postcss with autoprefixer and cssnano, gulp-uglify for the JavaScript, the imagemin family for images, gulp-concat and gulp-rename and gulp-cache and del for the task plumbing, browser-sync 3, gulp-rsync and vinyl-ftp for the two deployment routes, and gulp-imagemin with the mozjpeg, pngquant and svgo plugins.

## Five gulp tasks and what each one does

The task list is short and each entry does a distinct job.

The default gulp task runs sass, js, watch and browserSync, and it is the development loop. The build task builds the project to the dist folder, and the description is specific that it cleans up, optimises images and removes unnecessary files. The deploy task deploys the project on the server from the dist folder via FTP, and the rsync task does the same via rsync. And clearcache clears all the gulp cache.

Two things stand out. First, the build task is a separate command from the default one, so the production build is not something you trigger by accident while editing. Second, the deploy tasks operate on the dist folder, not on the source, which means you cannot deploy a half-built project, because the dist folder only exists after a build.

The image optimisation deserves a note because it is the piece that is easiest to get wrong by hand. The imagemin setup uses three compressors: mozjpeg for JPEG, pngquant for PNG and svgo for SVG. Those are lossy and format-specific, and running them on every build means the images in dist are not the images in app. It also means the gulp cache matters, because recompressing the same images on every watch cycle would be needlessly slow, which is what the cache is for and why there is a task to clear it.

The JavaScript side is uglify through gulp-uglify, which is the older of the two common choices. The current mainstream alternative is a modern bundler with a terser plugin, and the difference is not just the minifier, it is that this template has no module bundler at all. Bower is used to place library files into a libs directory, and the js task in the gulpfile is where you list their paths.

## Bower, the libs directory, and why the paths are declared by hand

The library story is the part of this template that dates it, and the rules section spells out the mechanism.

To install a new JavaScript library you run bower i plugin-name in the terminal, and the libraries are automatically placed in the app/libs folder. Bower must be installed in the system with npm i -g bower. Then you place all the JavaScript library paths in the js() task in the gulpfile.js.

So the flow is: a global Bower install, a per-library install command, files landing in app/libs, and then a manual edit to the gulpfile to reference them. There is no manifest of dependencies in package.json for the front end libraries, because Bower had its own manifest in the .bowerrc at the top of the tree.

That is the structural weakness of the project, and it is worth being direct about it. Bower is deprecated, so a new project on this template starts by adopting a package manager that no longer receives updates, and the manual path declaration means a forgotten gulpfile entry is a library that silently does not load. The gulp-concat task is what stitches the files together, and the order of the paths in that task is the order they are concatenated in.

The same pattern applies to the CSS side, but at least those files are centralised: the styles for the JavaScript libraries go in app/sass/_libs.sass, so there is one file to edit rather than a list spread across templates.

The template also says all HTML files should have similar initial content to app/index.html, which is a convention about the document head and its meta tags. The .htaccess with the caching rules is at the project level, which means the caching behaviour is assumed rather than configured, and a project served by nginx needs that translated rather than copied.

## Where OptimizedHTML is the wrong choice

The first wrong case is a project starting today. The template's toolchain is Gulp 5 with Bower and a Sass syntax from before the current conventions, and the front end libraries are installed with a tool that no longer gets updates. Starting a new project here means starting it on a deprecated dependency, and the migration to a bundler is work you would do immediately anyway.

The second is a team that wants modern CSS. The template uses Sass with Sass syntax rather than the module system with the .scss extension, and the media query and variable files are Sass partials with a leading underscore in the file name. That is a coherent choice and it is not the current one, so your own additions will be in a different dialect from anyone else's.

The third is a deployment that is not an Apache-like server with an .htaccess file. The caching rules are the Apache format, and the two deployment tasks are FTP and rsync, which suits a traditional shared host and does not suit a container platform or a static site service. The template optimises for the PageSpeed score of a page served from a normal web host with a .htaccess and an FTP account.

The fourth is a team that does not want a house style imposed. The rules for where every kind of file lives are strict, and they are good, and they are also not negotiable without fighting the template. A team with its own conventions will spend the first week moving things.

The alternative worth weighing is a modern bundler with a small starter of your own, which is a day of work and gives you a dependency manifest, tree-shaking, hashed asset filenames and a deployment step that is one command to your platform. The trade is that you lose the parts of this template that are genuinely good, which are the caching rules, the image compression settings and the fact that the source and the production folder are already separate.

## Conclusion

Adopt OptimizedHTML if you want a front-end starter that has already made the asset pipeline decisions for you and you are happy to follow its file layout, since the build, the deployment targets and the caching rules are all wired together. Keep away if you need a modern build tool, because this is a Gulp 5 project with a Bower dependency and a Sass syntax that predates the current conventions. Before you start, read the rules for working with the template, since the paths for libraries, fonts, variables and custom JavaScript are fixed, and note the licence is listed as ISC in the manifest while the repository listing does not identify one.

## FAQ

### What is OptimizedHTML and what is in the template?

It is a start HTML template built for Google PageSpeed with Bootstrap at grid only, Gulp, Sass, Browsersync, Autoprefixer, PostCSS, Uglify, gulp-imagemin, Vinyl-FTP and rsync for deployment, and Bower for the libraries path. It also includes a .htaccess file with caching rules for the web server.

### How do I set up and run the OptimizedHTML template?

Download optimizedhtml-start-template from GitHub, install WSL if you are on Windows, install the Node modules in the project folder with npm i, and run gulp. The default task runs sass, js, watch and browserSync for development, and the separate build task produces the optimized dist folder.

### How do I add a JavaScript library to OptimizedHTML?

Run bower i plugin-name, with Bower installed in the system using npm i -g bower. The libraries land in the app/libs folder, and you then add their paths to the js() task in the gulpfile.js, where the order of the paths is the order they are concatenated in.

### Where do I put my custom code in the OptimizedHTML template?

The rules are fixed by convention. Custom JavaScript goes in app/js/common.js, Sass variables in app/sass/_vars.sass, fonts in app/sass/_fonts.sass with the font-face mixin, Bootstrap media queries in app/sass/_media.sass, and the CSS for JavaScript libraries in app/sass/_libs.sass, and all HTML files should have initial content similar to app/index.html.

## Sources

- [Issues](https://github.com/wdmcourses/optimizedhtml-start-template/issues)
- [Project website](https://webdesign-master.ru/blog/tools/optimizedhtml.html)
- [README](https://github.com/wdmcourses/optimizedhtml-start-template/blob/master/README.md)
- [Releases](https://github.com/wdmcourses/optimizedhtml-start-template/releases)
- [wdmcourses/optimizedhtml-start-template on GitHub](https://github.com/wdmcourses/optimizedhtml-start-template)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wdmcourses-optimizedhtml-start-template