loading...
Cover image for My website now loads in less than 1 sec! Here's how I did it! ⚡

My website now loads in less than 1 sec! Here's how I did it! ⚡

cmcodes profile image C M Pandey Updated on ・4 min read

Hi there!

The reason why you're here is probably because you wanna know what I did to load my portfolio website in just 0.8 seconds and achieved a performance score of 97 on lighthouse.

Link to my portfolio and its source code is at the bottom.

I will lay out all my tips and tricks over here, which I implemented to achieve this! Let's get this thing started! 🤘

NOTE: According to Lighthouse, "Values are estimated and may vary. The performance score is based only on these metrics." This report was generated on 2nd of August, 06:29:22 PM IST. These scores might reflect a bit different on your machine due to internet connection speed or multiple extensions running in the background or I might add some features later. Also, I have "clearly" mentioned above that these scores were generated by Google Lighthouse. Don't expect the same score on any other tool. So, please don't try to troll on this basis and save your energy. Peace! ✌

Tip #1

Don't use a large DOM tree.

My portfolio contains 487 DOM elements with a maximum DOM depth of 13 and a maximum of 20 child elements only!

If your DOM tree is very large, then it will slow down the performance of your webpage:

  • Memory performance

Using general query selectors such as document.querySelectorAll('li'), stores references to a multiple nodes which can consume the memory capabilities of the device.

  • Network efficiency and load performance

A big DOM tree has many nodes (not visible in first load), which slows down load time and increases data costs for your users.

  • Runtime performance

Whenever a user/ script interacts with your webpage, the browser needs to recompute the position and styling of nodes. having complicated style rules can slow down the rendering.

Tip #2

Don't use enormous network payloads.

My portfolio has a total network payloads size of just 764 KB.

The total payload size of your website should be below 1600 KB.
To keep it low, you can do the following:

  • Defer requests until they're needed.

  • Minify and compress network payloads.

  • Set the compression level of JPEG images to 85.

Always remember, large network payloads cost large amounts of money.

Tip #3

Don't use GIFs.

Rather use PNG/ WebP format for dispalying static images. But if you want to display animated content then instead of using large GIFs (inefficient & pixelated) consider using MPEG4/ WebM video format.

Now, you will say what if I want their features like:

  • Automatic play.
  • Continuous loop.
  • No audio.

Well let me rescue you from this, the HTML5 <video> element allows recreating these behaviors.

<video autoplay loop muted playsinline>
  <source src="my-animation.webm" type="video/webm">
  <source src="my-animation.mp4" type="video/mp4">
</video>

Tip #4

Preload key requests

Suppose your page is loading a JS file which fetched another JS and a CSS file, the page won't appear completely until both of those resources are downloaded, parsed, and executed.

If the browser would be able to start the requests earlier, then there would be much time saving. Luckily, you can do so by declaring preload links.

<link rel="preload" href="style.css" as="style">

Tip #5

Don't try multiple page redirects.

Redirecting slows down the load speed of your webpage. When a browser requests a resource that has been redirected, the server returns an HTTP response. The browser must then make another HTTP request at the new location to retrieve that resource. This additional trip across the network can delay the loading of the resource by hundreds of milliseconds.

If you want to divert your mobile users to the mobile version of your webpage, consider redesigning your website to make it responsive.

Tip #6

Preconnect to required origins.

Using the keyword preconnect gives a signal to the bowser to establish early connections to important third-party origins.

<link rel="preconnect" href="https://www.google.com">

Doing so establishes a connection to the origin, and that informs the bowser that you want the process to start ASAP.

Tip #7

Encode your images efficiently.

A compression level of 85 is considered good enough for JPEG images. You can optimize your images in many ways:

  • Compressing images.
  • Using image CDNs.
  • Avoiding GIFs.
  • Serving responsive images.
  • Lazy loading images.

Tip #8

Minify your JavaScript files.

Minification is the process of removing whitespace and any code that is not necessary to create a smaller but perfectly valid code file.

By minifying your JavaScript files, you can reduce the payload size and parsing time for the script.

I use JavaScript Minifier for the same.

Tip #9

