Forem: Roman Sedykh

You ask business people questions but you do it without respect

Roman Sedykh — Wed, 03 Jul 2019 09:25:57 +0000

Ok, the more accurate title would be "How to communicate with business people about their projects if you're a freelance developer", but I couldn't resist. :-)

When you start a freelance developer career, the first big project is a game changer. Big projects bring more money and, inevitably, more problems. How not to frack up by having a miscommunication?

It takes years to see things for what they are. Until then you'll have troubles with understanding clients' needs, underestimate tasks, and miss deadlines, trust, and money. It's part of the process, but you can accelerate learning by communicating your understanding of incoming projects better.

I compiled a checklist backed with my experience of evaluating more than a hundred web and mobile projects (from a week-long to five years in development).

Step 1, preparation.

Should you even consider taking the project? Will the client agree on your terms? For that, you should answer these questions:

Can I do it?
How much time do I need?
How much must I charge to be able to complete the project if something goes wrong (it always does)?

At this step, you probably can't spend much time gathering info, but you definitely can have a call with a potential client. What should you do?

Before a call, prepare: read all docs (if they exist), learn about a few similar projects.

Then, follow the algorithm:

Ask about the project's goal.
Ask about edge cases, question why the client sees thing this way, what are the reasons.
Ask any questions you have left from reading original docs.
Tell the client your vision of a project, carefully listen to their response.
Try to find underlying potential problems with tech/design/business.
Update your project vision, agree on it with the client. That will be the project you will evaluate.
Discuss which major parts of website/app/service you should thoroughly estimate first, leaving everything else behind for a while. (Always start with a key part of the project).

After you finished a call, immediately write everything down. Then, if you can wait till the next day — just wait, let things settle down. You'll have a more unobstructed view, and a client might send you some additional info.

Still, want to land this deal?

Step 2, evaluation.

Write a response with your estimates following this template:

Write the project description.
Write the project goals.
Write about why you like it.
Write about project features. Mention underlying potential problems.
Create a mind map with the project's structure that an average person can understand.
If you have enough time, work on basic user stories (see this cheatsheet).
Write how you think you will build it, what are the major milestones, what’s your release strategy.
Write about resources you will need to accomplish a task.
Write time/budget estimate, based on tasks and/or resources. Don’t oversimplify things, but don't go pessimistic either.

A density of this response depends on how much you like/need the project.

If it's possible, always present your response on a video call or in person.

A few iterations later, you landed yourself a big project that you and your client are confident in and which can become a big step for your professional skills and career.

If you ever have to lead a remote dev team...

Roman Sedykh — Mon, 17 Jun 2019 12:08:13 +0000

For those developers who suddenly have to lead a remote team and answer to stakeholders, I compiled a checklist that you and your teammates can follow to have a simple, transparent, predictable and frictionless workflow.

I spend my years managing remote development teams. Either you work on a client's project or a startup, any workflow stands on three pillars:

Communication
Task management
Time management

To master those, we need frameworks and tools as simple as possible to get the job done without distracting you from creating the product. While I describe some frameworks below, I suggest you stick with Slack and Trello for communications. Harvest (teams of 5+, paid) or Toggl (5–, free) is the best if you're required to provide timesheets or you want to make a point.

Communication

Use channels, avoid direct messages. This makes your chats transparent. With more than two folks on a project, you don't want to get in the "gosh, we forgot to tell this to everybody else" situation.
Start a thread to discuss a particular issue. Mention only those who need to participate. Two points here: threads make channels much cleaner; you don't distract anyone who's not directly involved in the discussion, yet preserving their access to information.
Wisely add integrations with other instruments like Github, Trello, and Sentry to have anchor points in discussions.
Slack resembles an open space working environment. And yes, you require quality time alone. It's ok to turn off the app, but make sure that everybody knows how to reach you via phone or your personal messenger (btw, never continue work conversations there, return to Slack). And, never leave Slack when there is an ASAP situation.

Task management

