খালি ছবি। কী ব্যবহার করবেন: বেস64 বনাম 1x1 জেপিইজি চিত্র


11

আমি একটি ওয়েবসাইট তৈরি করছি এবং আমি আরও ভাল ওয়েবসাইটের গতি এবং এসইওর জন্য যতটা সম্ভব এইচটিটিপি কোয়েরি তৈরি করতে চাই। আমি স্রেফ তৈরি করা পৃষ্ঠাটিতে স্ক্রোলগুলিতে চিত্রগুলি দেখানো হচ্ছে (ব্যবহারকারী যখন সম্পর্কিত ছবিতে স্ক্রোল করে তখন চিত্রগুলিতে একটি বৈশিষ্ট্যযুক্ত ডেটা-স্ক্রার থাকে যা এসসিআর তে রূপান্তরিত হয়)।

সমস্ত চিত্রের data-srcপরিবর্তে বৈশিষ্ট্যযুক্ত হওয়ায় src, ডাব্লু 3 সি আমাকে ত্রুটিগুলি দেখায়।

এই সমস্যাটি সমাধান করার জন্য এই মুহূর্তে আমি দুটি বিকল্প পেয়েছি:

  1. খালি 1x1 চিত্রের url হওয়ার জন্য সমস্ত চিত্রের প্রাথমিক এসআরসি
  2. সমস্ত চিত্রের প্রাথমিক এসসিআর একটি ডেটা বেস 64 খালি চিত্র হতে হবে

আমি যখন ফাঁকা 1x1 চিত্রের একটি ইউআরএল ব্যবহার করছি, তারপরে (সরঞ্জাম.পিংডোম.কমের সাথে পরীক্ষিত) এটি 1 টি HTTP অনুরোধ দেখায়। যখন আমি কোনও ডেটা বেস 6464 টি ফাঁকা চিত্র ব্যবহার করি তখন পৃষ্ঠায় চিত্রের সংখ্যা হিসাবে এটি অনেকগুলি অনুরোধ দেখায়।

তাদের মধ্যে কোনটি আরও দ্রুতগতিযুক্ত কোনও ওয়েবসাইটের জন্য, দ্রুত গতিতে এবং কম HTTP অনুরোধ করে? (ধরা যাক যে ব্যবহারকারী ওয়েবপৃষ্ঠাটি একটি 14.4 কেবিপিএস ইন্টারনেট গতি - প্রথম ইন্টারনেটের গতিতে লোড করছে)

তবে এসইও এর জন্য?

অন্য কোন বিকল্প আছে?


8
"আমি যখন ডেটা বেস 64 টি ফাঁকা চিত্র ব্যবহার করছি তখন এটি পৃষ্ঠায় চিত্রের সংখ্যা হিসাবে অনেকগুলি অনুরোধ দেখায়" " - সেখানে কিছুটা ভুল আছে? ডেটা-ইউআরআই ব্যবহারের পুরো বিষয়টি হ'ল কোনও বাহ্যিক এইচটিটিপি অনুরোধ নেই। (কেবলমাত্র ব্যবহারকারী-এজেন্টরা যা ডেটা-ইউআরআই বুঝতে পারে না তারা কোনও এইচটিটিপি অনুরোধ
চালিয়ে

যদি ফাঁকা চিত্রটি 1x1 px এর চেয়ে বড় হবে (আমি এটি অনুমান করি) তবে আমি একটি বড় ব্যাকগ্রাউন্ড চিত্র (10x10 পিক্স, 100x100 পিক্স) সুপারিশ করব কারণ রেন্ডারিং দ্রুত হবে
টোটেমেডলি

3
কোনটিই ব্যবহার করবেন না? আপনি ডেটা-এসসিআরকে এসসিআর তে রূপান্তরিত করার সাথে সাথে আপনি ইমাগুলি ট্যাগটি গতিশীলভাবে তৈরি করতে পারেন। কোনও ডেটা-সিআরসি দিয়ে ফাঁকা চিত্র থাকার পরিবর্তে আপনি চিত্রগুলির তালিকা সঞ্চয় করতে এবং প্রয়োজনে ট্যাগ তৈরি করতে পারেন।
the_lotus

@ ফারাপ যা কাজ করে না কারণ ব্রাউজারগুলি চিত্রগুলি লুকিয়ে থাকলেও ডাউনলোড করবে।
অসন্তুষ্ট গোয়াট