Minify your CSS files.

CSS files occupy more whitespace than any other file. By minifying them, we can save some bytes for sure!
Do you know that you can even change a color value to its shorthand equivalent, like #000000 can be reduced to #000, and will work just fine!

I use CSS Minifier for the same.

Tip #10

Resize your images.

I can bet this is the most given advice when it comes to webperf because the size of images is far far far greater than any text script file, so an over-sized image might be an overkill.

You should never upload images that are larger than what's rendered on the screen, that will do no good.

You can either just simply resize your image dimensions or use:

  • Responsive images.
  • Image CDNs.
  • SVG instead of icons.

Thank you for reading so far! 😄
Hope you learned something new from this! 😃

Here's the link to my portfolio website 👉 cmcodes

Here's the link to my portfolio source code 👇

GitHub logo cmcodes1 / cmcodes1.github.io

😄 Here's my portfolio!

Check it out and do let me know your views! Eager to hear your opinion. 😁

Feel free to share your portfolio link in the comments below. I would be very happy to have a look at them. 😊

Happy Coding! 👨‍💻

Posted on by:

cmcodes profile

C M Pandey

@cmcodes

Wrote a piece of code around 7 years ago, it was fun; so that's what I have been doing till date :)

Discussion

pic
Editor guide
 

Here, your website is low rated in test it scored 68 and that is not a good score site speed isn't a measure untill you have a good score, I used font awesome, but my website loads in 2.5 seconds and scored 80, this is not a good score for my website and I am constantly improving the website and recommend you too...

 

Hey, @hemant , @cmcodes , check this article:
dev.to/joelbonetr/building-an-effi...

It gets 98-100 depending on the run (you may know its not consistent and the score varies from some points between different benchmark runs) even I added analytics on it.

Hope it helps you :)

 

Yeah! I will work on that for sure!

 

How did you test your website speed?

And is your thumbnail relevent to your own website?

I tested it through Lighthouse in Chrom DevTools. And yeah! This thumbnail is from that report only. You can run this test yourself too! 😊

 

Yes, don't use FontAwesome.

 

If you're going to use FontAwesome, the responsible way to do it is to use IcoMoon to create a font subset of just the icons you need, and then save that as a custom font and use that. It'll bring your gzip size from 70KB down to maybe 10KB (obvs depending on how many icons you use).

 

IcoMoon is really good alternative.

 

Why not? Over 1000,000,000 websites use it. 🤔

 

I only need 3 social icons. So, I rather choose svg than bloated FontAwesome.

lighthouse-dot-webdotdevsite.appsp...

Your website is really cool! 🤘

 

I'd probably add "use caching where possible" into the mix.

With the majority of sites using a CMS database of some kind, skipping that whole database read can save a lot of time (relatively) if the content won't change regularly

 

Pagespeed and lighthouse ignore cache so you will never get a better score adding cache. I've tried it many times using cloud flare and another services of that kind.
If you have static content there's no point on caching it out of your server, it will be slower than using server cache (no redirects, no third party implications), so you can simply use server cache module like memcached, opcache, pagecache or another, you'll need to check it depending on having apache or nginx.

 

That's what I was meaning by avoiding the database for CMS reads. I should have been clearer.

yes, you mean on a dynamic site (which sometimes a server language will need to read from a DB to process the output content), of course it's useful to cache this sites even on a third party cache-proxy :)

 

Lighthouse inspects cache-control headers, and if you don't have them set (or set properly) you will be penalized.

You will always have caching (servers usually perform cache automatically by default) but the error you get on pagespeed about "Serve static assets with an efficient cache policy" is about resource cache headers (images, scripts, style sheets...) that implies cache lifetime. This means adding Cache-Control: max-age=31536000 (which is a 1 year lifetime cache).

BTW cache must speed up the downloaded resources, so logically (and practically) you must get more pagespeed score using a cache of 1 day than not using cache for example, but pagespeed request uses no-cache server request and avoids user/local cache, so the score will be the same using cache or not, that's what I wanted to mean .

