A $100 investment doesn't seem much and it's more like a kudos, but it is an investment. I agree that more information can help anyone determine better how to choose between startup A or B.
That's a good point, and it reminds me of the saying - don't invest more than you're willing to lose. I'm definitely open to making $100 investments, but I guess my question was more directed towards higher risk/volume investments that might beg for a more structured DD process.
I've been using PushBullet for years. Great product! It's not fair what big companies are doing to what it seems to be, prioritizing their own features over third party well-built products. It's abusive.
Completely agree! Being remote in a non-remote company is one of the hardest things as those companies don't have procedures in place for keeping everyone in the loop.
On the guide, we wrote we have by default ALLOW ANY, DENY SOME. If you are online then you can be interrupted unless you set your status to the headphone emoji.
Otherwise posting office hours may force the idea of how many office hours each person is doing and that's not something we want to measure.
It depends on which things you need to measure based on the type of company you have or you want. A D2C company clearly needs a fixed amount of office hours where a SaaS company may not.
Remote companies come with a redefinition of what a social workplace is and how you get to know someone. In my past years, I've mostly worked remote and still I think I know the people I've worked with very well.
Communicating regularly every day and doing things like online gaming or company retreats can help to redefine social interactions.
The support system is really important, if you are remote it should mean that you prefer to be close to your support system. If you are not, then something is wrong and that's going to be a challenge.
I personally have been working around web technologies and performance for the last 14 years. I understand where this article is coming from and I actually have to give it some credit, it has a good click-bait title but it's an old solution. I'm tired of reading about this type of solutions, there are thousands of articles exactly like this one.
Reducing the size of your images is just the first step and there are many things you need to consider in order to make your website faster, things you need to solve:
- Format: deliver the images in the right format for each browser (e.g. using WebP for Chrome)
- Size: What size for each image? What happens on mobile, tablet, desktop and the different screen sizes and pixel ratios (it's not only retina or not)
- Quality: Is your image being resized by the browser? Are you using raw files to generate the optimized images?
- Thumbnails: Are you also generating thumbnails for listings or smaller versions of your images? How are you going those thumbs to your original images? Do you need to use a Database?
- Storage: Where are you going to store those images?
- Headers: Caching static assets it's key for recurrent users, are you using Apache or Nginx? Is your setup working well?
- CDN: are you using a CDN to deliver those assets? CloudFlare is great but it's not the fastest way to deliver images. What about setting the right configuration for that CDN? How much are you going to spend?
So what's next? Going to one of the API service to optimize images, read their 500 pages of docs to get to resize and crop an image? Ad complex plugins to your backend and have a high dependence integration?
I mean, if you like to add more dependencies to your project, maintain more code, spends hours rebuilding scripts and running cron jobs to update your images, go for it.
That's why about 9 months ago we started working on a new concept, solving all these problems with a service that integrates as easy as a lazy-loading plugin and it solves EVERYTHING about image optimization (and yes, everything that you're talking about on every comment on this HN post).
Don't get me wrong, we have a lot to improve and there are many details of our product that we need to polish, but we believe we've built a solution that solves perfectly all the most important parts of image optimization and delivery. It's not about reducing the image size by 1KB more, it's about everything else and understanding the big picture.
We love feedback and our backlog is prioritized based on our customer needs, let us know what you think.
Author here. Thanks for the feedback. I agree that what I've done is nothing revolutionary, but the vast majority of websites out there don't have these sort of thing.
That's one of the reasons why the average page weight continues to grow every year [0].
Moreover, this solution is good enough for people with small blogs just like mine. Anyone who needs something more involved can use your service or other alternatives.
As for responsive images, I implemented that on my site too although I didn't mention it in the article. I plan to write a follow up article on that topic soon.
On a side note, you might want to bump up the font size of the navigation links on your site. They're too faint.
Totally agree with the page weight and that we're missing something.
Increasing page weight when we're also increasing connection speeds is only bad when the first one increases more rapidly, and I believe that we're under that situation.
Would love to connect to chat about this and for sure I'll read the follow-up article.
Some things you didn't mention are domain resolution latency and caching, browser request parallelization, delivery protocol selection and reducing the raw number of content requests. Basically you are entering CDN territory here.
That's why I added the CDN part, didn't wanted to go to deep on that issue. As you're saying CDN it's a big part of the image delivery, even more important than having a great algorithm to compress those images. We've found that after passing a certain threshold, eg. the image being < 200KB the download time it's not something important, so the size doesn't matter that much, the TTFB (time to first byte) is crucial.
There's also a difference between performance, speed and actual perception of speed, but that is very hard to measure and maybe it's an issue for another topic.
You need to ask yourself two questions:
1 - When do I need this up and running?
2 - How long do I want this stack to survive?
Question 1
Based on your skills and how fast you can learn something new, how fast you need something is crucial to select the appropriate tools to complete the tasks and you'll need that running on production (you can forget about Kubernetes now).
Based on that, you'll need to benchmark the tools you already know or the ones you want to learn based on the attributes your project will need more. Try to build a small prototype of one of the core features of your product and decide then, if you think the stack you selected is not playing along, change it and iterate on it.
Question 2
Everybody thinks they are building something to last, but that's the most stupid thing to do. Once you write the first line of code, you already set up an expiration date for that piece of software. Tools and software changes all the time and the tools you've today, they might not have support tomorrow or some technologies may come up that will solve the problem for you and you can discard a big part of your stack.
3 years is a good time for any stack to run, evolve and die. It's a good timespan to understand what you need more, build new prototypes with new technology and try new tools. So when it comes the time you've to re-build your stack, you already have something in mind.
Remember when people used two floppy disks to save files so if one floppy break you have a backup one?
I remember the first day I heard about Dropbox and I was amazed by it, it made perfect sense. Since then I'm a client and as an entrepreneur, it's a company I always looked up to.
I remember the first day I used Rsync (developed by famous reverse engineer Andrew Tridgell of Samba fame [1]) and the first day I used WebDAV and later on WebDAVFS. Nowadays, I use TransIP STACK (1 TB free) and Google Drive (15 GB) plus public key cryptography.
Dropbox might've been the first in the field, but it has no selling point above STACK for me since it doesn't implement public key cryptography just like the other providers. Google's sell point is that compressed photos are free storage (although -obviously- unencrypted).
Which suggests, to me, that they're accessing the data or perhaps saving a few GBs with say ZFS dedup (ultimately not a trade-off in the interest of the user). Because otherwise, the lag would be client-side only (after all, the clients employ the cryptography).
Most of this makes perfect sense, but allow me to disagree with one point "Those kinds of decisions are much more important than what stack you build" the most technical founder should never lose focus of the importance of this.
Of course, if you don't have a business it doesn't matter what stack you're using, to build a quick RAT (yes RAT, not MVP) you don't need to go deep on the stack, but once those experiments are moving forward you've to be careful. You've to pick the right stack and tools to build your company, focus on that even more if you are a technology company (not a consumer one). This won't only be part of the scaling plan of your company but it'll also play a big role on recruiting if you're using new technologies you've to train people if you're using more mature technologies you probably have a better hiring pool in one than another.
Plus, you need to be able to share with your team the importance of picking one stack over another, the cycle of development and the times to invest in refactor or why to re-build something that started as an experiment but now needs to scale.