Team leader special: subscribe to the boards, so you don't miss important messages and the big picture of your project. By subscribing, you allow Trello to send you notifications via email. Don't check your email on every inbox message, look through notifications during your everyday zero inbox routine and make sure (buy manually archiving each email) that you don't miss anything important.
Here's my framework: make lists and describe tasks in cards. Make the priority cards top your lists. Then, take tasks from the top left and start moving them to the right. TODO → IN PROGRESS → TEST → RETURNED FROM TEST → IN PROGRESS → TEST → READY TO PRODUCTION → DONE
Decompose tasks into subtasks: create "Frontend," "Backend," "Markup," "Questions," "Etc" checklists. You might want to split large tasks into smaller ones. Completing each small task provides its separate value, like, you can deploy a subset of features to production.
Deadlines, if added as due dates, are real. If you're not sure that you can make it, then move a deadline, so everybody can see it and act accordingly. Don't forget that it can take a couple of extra days to test, fix bugs, and deploy a feature to production.
Learn a few hotkeys (hit shift + ? in Trello).
Use color labels to differentiate tasks. This helps you evaluate progress and balance the team load visually. You can invent your own system or use mine: Backend, Frontend, Bug, ASAP, Non-tech, Tech debt, Design, Tech special, Discuss, Temp mark.

Time management

(optional, depends on circumstances)

Install time tracker browser extensions and desktop apps. Assign a hotkey for popping up a desktop app.
Track everything related to work: coding, fixing, refactoring, discussing, thinking, reading, etc.
Track time from Trello cards (via the browser extension), so your records get attached to the tasks (useful for analyzing and reporting).
No card to track? Create a new card (for example: “Update dependencies”), so the task can be visible, testable and trackable. In some cases (like general talk about the project) just track the project's overall time.
Track honestly. Tea time, side chat? Pause. Forget to stop? Correct later. But never track time post factum.

That's how, after much back and forth, I manage remote teams. The goal here is not becoming a control nazi but ensuring the transparency of the processes and availability of information to achieve the comforting work-life balance.

Hope this post will help you avoid mistakes. Share it with your teammates if you like it. :-)

Image Optimization: Understanding the Exact Impact on Google’s Performance Score to Rank Higher

Roman Sedykh — Mon, 06 May 2019 14:05:14 +0000

Everybody talks about Web Performance these days. Site speed is a ranking factor and affects business metrics: bounced visitors and page views per session. However, it’s usually unclear how improving performance affects those metrics exactly.

Many articles on Web Performance mention “image optimization” as a primary step in accelerating websites. Now, what’s the exact impact? This post elaborates on how exactly image optimization affects Google’s Performance Score.

Performance Score is determined by Lighthouse simulating a page load and analyzing the derived lab data. 100 is the best possible score which represents the 98th percentile, a top-performing site. A score of 50 represents the 75th percentile.

A score of 90–100 is considered fast, and 50 to 90 is considered average. Below 50 is considered to be slow.

We took the world’s top 500 websites (like USA Today, IKEA, and Behance) and ran performance analyses with Lighthouse (performance analyzer made by Google) and PageDetox (a diagnostic framework made by us).

We want to share the numbers so you could better understand where you stand.

Is the hype about optimizing web performance worth it?

Why should you care? The answer is simple — competition.

You can optimize your website in many ways. Take search engine optimization; when optimized with the right keywords, content lengths, and backed with authoritative domains, your website gets ranked higher in search results.

However, while the average Lighthouse SEO score is 93 for the analyzed pack, the performance score is only 48.

What does this mean for you? You can choose where you compete for optimization. Simply put, getting above average in SEO means achieving 93+ points while there’s roughly twice as much opportunity in optimizing for performance. Also, it takes time to prove your SEO strategies while you can quickly achieve the target performance metrics.

If your niche is competitive, and a search engine is ranking two websites with similar content and SEO score, it will prioritize the one with a higher Performance Score.

That’s also logical from the user experience perspective. The faster your site is, the smoother the user experience; thus, your analytics platform registers fewer bounces, more page views, and higher conversions.

In our research, we focused on the total image weight of analyzed pages. On average, images take up to 53% of your entire page weight (according to Pingdom). This means they have a big impact on page-loading times and subsequently overall performance.

A bit of theory

This section unveils how exactly image performance affects Performance Score. It’s a bit technical, so if you want the actual figures for the top 500
websites upfront, skip down to the next section.

Lighthouse uses the following metrics to calculate Performance Score based on their weights:

First Contentful Paint (FCP, users perceive a page as responding), weight 3
First Meaningful Paint (FMP, page’s primary content appears on the screen), weight 1
Speed Index (SI, visible page content gets displayed), weight 4
First CPU Idle (page becomes minimally interactive), weight 2
Time to Interactive (TTI, page becomes fully interactive), weight 5

While none of the above reads as “image content weight and loading time,” you can find performance improvement opportunities specific to images in a Lighthouse report. They are:

Defer offscreen images, implement lazy-loading.
Properly size images, implement Responsive Images.
Efficiently encode images, balance out quality levels.
Serve images in next-gen formats, use webp where possible.
Use video formats for animated content, convert GIFs to video formats.

Note, these can be seen in your complete Lighthouse report JSON under the “load-opportunities” key, with zero weights. This means these image issues do not directly affect your performance score calculations. However, they do leverage all five components of the Performance Score.

So, the idea is that by optimizing images and their delivery, we can improve all five Performance Score components. Now, let’s proceed to our findings.

Here’s what we found out

After analyzing the main pages for over 500 of the leading websites out there, we ended up with the following averages:

Image count: 43 on desktop and 23 on mobile.
Page weight: 3.64 MB for desktop and 2.69 MB for mobile.
Image content weight: 1.40 / 0.74 MB, which results in 33 / 32 KB per image.
Page load time: 7.6 seconds on broadband (10Mb/s) and 13.92 seconds on slow 4G (1.5 Mb/s).
Lighthouse Performance Score (normalized on a scale from zero to one): 64 on desktop and 48 on mobile.

It’s interesting to note that among the most performant sites on our list were the obvious candidates like google.cn and wikipedia.org along with less obvious ones like wordreference.com and ikea.com. On the “sluggish” end were usatoday.com, kaskus.co.id, and deviantart.com.

Here is the raw data we collected and used to analyze the performance of the world’s top500 sites. We highlighted the rows of the websites we couldn’t collect data for: one of the two analyzers failed, etc.

So, where’s the room for improvement?

Let’s take a look at the insights derived from Lighthouse reports for desktop / mobile websites:

59 % / 62 % require image format improvements.
57 % / 36 % have problems with responsive images.
34 % / 32 % have image weight issues.

What can be achieved

If we fix all the three types of issues, on average, we’ll:

Reduce image content weight by 62 % on desktop and by 66 % on mobile.
Reduce page loading time by 8 % / 20 % respectively.
Decrease the amount of bounced visitors by 19 % / 9 %.
Increase the number of website pages viewed by a user during a single session by 13 % / 14 %.

What about the actual Performance Score?

We can predict the impact.

Since Google provides its performance score calculator, the only thing left is understanding what the new FCP, FMP, SI, CPU, and TTI will be.

Thanks to Lighthouse, we know the parameter values for the analyzed set of sites. All five components of the performance score are expressed in seconds.

Current state:

First Contentful Paint — 1.68 / 4.05
First Meaningful Paint — 1.78 / 4.38
Speed Index — 2.90 / 7.54
First CPU Idle — 2.62 / 7.67
Time to Interactive — 2.92 / 10.10

We also know:

The number of bytes saved by optimizing images
The initial load time for every desktop and mobile main page version
The number of seconds we can shed from the load time
The percentage of load time improvement

We assumed that if we proportionally decrease these metrics, we might come up with a reliable approximation.

Forecasted results:

First Contentful Paint — 1.51 / 3.52
First Meaningful Paint — 1.60 / 3.82
Speed Index — 2.64 / 6.68
First CPU Idle — 2.39 / 6.93
Time to Interactive — 2.67 / 9.11

Given that, the average optimized Performance Score for the world’s top 500 websites will improve by 4 points for desktop and 7 for mobile, and up to 25 / 33 for the worst performing 10%.

We can’t tell how exactly the improved Performance Score will affect SERP positions for the analyzed websites (nobody can, Google included). The fact is that maximizing the score provides increased chances to get higher rankings.

When accelerating the site, we also improve the user experience along the way. We can then expect that decreasing the number of bounced visitors and increasing page views directly affects conversion rates for the top of the analyzed sites’ funnels.