The difference on pagespeed score about using 1 year cache lifetime on all assets and not using cache will be only about the weight of the error mentioned above. You can try solving all errors and performing all recommendations except this one and check how much it weights.

Another point to keep in mind is that if you are managing a web app which is constantly evolving and you set a 1 year lifetime cache, you'll probably need to purge the cache every time you deploy a version into production (recommended custom purge only for the assets you updated).

 

Thanks for sharing this! 😊

 

How do I convert GIF to webm?

Also, about webm and webp, I am worried about caniuse in Edge / IE...

 

Edge supports webp, and the next version of Safari too. However you can use Cloudinary to do the format selection automatically - It's free forever up to 25GB of traffic/month.

See akshayranganath.github.io/How-to-m... for easy instructions.

 

You should use cloudinary to host your images and you can serve them in a format that's optimized by browser, e.g. in chrome you'll get a webp, in ie you'd get a jpg.

 

You can make use of CSS @supports feature to check if the browser support WEBP images. If not than it'd load PNG, JPG instead.

 

There are many online converters like ezgif and convertio.

 

Great work on the design and optimisation!

Really love the clean style, with just enough colour thrown in

 

Thanks! 😊

 

Not only does it load fast, it is also beautiful <3

 

Thanks! Damien 😊

 

Congrats, it is blazing fast ⚡⚡

Here is my blog, not fast as yours though 🙂

 

Thanks! 😊 Just checked out yours too! UI is amazing and so many articles!!!

 

Nice article.

the thing you said it is related to client side only.

 

Thanks! 😊

 

Good looking portfolio :)

 

Thanks! 😊

 

Great portfolio. Amazing design. Keep it up.
Looking forward to more projects and tips to learn and also so that I can clone them.😆

 

Thanks! 😊 And yeah sure! I will keep them coming for you! I got your back! 😄🤘

 

Good stuff and a nice portfolio. Keep it up. 👍

 

Thanks a lot! 😊

 

You're using a previous version of lighthouse.. try the latest lighthouse web.dev/measure/

lighthouse-dot-webdotdevsite.appsp...

 

I just ran one too out of curiosity. Definitely always a good tool to check for almost anything. Has always helped me get to about the 1s load time which is really nice. I also normally do SSR so it's just that much faster on initial load especially when accessing external data.

 

Yes, I mostly work on performance part of the application. This tool has helped me with everything, even their documentation is great

 

Thanks for sharing this! 😊

 

Brother html site usually perform better. And hosted from github and netlify usually are faster.

 

Yeah! I know that! That's why I used them. 😄

 

But html aren't adsense friendly.

Why would someone try to place ads on their portfolio? 🤔

Perhaps someone who needs to buy a domain for his/her portfolio 😂

Damn! 😂😂😂

 

That's a fairly decent looking portfolio page -- except for the carousel in your Achievements section. Carousel's are user-hostile and frustrating to interact with. You're also using a library for it that the developer has abandoned and doesn't recommend anyone use.

 

Thanks for sharing this! 😊 Tiny Slider seems better. Will try that out in the future!

 

Tiny Slider may be better (it's maintained, at least) but carousels are horrible for people trying to look at your portfolio. Just don't use one at all.

Thanks for your insights!

 

I absolutely cannot agree with point 10.

Images with exact dimensions (as rendered) look ugly when it comes to laptops and many mobile devices. Even Windows by default make laptop screen 15.6 inches / 1920x1080 all higher and (Recommended by Microsoft Windows) to 125%. So all the images on the web will be 25% zoomed and if the size is exactly as in page then it loses in quality while displaying. So you get less size but loose on quality of how your content looks.

From my experience, the images should be at least +25% larger (with dimensions set in "img" tag) while better to +50% so it looks good on mobile zooming. Better to compress images to 60% instead so the image still looks great and your UI is good on laptops and small screens.

If you never heard about this just go to your Windows (if you use it :) Display settings -> Scale and layout and set it to 125% then look on your exact size images.

 

I was using small sized images so it didn't had much impact.

 

Yes, while using a normal monitor or without zooming everything looks well.
Even Pingdom Speed Test recommends using scaled images but I won't do it.
I would rather loose some milliseconds of loading speed than see that image quality.
Now and in the near future the speeds will increase so serve that image a little bigger and laptop users with small screen sizes will be grateful to you. :)