আপনি বিষয়বস্তু সরবরাহের জন্য যে কোনওটিকেই বেছে নিন, একে পিএনজি 8 হিসাবে এনকোডিং করা সম্ভবত জেপিগের চেয়ে দ্রুত হবে।
সেকেন্ডে সাইক্বিয়ান 23 '

উত্তর:


12

বেস 64 ইমেজ বিকল্পটি ব্যবহার করা উচিত যেখানে আপনার কেবলমাত্র খুব অল্প সংখ্যক চিত্র থাকবে এবং আপনি সার্ভার থেকে একটি ছবি আনার নেটওয়ার্কের ওভারহেডটি মুছে ফেলতে চান। তবে আপনি যে প্রশ্নটিতে ইঙ্গিত দিচ্ছেন তা থেকে আমি ধরে নিই এটি একটি বিশাল সংখ্যক চিত্রের স্কেল হতে পারে। এই ক্ষেত্রে আমি একটি দীর্ঘ ক্যাশে আজীবন সার্ভার থেকে একক 1px x 1px স্বচ্ছ চিত্রটি ব্যবহার করব কারণ এটি ব্রাউজারে এবং কোনও মধ্যবর্তী প্রক্সি সার্ভারগুলিতে একবার ক্যাশে গেলে সার্ভার থেকে এনে দেওয়া হবে।