Image optimization is one of the easiest and quickest proven ways to get there. And, where even the world’s top 500 websites have room for improvement, get in the lead.

This is the low-hanging fruit. It may seems complicated, but you can quickly implement the optimizations with the right tools.

Analyze your website with PageDetox to get started.

Then get rid of every issue and improve scores by using webp images, compressed images, and responsive images:

Optimizing images on autopilot with Uploadcare (to improve page load speed)

Roman Sedykh ・ Feb 15 '19

#imageoptimization #pagespeed #beginners #webperf

Optimizing images on autopilot with Uploadcare (to improve page load speed)

Roman Sedykh — Fri, 15 Feb 2019 14:01:18 +0000

Summary: a step-by-step guide on optimizing images with CDN’s URL directives to get rid of Google PageSpeed image related issues.

When you analyze a website with Google PageSpeed Insights, it often
points out several image issues to fix:

Next-generation formats
Image size
Responsiveness
Lazy loading

We analyzed 10k of our users’ websites and found out that:

Only a tiny percentage of users implements next-generation image formats, which alone can lead to a file size drop of 25–34% (source: Google).
Almost every compressed image can be further downsized without any significant loss in visual quality.
The problem is often about a few huge images; fixing those dramatically improves loading time.
Often there is no lazy loading (when images are only loaded when they’ll be scrolled to soon).
Many analyzed websites provide either no or poor Responsive Images experience.

Eliminating the issues will increase page loading speed, decrease bounce rate, and improve the user experience.

Resolving those is frustrating if you don’t know exactly what to do. Here is an ultimate guide on optimizing images in three steps:

Optimize Size & Format — get rid of excess image weight at no significant loss in visual quality.
Use Responsive Images — serve appropriate images to every device and screen.
Add Lazy Loading — load only those images users are looking at.

Short version of the guide

Use srcset instead of src.
Create versions of images with CDN's URL directives.

Aaand add lazy loading. Profit, you've won Google PageSpeed images score. :-)

Full version

You’ll need a tool allowing you to manipulate images in real time, Image CDNs do this job well. In our examples, we’ll use Uploadcare Image Transformations.

This step is technology agnostic: you can use other tools to manipulate images.

Once you upload files (for test purposes you can do it manually, no need to code), they get cached by a CDN, which alone improves image load speed. The files will now have their permalinks starting with https://ucarecdn.com/ followed by their UUIDs.

From there, you manipulate images by changing their URLs: include Image Transformations as URL directives:

https://ucarecdn.com/{FILE-UUID}/-/{DIRECTIVES}/

Let’s move on to optimizing images.

Step 1. Size & Format

1.1. Next-gen formats — saves ≈25-34%

-/format/:format/
:format: jepg, png, webp, auto
docs / image format

WebP is a new image format for the web with superior compression, developed by Google. Use the auto value to deliver WebP images to user browsers that support the format. Since WebP is not everywhere, it is a good practice to specify the jpeg or png format as a fallback.

1.2. Quality — saves up to ≈50%

-/quality/:value/
:value: lightest, lighter, normal, better, best
docs / image quality

With Uploadcare, you use quality presets. Use lightest (≈50% file size) for retina resolutions, when you don’t have to worry about the quality of individual pixels and lighter (≈80% file size) for every other occasion.

1.3. ICC profile size threshold (image meta) — can save up to ≈1 MB for some images

-/max_icc_size/:number/
:number: the maximum allowed ICC profile size in kilobytes
docs / ICC profile size

ICC profiles define how image colors should be displayed on your screen. The profiles can add up weight to your images, so you can reduce their size by getting rid of excessive ICC profiles. We recommend setting the limit to 10 KB (10240 bytes). Most of the common profiles (sRGB, Display P3, ProPhoto, Adobe RGB, Apple RGB) sit under the threshold.

Let’s check out the combined impact of those optimizations

A. Original, 539 kb:

https://ucarecdn.com/c4bd2b28-e3de-4731-a2e3-2bdbf044be47/

B. lighter version, 291 kb, no significant visual difference — saved
46 %:

https://ucarecdn.com/c4bd2b28-e3de-4731-a2e3-2bdbf044be47/-/format/auto/-/quality/lighter/-/progressive/yes/-/max_icc_size/10/