Thanks for sharing this! 😊

 

I have another suggestion to add: Instead of making two REST requests with might have a race condition, like a POST followed by a GET, and avoiding it using setTimeout, you can use GraphQL mutations for atomic manipulation of server-side data.

graphql.org/learn/queries/#mutations

 

Can you please check us for a minute and list some points that I can work with to boost my score. Working hard on it. Score was quite good before I put adsence codes on the site.

Just give some of your valuable time and help me here. It would be really helpful.
Link to site: tutorialsmate.com

Thank you...

 

Let's take this to DM. 😊

 

Statistics from Google indicate that 50% of website visitors expect a mobile website to load within 2 seconds. 53% of users will probably leave the blog page if it takes longer than 3 seconds to load. So for Google, page speed is one of the factors, that define the user experience. And for Google, the user is a boss. Here for optimization of your page, you can also get the tools from the following link url-decode.com/cat/ as well. Where you will find tools related to minification, image optimization, and many more.

 

Yeah! Speed does matter when it comes to websites! Thanks for sharing this link. It's a treasure of tools. 😄

 
 

What you host your site on matters incredibly - shared hosting will perform really poorly compared to dedicated hosting with hardware caching etc. We've helped clients go from sites that load 15+ sec to under 3 sec just by moving them to a better server and properly configuring LiteSpeed caching. WebP is also a good thing to implement, and it's now supported by Safari in their upcoming release. And reducing calls to 3rd party hosted libraries (ie Jquery) helps a lot.

 

Thanks for sharing this! 😊

 

Tip #0: Use webpagetest.org to get real measurements: webpagetest.org/result/200709_JA_4...

"Loads in 2 seconds" isn't quite accurate since it looks like your best run was doc complete at about 4 seconds, while your repeat views are <1 sec (which is great).

Your lighthouse perf score was 73. Still a lot of work to do, but you're well on your way.

Make sure to take a look at the caching recommendations, those are going to be the lowest hanging fruit, although you might not have the ability to change this if using Github Hosting. I'd recommend something like Firebase Hosting which is free for your usage and allows for complete control over the static asset caching.

 

Yeah! I should move to a dedicated hosting! Thanks for sharing this! 😊

 

Great post! You mention image CDNs but you don't use them. Here's a way to use an image CDN easily with your github pages site: akshayranganath.github.io/How-to-m... , your images will be typically 40% lighter and served faster if you use it.

Cheers,

 

Cool! I'd like to translate this post to Chinese. Can you give me the permission? The translated text will be published at nextfe.com

 

Sure! You can repost this to Chinese at nextfe.com, if you mention the link to this post.

 

Chinese translation is finished: nextfe.com/site-loads-in-less-than...

There is a backlink to this post at the beginning of the translated text.

 
 

Looks great!

 

Your site:

Website TS

 

I think you didn't read the note at the beginning. I have mentioned the score from Google Lighthouse not from web.dev tool.

 

I think, that's same

No! They're not!

 

Well it's showing 88 scores point of performance
![dev-to-uploads.s3.amazonaws.com/i/...)

 

According to Lighthouse, "Values are estimated and may vary. The performance score is based only on these metrics." This report was generated on 4th of July, 01:28:48 PM IST. These scores might reflect a bit different on your machine due to slow internet connection or multiple extensions running in the background

 

Minifying the JS files won't actually reduce parsing time unless tree shaking is part of the minification process (and this is usually considered a separate part of the build process).

 

Thanks for sharing this! 😊

 
 

Have a look of light house score of my page (my portfolio) built with Gatsby.js
harshadprajapati.vercel.app/

dev-to-uploads.s3.amazonaws.com/i/...

 

Woah! Your scores are pretty good! Just add some styling to your skills elements.

 

Thank for your suggestion.

 

Love this post, really great tips!

 

Wait! What? Ben Halpern himself! 😍 Thank you so much for your feedback! You made my day! ♥️ I do admire your work that you put into making this awesome platform. 🔥