উদাহরণ হিসাবে এই চিত্রটি প্রায় 95 বাইট আকারের হবে ( https://commons.wikimedia.org/wiki/File ব্দx1.png), একটি বেস 64 এনকোডড ইমেজের স্ট্রিংয়ের জন্য আপনি দেখতে পাবেন যে আকারটি এই চিত্রের সাথে সমান হবে ফাইলের আকার তবে আপনি এতে যুক্ত প্রতিটি একক চিত্রের জন্য পুনরাবৃত্তি হবে।

২-৩ টি চিত্রের জন্য আকার এবং গতি নগণ্য হবে এবং একটি পুরো আনতে পেরে সার্ভার ট্র্যাফিক হ্রাস পাবে, তবে এর চেয়েও বেশি পৃষ্ঠার আকার খুব বড় হতে শুরু করবে যা লোডিংয়ের সময়কে প্রভাবিত করবে এবং এসইও র‌্যাঙ্কিংয়ের পরিবর্তে।


6
একটি ফাঁকা করুন Base64- ইমেজ 55 বাইট হতে পারে: data:image/gif;base64,R0lGODlhAQABAAAAACwAAAAAAQABAAA=। যদি চিত্রটির ইউআরএল কিছুটা দীর্ঘ হয় ( উদাহরণস্বরূপ : //.com/mplamps/template-name/files/1x1.png ), বেস 64 চিত্রটি সুপারিশ করা হবে কারণ আপনি এইচটিটিপি কোয়েরি করেন না এবং এটি বাইটে ছোট ইমেজ ইউআরএল (পৃষ্ঠার প্রতিটি চিত্রের জন্য পুনরাবৃত্তি) + বাহ্যিক চিত্রের আকারের চেয়ে বেশি।
নেটক্রিটর

@ নেটক্রিটরহোস্টিং-ওয়েব ডিজাইন আপনার মন্তব্যের জন্য আপনাকে ধন্যবাদ। বেস 64 এবং বাইরের চিত্র ব্যবহার করার সময় আমি ওয়েবসাইটের আকারটি তুলনা করেছি এবং বেস 64 চিত্র ব্যবহার করার সময় আকারটি ছোট হয়। আমি প্রতি পৃষ্ঠায় প্রায় 40 টি চিত্র ব্যবহার করছি।
এমএম পিপি

অথবা আপনি নিজের ওয়েবসাইটের মূলটিতে চিত্রটি আপলোড করতে পারেন এবং আপেক্ষিক ইউআরএল ব্যবহার করতে পারেন, তাই ওয়েবসাইটটি আরও ছোট হবে।
নেটক্রিটার

3
জিজিপ পুনরাবৃত্তিগুলির যত্ন নেবে, সুতরাং আপনার পৃষ্ঠায় 400 বেস-64৪ এনকোডযুক্ত চিত্র থাকা 400 ইউআরএল এর চেয়ে বেশি ব্যান্ডউইথের জন্য ব্যয় করতে পারে না।
ব্যবহারকারী 2428118

3
@ অ্যারন যদি আপনার পৃষ্ঠাটি 25.6 মেগাবাইট বড় হয় (400 82-বাইট দীর্ঘ ডেটা ইউআরআই এর মধ্যে 64 কেবি = 25,568,800 বাইট) তবে আপনি 3264 কেবি বেস 64-এনকোডযুক্ত ইমেজ নিয়ে চিন্তা করতে আরও বড় সমস্যা পেয়েছেন got
ব্যবহারকারী 2428118

5

আইআইআর 8 সমর্থন করার প্রয়োজন না হলে অবশ্যই ইউআরআই ডেটা দিয়ে যান go ( ব্রাউজার সমর্থন ))

এইচটিএমএলে সরাসরি প্রচুর ক্ষুদ্র চিত্র এম্বেড করা দেখতে দেখতে এটিকে সরাসরি লিঙ্ক করার চেয়ে আরও বেশি ব্যান্ডউইথ লাগবে, তবে বৃদ্ধিটি জিজিপ দ্বারা প্রশমিত হবে ; পৃষ্ঠার আকার শুধু পার্থক্য মধ্যে দৈর্ঘ্যে পার্থক্য থেকে আসবে এক একটি ফাঁকা ইমেজ ডেটা কোনো URI এবং এক আপনার সার্ভারে ইমেজ URL। একটি ফাঁকা জিআইএফ 43 বাইটের মতো ছোট হতে পারে। বেস 64৪-এনকোড, এটি 82২ বাইট। এমন কোনও উপায় নেই যা কখনও>> 500-বাইট এইচটিটিপি অনুরোধ , একই ধরণের আকারের প্রতিক্রিয়া থেকে খারাপ কাজ করতে চলেছে এবং তারপরে আমি টিসিপি প্যাকেটের আকার এবং অন্যান্য ওভারহেডকেও বিবেচনায় নিচ্ছি না।

এখানে বেস 64৪-এনকোডযুক্ত 43-বাইট জিআইএফ চিত্র রয়েছে:

data:image/gif;base64,R0lGODlhAQABAIAAAP///////yH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==

এসইও হিসাবে, গুগল সাইটের উত্স কোডটি দেখুন, উদাহরণস্বরূপ গুগল নিউজ এবং এর জন্য অনুসন্ধান করুন data:image/gif,base64...


আপনার চিত্রটি বড়। 55 বাইট সংস্করণ জন্য উপরের মন্তব্য দেখুন।
জোশুয়া

1
উল্লিখিত পরীক্ষাগুলির (মে 2014) স্ট্যাকওভারফ্লো-এর এই উত্তরটি দেখায় যে 1px চিত্রের বৃহত সংখ্যা (~ 1800) এম্বেড করা একই বাহ্যিক চিত্রের সাথে বারবার লিঙ্ক করার চেয়ে যথেষ্ট ধীর হয় । বাহ্যিক চিত্রটি একবার অনুরোধ করা হয়েছে এবং ক্যাশে করা হয়েছে, যেখানে ব্রাউজারকে HTML পার্সিং প্রক্রিয়ার অংশ হিসাবে প্রতিটি ডেটা-ইউআরআই আলাদাভাবে ডিকোড করতে হবে - এটি মনে হয় বাধা। এটি মনে করে যে ডেটা-ইউআরআইগুলি অল্প সংখ্যক (ছোট) চিত্রের মধ্যে সীমাবদ্ধ হওয়া উচিত।
ডকরাট

@ জোশুয়া যদিও এই চিত্রটি আমার ব্রাউজারে (ফায়ারফক্স) সঠিকভাবে প্রদর্শিত হয়েছে, তবে এটি অন্য কোনও প্রোগ্রাম (উদাহরণস্বরূপ পেইন্ট) দ্বারা খোলা যাবে না তাই আমি এটি ব্যবহার করা এড়াতে চাই।
ব্যবহারকারী 2428118

2

এই মুহূর্তে আমি দুটি বিকল্প পেয়েছি, এই সমস্যাটি সমাধান করার জন্য: সমস্ত চিত্রের প্রাথমিক এসসিআর একটি ডেটা বেস হওয়ার জন্য খালি ছবি image৪

এই বিকল্পটির জন্য কেবল একটি আধুনিক ব্রাউজারের প্রয়োজন নেই, তবে এটি ক্লায়েন্টের দিক থেকে ধীরে ধীরে হতে পারে যেহেতু ব্রাউজারটি অবশ্যই চিত্রটি তৈরি করতে ইমেজ ডেটা ডিকোড করে।

খালি 1x1 চিত্রের url হওয়ার জন্য সমস্ত চিত্রের প্রাথমিক এসআরসি

এটি ঠিক আছে যে সমস্ত চিত্র স্লটগুলির জন্য ফাঁকা চিত্র URL টি একই URL এবং এটির একটি দীর্ঘ ক্যাশে আজীবন এইচটিটিপি শিরোনাম "ক্যাশে-নিয়ন্ত্রণ" সংজ্ঞায়িত রয়েছে provided এটির সাথে সমস্যাটি হ'ল নতুন চিত্র ফাইলগুলি লোড হওয়ার সাথে সাথে, চিত্রের স্কোয়ারগুলি নতুন আকারে চলে যাবে যা ব্যবহারকারীর অভিজ্ঞতাটিকে দুর্দান্ত হিসাবে তৈরি করতে পারে না।

প্রায় নিখুঁত ধারণাটি হ'ল ...

পৃষ্ঠাটি শুরু হয়ে গেলে, স্থির আকারের বাক্স সহ একটি গ্রিড উপস্থাপন করুন যা প্রতিটি চিত্রকে সামঞ্জস্য করতে পারে। পুরো গ্রিডটি স্ক্রিনে ফিট না হলে এটি ঠিক আছে। তারপরে এমন জাভাস্ক্রিপ্ট তৈরি করুন যা এইচটিএমএল লোডের পরে কার্যকর হয় এবং সেই জাভাস্ক্রিপ্টে একটি নতুন চিত্র উপাদান তৈরি করুন এবং এটি গ্রিডের প্রতিটি কক্ষে সংযুক্ত করুন তারপরে চিত্রের উত্সটি সঠিক চিত্র ফাইলটিতে সেট করুন। প্রথম পর্দাটি পূর্ণ না হওয়া পর্যন্ত এটি করুন। তারপরে জাভাস্ক্রিপ্টের মধ্যে স্ক্রোলিং সনাক্ত করুন এবং তারপরে যখন স্ক্রোলিং ঘটে তখন নতুন ঘরগুলির জন্য উপরের প্রক্রিয়াটি পুনরাবৃত্তি করুন।

এখন আপনি যদি সেরাের সেরাটি চান, এবং গুণমান একটি বিশাল উদ্বেগ নয়, তবে আমি যা প্রস্তাব করি (তা আমি আমার সাইটেও প্রয়োগ করেছি) একটি গ্রিড তৈরি করে সেটাকে সেট করা হবে যে সেই গ্রিডের ব্যাকগ্রাউন্ড চিত্রটি একটি সমস্ত চিত্রের স্প্রিট শীট চিত্রগুলির স্কোয়ার হিসাবে ফর্ম্যাট করা। এই পদ্ধতিটি নমনীয় এবং দ্রুত লোড করার কারণে সমস্ত চিত্রের জন্য একটি অনুরোধ প্রয়োজন।

আপনি যদি দ্রুত রুটে যেতে চান তবে ব্যবহার করতে এখানে একটি টেমপ্লেট এইচটিএমএল। মাত্র দুটি অনুরোধ করা হয়। এইচটিএমএল কোড এবং একটি চিত্র। এই কোডটিতে, আমি ধরে নিচ্ছি যে শীট থেকে প্রতিটি চিত্র প্রস্থে 100 পিক্সেল এবং উচ্চতায় 200 পিক্সেল এবং প্রতিটি চিত্র কোনও ফাঁক ছাড়াই একে অপরের পাশে পুরোপুরিভাবে সাজানো আছে।

<html>
<head>
<style type="text/css">
#imagegrid {background-color: black; background-image:url('http://example.com/url/to/imagesheet.jpg');}
A {display:block;width:100px;height:200px;margin:10px;float:left;}
#image1{background-position: 0px 0px}
#image2{background-position: 100px 0px}
#image3{background-position: 200px 0px}
...
#imageN{background-position: XXXpx 0px}
</style>
</head>
<body>
<div id="imagegrid">
<a href="image_one.htm" id="image1"></a>
<a href="image_two.htm" id="image2"></a>
<a href="image_three.htm" id="image3"></a>
...
<a href="image_N.htm" id="imageN"></a>
</div>
</body>
</html>

আমার কোডে আমি 3 টি বিন্দু যুক্ত করেছি। এর অর্থ আপনি আপনার স্প্রিট শিটটিতে কেবলমাত্র এক সারি ইমেজ রয়েছে এমন শর্ত রয়েছে যে প্রতিবারের সংখ্যা বাড়িয়ে এবং অবস্থানটি 100 দ্বারা বাড়িয়ে আপনি চিত্র যুক্ত করতে পারেন keep এছাড়াও, অপেরা হিসাবে কিছু ব্রাউজারের সাহায্যে আপনার পটভূমির অবস্থান মানগুলির সামনে কাজ করার জন্য একটি নেতিবাচক চিহ্ন যুক্ত করতে হবে।


2
আপনার চিত্রগুলি আধ গিগাবাইট আকারের না হলে কোনও চিত্রই বেস 64-ডিকোডিংয়ের ফলে পারফরম্যান্সে কোনও পরিমাপযোগ্য প্রভাব পড়বে।
ব্যবহারকারী 2428118

এটি কম্পিউটার সিস্টেমের উপরও নির্ভর করে। যদি ক্লায়েন্টটির এখনও পেন্টিয়াম 1 এর মতো পুরানো ফ্যাশনযুক্ত কম্পিউটার থাকে তবে পারফরম্যান্স হিট হতে পারে।
মাইক 23

1

চিত্র, কারণ রক্ষণাবেক্ষণ।

আমার অভিজ্ঞতায় এটি চিত্রটি ব্যবহার করতে আরও ভাল কাজ করে। এটি প্রকৃত কোডে আরও স্পষ্ট এবং মনে রাখা সহজ। আমি সন্দেহ করি আপনি ট্রান্সপার্যান্ট ইমেজের জন্য এনকোডযুক্ত স্ট্রিংটি মনে রাখবেন এবং আপনি যদি করেন তবেও আপনার সসেসর / কোলেগেস।
আপনি যদি কয়েক সপ্তাহ পরে এই কোডটিতে ফিরে আসেন, আপনি বেস 64টি ভুলে গেছেন।

কোডটি বজায় রাখা অনেক সহজ হবে আপনি যদি ইমেজটি ব্যবহার করেন তবে ন্যূনতম প্রো এর পক্ষে এটি ওজন না করে।


অনেকে বেস -৪ 64 মানগুলি তৈরি করতে স্ক্রিপ্ট ব্যবহার করেন, সুতরাং ওপিতে তার ওয়েবসাইটের কোড উপস্থাপনের জন্য এইচটিএমএল ফাইলগুলির একটি সেট ব্যবহার না করা না হলে এই জাতীয় মানগুলি মনে রাখার প্রয়োজনীয়তা উইন্ডোটির বাইরে রয়েছে।
মাইক 23

1

কীভাবে কেবলমাত্র ~ 3 অতিরিক্ত বাইট, 0 টি অতিরিক্ত HTTP অনুরোধ এবং 0 টি অতিরিক্ত img src দৈর্ঘ্য (বা 0 টি ক্যাচড ডেটা-চিত্রের স্থানধারক)। আপনি কি চিত্রের জন্য একটি ফাঁকা এসসিআর ব্যবহার করতে পারেন?

<img src data-src="banannanannas.jpg" />

এবং যদি তাদের altট্যাগ থাকে তবে আপনি এগুলি ত্রুটি / ব্যর্থ চিত্র থেকে আড়াল করতে পারেন:

<img src data-src="banannanannas.jpg" onerror="this.alt=''" alt="some desc" />

প্রদর্শন: কিছুই না। ওয়েল ট্যাগটি হ্যাক করে চিত্রের স্থানধারক সীমানা থেকে সামান্য FOUC বিলম্ব হয়। সম্ভবত এটি পাশাপাশি পরিষ্কার করা যেতে পারে।


2
যদিও একটি খালি srcবৈশিষ্ট্য এখনও ডাব্লু 3 সি ভ্যালিডেটরে ত্রুটি ফেলবে (যা উদ্বেগ বলে মনে হচ্ছে)।
মিঃ হোয়েট

@ w3dk হ্যাঁ যে এটি সফল হয় তবে আবার খুব কম আধুনিকীকরণ পাস হয়।
ধৌপিন

আপনি যদি ডাব্লু 3 সি নিয়মগুলি পাস করতে চান তবে এসআরসি-র জন্য কিছু নির্দিষ্ট করা দরকার, এমনকি যদি এটির URL টি 404 ত্রুটি করে। আমি চিত্রটির প্রস্থ এবং উচ্চতা বৈশিষ্ট্যের মানগুলিও নির্দিষ্ট করে দেওয়ার পরামর্শ দিচ্ছি যাতে ব্যবহারকারীরা লোডিং প্রক্রিয়াটির অর্ধেক পথ বাড়িয়ে দেওয়া ছোট ছোট বাক্সগুলির পরিবর্তে প্রকৃত স্থানধারীদের দেখতে পান।
মাইকে
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.