C. lightest version, 149 kb, visible difference in quality — saved
72 %:

https://ucarecdn.com/c4bd2b28-e3de-4731-a2e3-2bdbf044be47/-/format/auto/-/quality/lightest/-/progressive/yes/-/max_icc_size/10/

Step 2. Resizing, Cropping & Responsive Images

2.1. Resize, a key to Responsive Images

-/preview/:two_dimensions/
:two_dimensions: e.g. 300x300, 300x, x300
docs / resize image proportionally

Reduces an image proportionally to fit into the given dimensions in pixels while preserving the original aspect ratio. Resizing images is a go-to for saving bandwidth.

2.2. Scale crop

-/scale_crop/:two_dimensions/
-/scale_crop/:two_dimensions/center/
docs / scale crop

The next important aspect of Responsive Images is cropping originals to provide a better mobile screen fit. It is a good fit for mobile experiences. It scales down an image until one of its dimensions gets equal to some of the specified ones; the rest is cropped. This proves useful when you want to fit as much of your image as possible into a box, “center” it.

2.3. Crop

-/crop/:two_dimensions/:two_coords/
-/crop/:two_dimensions/center/
docs / crop

Crops an image using specified dimensions and offsets. Great for art direction.

Let’s make a responsive image

In the template below, we tell a user’s browser about what images and sizes are available to display on a user device.

We also added breakpoints (min/max-width) to switch between appropriate sizes. The browser then does all the work figuring out which image suits the device best.

To become a pro in responsiveness, check out MDN web docs and our course Introduction to Responsive Images and learn more about why it matters: performance, art direction, WebP, and breakpoints.

Lazy loading

Lazy loading is not an image property. It has to deal with adding some JavaScript code; you can find implementations of lazy loading for different JavaScript frameworks on GitHub:

Still, there are a few tricks to improve the lazy loading experience on your page:

Use progressive jpegs.
Load very light blurred instance of an image before the original.
Or extract the major color and show it until a picture gets loaded.
Use this color with setfill and stretch transformations.
Play with face recognition and object recognition.

Conclusion

At the end of the day, here’s what you need to do to win at Google PageSpeed image score:

Run a PageDetox report to see how images affect your website load times.
Pick an image CDN that manipulates images on the fly, like Uploadcare.
Get your image assets there.
In your <img> elements, replace src with srcset holding image versions generated by your image CDN.
Implement lazy loading.

We believe that the only thing you should be doing is uploading a single hi-res image. The image handling service then handles the rest: picks breakpoints, optimizes images for the best results, and sticks proper snippets into your code. We're working on it!

FAQ

What if I don’t want to upload files to Uploadcare / another CDN?

It’s common that your images are already sitting somewhere, and you don’t want to re-upload them to an image CDN.

In this case, check out Image Proxy options like Upload-Free Image Processing. It fetches your content, optimizes and delivers it to your users via Image CDN.

What about Client Hints?

They don’t work for everybody right now, even in Google Chrome. Changes in the desktop version of Chrome 67 have removed support for cross-origin client hints.

Building an image optimization tool to win the PageSpeed game on autopilot

Roman Sedykh — Mon, 28 Jan 2019 17:43:10 +0000

Hi dev.to!

We’re building an image optimization tool called PageDetox. Its purpose is helping to win the Google PageSpeed game.

I want to ask you for URLs to analyze and provide you with optimization instructions to raise your image score up to a 💯.

How does the tool work?

You analyze a page on autopilot, request a report
We provide the report together with a personalized workflow for optimizing images

The analyzer is there and ready, while the step-by-step optimization part is work in progress.

Here’s the instruction design we want to start with:

Upload files to an Image CDN (since we're with Uploadcare, we stick with using that service; if you're a fan of other solutions, pick your favorite. Uploadcare provides a CDN URL that allows applying Image Transformations on the fly, we make use of it)
Get those CDN URLs
Replace the src attribute in <img> with srcset
Make each version of a source image with on-the-fly transformations taking analyses results into consideration

Check an example below ⬇️

So, shoot me your page URL in the comments. I’ll be supervising each set of instructions and ask what was unclear/going wrong, a custdev kind of thing.

If you’ll have any feedback regarding the app’s flow, I’d appreciate you sharing it.

Thanks!